From stefank at openjdk.org Wed Oct 1 07:36:49 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 1 Oct 2025 07:36:49 GMT Subject: RFR: 8368966: Remove spurious VMStructs friends In-Reply-To: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com> References: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com> Message-ID: On Tue, 30 Sep 2025 16:35:36 GMT, Francesco Andreuzzi wrote: > In this PR I propose a small clean up to remove several spurious friends of `VMStructs`. Either I could not find any reference to them in `vmStructs*`, or no private symbols is mentioned. > > Passes tier1 and tier2 (fastdebug). src/hotspot/share/utilities/growableArray.hpp line 715: > 713: template > 714: class GrowableArray : public GrowableArrayWithAllocator> { > 715: friend class VMStructs; I was a bit surprised to see that you added a friend declaration. Was this done because you removed the one in the parent class? I see that vmStructs.cpp has GrowableArray listed: nonstatic_field(GrowableArrayBase, _len, int) \ nonstatic_field(GrowableArrayBase, _capacity, int) \ nonstatic_field(GrowableArray, _data, int*) So, I guess it makes sense to move it here. OTOH, the exposed `_data` field is inside GrowableArrayView, so maybe it would work to put the friend declaration there instead? I guess either way is fine but there's a risk that there will be some churn about where to put the friend declaration if someone wants add one of the classes between (and including) GrowableArrayView and GrowableArray. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27583#discussion_r2393707385 From fandreuzzi at openjdk.org Wed Oct 1 09:08:09 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 1 Oct 2025 09:08:09 GMT Subject: RFR: 8368989: Use NMethodMarkingScope and ThreadsClaimTokenScope in shenandoahSTWMark Message-ID: Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `shenandoahSTWMark` to be more precise with what is needed and why. - `ShenandoahSTWMark` uses `MarkingNMethodClosure`, so we also need `NMethodMarkingScope`. - `nworkers` is guaranteed to be > 0 Passes `tier1` and `tier2` (fastdebug). ------------- Commit messages: - trigger - replace Changes: https://git.openjdk.org/jdk/pull/27589/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27589&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368989 Stats: 9 lines in 1 file changed: 5 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27589.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27589/head:pull/27589 PR: https://git.openjdk.org/jdk/pull/27589 From shade at openjdk.org Wed Oct 1 09:15:31 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 1 Oct 2025 09:15:31 GMT Subject: RFR: 8368989: Use NMethodMarkingScope and ThreadsClaimTokenScope in shenandoahSTWMark In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 08:57:07 GMT, Francesco Andreuzzi wrote: > Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `shenandoahSTWMark` to be more precise with what is needed and why. > > - `ShenandoahSTWMark` uses `MarkingNMethodClosure`, so we also need `NMethodMarkingScope`. > - `nworkers` is guaranteed to be > 0 > > Passes `tier1` and `tier2` (fastdebug). Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27589#pullrequestreview-3288228821 From ayang at openjdk.org Wed Oct 1 09:22:26 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 1 Oct 2025 09:22:26 GMT Subject: RFR: 8368989: Use NMethodMarkingScope and ThreadsClaimTokenScope in shenandoahSTWMark In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 08:57:07 GMT, Francesco Andreuzzi wrote: > Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `shenandoahSTWMark` to be more precise with what is needed and why. > > - `ShenandoahSTWMark` uses `MarkingNMethodClosure`, so we also need `NMethodMarkingScope`. > - `nworkers` is guaranteed to be > 0 > > Passes `tier1` and `tier2` (fastdebug). Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27589#pullrequestreview-3288254141 From fandreuzzi at openjdk.org Wed Oct 1 14:26:12 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 1 Oct 2025 14:26:12 GMT Subject: RFR: 8368966: Remove spurious VMStructs friends In-Reply-To: References: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com> Message-ID: On Wed, 1 Oct 2025 07:34:00 GMT, Stefan Karlsson wrote: > Was this done because you removed the one in the parent class? Yeah that's the reasoning. > the exposed _data field is inside GrowableArrayView, so maybe it would work to put the friend declaration there instead? Actually I'm a bit confused. What you suggest _should not_ work, but it compiles happily. Friendship is not inherited, so we should not be able to access `GrowableArray::_data` if we move `friend class VMStructs` to `GrowableArrayView`. I thought maybe that was a quirk of `offsetof`, but that does not seem to be the case: #include class X { protected: int field; }; class Y : public X {}; class Z { friend X; void doStuff() { Y y; // both these are illegal // int foo = y.field; // int foo = offsetof(Y, field); } }; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27583#discussion_r2394806258 From fandreuzzi at openjdk.org Wed Oct 1 14:45:57 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 1 Oct 2025 14:45:57 GMT Subject: RFR: 8368966: Remove spurious VMStructs friends In-Reply-To: References: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com> Message-ID: <5KijkMyIVGa9y4yQ8WZD-A7sop9fmMbDNPHuq0kW_5Q=.08f0e165-1833-4c35-b261-4d0806c30869@github.com> On Wed, 1 Oct 2025 07:34:00 GMT, Stefan Karlsson wrote: > Was this done because you removed the one in the parent class? Yeah that's the reasoning. > I guess either way is fine but there's a risk that there will be some churn about where to put the friend declaration if someone wants add one of the classes between (and including) GrowableArrayView and GrowableArray. Given that `friend` _should not be_ inherited, I'd expect the `friend` declaration on the exact class which we use in `vmStructs*.cpp`. However, I'm curious about why what you suggest compiles. Moving `friend class VMStructs` from `GrowableArray` to `GrowableArrayView` should not allow us to access `_data` via `GrowableArray`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27583#discussion_r2394868333 From stefank at openjdk.org Thu Oct 2 07:59:46 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 2 Oct 2025 07:59:46 GMT Subject: RFR: 8368966: Remove spurious VMStructs friends In-Reply-To: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com> References: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com> Message-ID: On Tue, 30 Sep 2025 16:35:36 GMT, Francesco Andreuzzi wrote: > In this PR I propose a small clean up to remove several spurious friends of `VMStructs`. Either I could not find any reference to them in `vmStructs*`, or no private symbols is mentioned. > > Passes tier1 and tier2 (fastdebug). Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27583#pullrequestreview-3293095646 From stefank at openjdk.org Thu Oct 2 07:59:48 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 2 Oct 2025 07:59:48 GMT Subject: RFR: 8368966: Remove spurious VMStructs friends In-Reply-To: <5KijkMyIVGa9y4yQ8WZD-A7sop9fmMbDNPHuq0kW_5Q=.08f0e165-1833-4c35-b261-4d0806c30869@github.com> References: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com> <5KijkMyIVGa9y4yQ8WZD-A7sop9fmMbDNPHuq0kW_5Q=.08f0e165-1833-4c35-b261-4d0806c30869@github.com> Message-ID: <8hpnnfueQUsV2r1a1h1N99OMdd0p8EpYdRx83blcgOw=.6a3fbad7-3f79-48fe-be00-a6ee68c9de38@github.com> On Wed, 1 Oct 2025 14:42:13 GMT, Francesco Andreuzzi wrote: >> src/hotspot/share/utilities/growableArray.hpp line 715: >> >>> 713: template >>> 714: class GrowableArray : public GrowableArrayWithAllocator> { >>> 715: friend class VMStructs; >> >> I was a bit surprised to see that you added a friend declaration. Was this done because you removed the one in the parent class? >> >> I see that vmStructs.cpp has GrowableArray listed: >> >> nonstatic_field(GrowableArrayBase, _len, int) \ >> nonstatic_field(GrowableArrayBase, _capacity, int) \ >> nonstatic_field(GrowableArray, _data, int*) >> >> >> So, I guess it makes sense to move it here. OTOH, the exposed `_data` field is inside GrowableArrayView, so maybe it would work to put the friend declaration there instead? >> >> I guess either way is fine but there's a risk that there will be some churn about where to put the friend declaration if someone wants add one of the classes between (and including) GrowableArrayView and GrowableArray. > >> Was this done because you removed the one in the parent class? > > Yeah that was my reasoning. > >> I guess either way is fine but there's a risk that there will be some churn about where to put the friend declaration if someone wants add one of the classes between (and including) GrowableArrayView and GrowableArray. > > To me it looks less confusing to have the `friend` declaration for the type which is referenced in `vmStructs`. But both are legal, do you think moving the `friend` declaration to the type which declares the referenced field would be more appropriate? If yes, I'll track other similar patterns too. I don't think such churn is important for VMStructs. Let's keep your change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27583#discussion_r2397576465 From fandreuzzi at openjdk.org Thu Oct 2 08:18:46 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 2 Oct 2025 08:18:46 GMT Subject: RFR: 8368966: Remove spurious VMStructs friends In-Reply-To: References: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com> Message-ID: On Thu, 2 Oct 2025 07:56:39 GMT, Stefan Karlsson wrote: >> In this PR I propose a small clean up to remove several spurious friends of `VMStructs`. Either I could not find any reference to them in `vmStructs*`, or no private symbols is mentioned. >> >> Passes tier1 and tier2 (fastdebug). > > Marked as reviewed by stefank (Reviewer). Thanks for the review @stefank. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27583#issuecomment-3359780526 From duke at openjdk.org Thu Oct 2 08:18:48 2025 From: duke at openjdk.org (duke) Date: Thu, 2 Oct 2025 08:18:48 GMT Subject: RFR: 8368966: Remove spurious VMStructs friends In-Reply-To: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com> References: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com> Message-ID: On Tue, 30 Sep 2025 16:35:36 GMT, Francesco Andreuzzi wrote: > In this PR I propose a small clean up to remove several spurious friends of `VMStructs`. Either I could not find any reference to them in `vmStructs*`, or no private symbols is mentioned. > > Passes tier1 and tier2 (fastdebug). @fandreuz Your change (at version 1f873d0d1e693d0d73772376041cc6171bf13be2) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27583#issuecomment-3359787966 From fandreuzzi at openjdk.org Thu Oct 2 08:38:31 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 2 Oct 2025 08:38:31 GMT Subject: RFR: 8368989: Use NMethodMarkingScope and ThreadsClaimTokenScope in shenandoahSTWMark In-Reply-To: References:

Message-ID: On Wed, 1 Oct 2025 09:19:35 GMT, Albert Mingkun Yang wrote: >> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `shenandoahSTWMark` to be more precise with what is needed and why. >> >> - `ShenandoahSTWMark` uses `MarkingNMethodClosure`, so we also need `NMethodMarkingScope`. >> - `nworkers` is guaranteed to be > 0 >> >> Passes `tier1` and `tier2` (fastdebug). > > Marked as reviewed by ayang (Reviewer). Thanks for the review @albertnetymk and @shipilev. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27589#issuecomment-3359876182 From duke at openjdk.org Thu Oct 2 08:38:33 2025 From: duke at openjdk.org (duke) Date: Thu, 2 Oct 2025 08:38:33 GMT Subject: RFR: 8368989: Use NMethodMarkingScope and ThreadsClaimTokenScope in shenandoahSTWMark In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 08:57:07 GMT, Francesco Andreuzzi wrote: > Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `shenandoahSTWMark` to be more precise with what is needed and why. > > - `ShenandoahSTWMark` uses `MarkingNMethodClosure`, so we also need `NMethodMarkingScope`. > - `nworkers` is guaranteed to be > 0 > > Passes `tier1` and `tier2` (fastdebug). @fandreuz Your change (at version 442bc5be6ca713c7fcabf8a0ad87f74f97d58181) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27589#issuecomment-3359879615 From ayang at openjdk.org Thu Oct 2 08:47:52 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 2 Oct 2025 08:47:52 GMT Subject: RFR: 8368966: Remove spurious VMStructs friends In-Reply-To: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com> References: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com> Message-ID: <8njjGUUpbw5NKV_Rh8MUw4lJ6dqiSUWeSuXC6Thqh1o=.d8b2297d-f3d9-450b-850a-23decdc11320@github.com> On Tue, 30 Sep 2025 16:35:36 GMT, Francesco Andreuzzi wrote: > In this PR I propose a small clean up to remove several spurious friends of `VMStructs`. Either I could not find any reference to them in `vmStructs*`, or no private symbols is mentioned. > > Passes tier1 and tier2 (fastdebug). Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27583#pullrequestreview-3293343742 From fandreuzzi at openjdk.org Thu Oct 2 09:02:00 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 2 Oct 2025 09:02:00 GMT Subject: Integrated: 8368966: Remove spurious VMStructs friends In-Reply-To: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com> References: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com> Message-ID: On Tue, 30 Sep 2025 16:35:36 GMT, Francesco Andreuzzi wrote: > In this PR I propose a small clean up to remove several spurious friends of `VMStructs`. Either I could not find any reference to them in `vmStructs*`, or no private symbols is mentioned. > > Passes tier1 and tier2 (fastdebug). This pull request has now been integrated. Changeset: dfd38322 Author: Francesco Andreuzzi Committer: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/dfd383224dbc2e41c9f44b1acd09ffb179cc38f3 Stats: 80 lines in 47 files changed: 1 ins; 78 del; 1 mod 8368966: Remove spurious VMStructs friends Reviewed-by: stefank, ayang ------------- PR: https://git.openjdk.org/jdk/pull/27583 From roland at openjdk.org Thu Oct 2 09:08:06 2025 From: roland at openjdk.org (Roland Westrelin) Date: Thu, 2 Oct 2025 09:08:06 GMT Subject: RFR: 8354282: C2: more crashes in compiled code because of dependency on removed range check CastIIs [v3] In-Reply-To: References: Message-ID: > This is a variant of 8332827. In 8332827, an array access becomes > dependent on a range check `CastII` for another array access. When, > after loop opts are over, that RC `CastII` was removed, the array > access could float and an out of bound access happened. With the fix > for 8332827, RC `CastII`s are no longer removed. > > With this one what happens is that some transformations applied after > loop opts are over widen the type of the RC `CastII`. As a result, the > type of the RC `CastII` is no longer narrower than that of its input, > the `CastII` is removed and the dependency is lost. > > There are 2 transformations that cause this to happen: > > - after loop opts are over, the type of the `CastII` nodes are widen > so nodes that have the same inputs but a slightly different type can > common. > > - When pushing a `CastII` through an `Add`, if of the type both inputs > of the `Add`s are non constant, then we end up widening the type > (the resulting `Add` has a type that's wider than that of the > initial `CastII`). > > There are already 3 types of `Cast` nodes depending on the > optimizations that are allowed. Either the `Cast` is floating > (`depends_only_test()` returns `true`) or pinned. Either the `Cast` > can be removed if it no longer narrows the type of its input or > not. We already have variants of the `CastII`: > > - if the Cast can float and be removed when it doesn't narrow the type > of its input. > > - if the Cast is pinned and be removed when it doesn't narrow the type > of its input. > > - if the Cast is pinned and can't be removed when it doesn't narrow > the type of its input. > > What we need here, I think, is the 4th combination: > > - if the Cast can float and can't be removed when it doesn't narrow > the type of its input. > > Anyway, things are becoming confusing with all these different > variants named in ways that don't always help figure out what > constraints one of them operate under. So I refactored this and that's > the biggest part of this change. The fix consists in marking `Cast` > nodes when their type is widen in a way that prevents them from being > optimized out. > > Tobias ran performance testing with a slightly different version of > this change and there was no regression. Roland Westrelin has updated the pull request incrementally with three additional commits since the last revision: - review - infinite loop in gvn fix - renaming ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24575/files - new: https://git.openjdk.org/jdk/pull/24575/files/c509ef56..aff5894b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24575&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24575&range=01-02 Stats: 61 lines in 10 files changed: 11 ins; 0 del; 50 mod Patch: https://git.openjdk.org/jdk/pull/24575.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24575/head:pull/24575 PR: https://git.openjdk.org/jdk/pull/24575 From roland at openjdk.org Thu Oct 2 09:08:08 2025 From: roland at openjdk.org (Roland Westrelin) Date: Thu, 2 Oct 2025 09:08:08 GMT Subject: RFR: 8354282: C2: more crashes in compiled code because of dependency on removed range check CastIIs [v3] In-Reply-To: <7Y1VflHDgnEChBAv9bwWH5ayU-K9ngRa3BfPjgzzHP0=.61111d18-a22e-4cb5-9492-e50f5524ac08@github.com> References: <7Y1VflHDgnEChBAv9bwWH5ayU-K9ngRa3BfPjgzzHP0=.61111d18-a22e-4cb5-9492-e50f5524ac08@github.com> Message-ID: On Wed, 23 Apr 2025 10:56:51 GMT, Emanuel Peter wrote: >> Roland Westrelin has updated the pull request incrementally with three additional commits since the last revision: >> >> - review >> - infinite loop in gvn fix >> - renaming > > @rwestrel thanks for looking into this one! > > I have not yet deeply studied the PR, but am feeling some confusion about the naming. > > I think the `DependencyType` is really a good step into the right direction, it helps clean things up. > > I'm wondering if we should pick either `depends_only_on_test` or `pinned`, and use it everywhere consistently. Having both around as near synonymes (antonymes?) is a bit confusing for me. > > I'll look into the code more later. I pushed an update with the renaming suggested by @eme64 and an extra comment with example use cases ------------- PR Comment: https://git.openjdk.org/jdk/pull/24575#issuecomment-3360011105 From fandreuzzi at openjdk.org Thu Oct 2 09:31:05 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 2 Oct 2025 09:31:05 GMT Subject: RFR: 8368989: Use NMethodMarkingScope and ThreadsClaimTokenScope in shenandoahSTWMark [v2] In-Reply-To: References: Message-ID: > Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `shenandoahSTWMark` to be more precise with what is needed and why. > > - `ShenandoahSTWMark` uses `MarkingNMethodClosure`, so we also need `NMethodMarkingScope`. > - `nworkers` is guaranteed to be > 0 > > Passes `tier1` and `tier2` (fastdebug). Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: trigger ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27589/files - new: https://git.openjdk.org/jdk/pull/27589/files/442bc5be..0801a496 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27589&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27589&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27589.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27589/head:pull/27589 PR: https://git.openjdk.org/jdk/pull/27589 From fandreuzzi at openjdk.org Thu Oct 2 09:31:06 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 2 Oct 2025 09:31:06 GMT Subject: RFR: 8368989: Use NMethodMarkingScope and ThreadsClaimTokenScope in shenandoahSTWMark In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 08:57:07 GMT, Francesco Andreuzzi wrote: > Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `shenandoahSTWMark` to be more precise with what is needed and why. > > - `ShenandoahSTWMark` uses `MarkingNMethodClosure`, so we also need `NMethodMarkingScope`. > - `nworkers` is guaranteed to be > 0 > > Passes `tier1` and `tier2` (fastdebug). I noticed one of the macOS job was canceled, I noticed the same issue in another repository yesterday. I assume the reason is a scheduling timeout. Restarted GHA run. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27589#issuecomment-3360118706 From duke at openjdk.org Thu Oct 2 12:31:46 2025 From: duke at openjdk.org (duke) Date: Thu, 2 Oct 2025 12:31:46 GMT Subject: RFR: 8368989: Use NMethodMarkingScope and ThreadsClaimTokenScope in shenandoahSTWMark [v2] In-Reply-To: References:

Message-ID: On Thu, 2 Oct 2025 09:31:05 GMT, Francesco Andreuzzi wrote: >> Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `shenandoahSTWMark` to be more precise with what is needed and why. >> >> - `ShenandoahSTWMark` uses `MarkingNMethodClosure`, so we also need `NMethodMarkingScope`. >> - `nworkers` is guaranteed to be > 0 >> >> Passes `tier1` and `tier2` (fastdebug). > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > trigger @fandreuz Your change (at version 0801a4965d20cf84b2e4be04c4ab4a98a5e7234c) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27589#issuecomment-3360986058 From wkemper at openjdk.org Thu Oct 2 14:27:24 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 2 Oct 2025 14:27:24 GMT Subject: RFR: Merge openjdk/jdk21u:master Message-ID: Merges tag jdk-21.0.9+9 ------------- Commit messages: - 8368308: ISO 4217 Amendment 180 Update - 8365389: Remove static color fields from SwingUtilities3 and WindowsMenuItemUI The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/224/files Stats: 90 lines in 9 files changed: 14 ins; 50 del; 26 mod Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/224.diff Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/224/head:pull/224 PR: https://git.openjdk.org/shenandoah-jdk21u/pull/224 From wkemper at openjdk.org Thu Oct 2 18:11:10 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 2 Oct 2025 18:11:10 GMT Subject: RFR: Merge openjdk/jdk21u:master [v2] In-Reply-To: References: Message-ID: > Merges tag jdk-21.0.9+9 William Kemper 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. ------------- Changes: - all: https://git.openjdk.org/shenandoah-jdk21u/pull/224/files - new: https://git.openjdk.org/shenandoah-jdk21u/pull/224/files/8c322f59..8c322f59 Webrevs: - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=224&range=01 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=224&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/224.diff Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/224/head:pull/224 PR: https://git.openjdk.org/shenandoah-jdk21u/pull/224 From wkemper at openjdk.org Thu Oct 2 18:13:56 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 2 Oct 2025 18:13:56 GMT Subject: Integrated: Merge openjdk/jdk21u:master In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 14:22:20 GMT, William Kemper wrote: > Merges tag jdk-21.0.9+9 This pull request has now been integrated. Changeset: 3d6a0cca Author: William Kemper URL: https://git.openjdk.org/shenandoah-jdk21u/commit/3d6a0cca11e803a95e9376eed9af55a032feb719 Stats: 90 lines in 9 files changed: 14 ins; 50 del; 26 mod Merge ------------- PR: https://git.openjdk.org/shenandoah-jdk21u/pull/224 From fandreuzzi at openjdk.org Thu Oct 2 18:52:30 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 2 Oct 2025 18:52:30 GMT Subject: Integrated: 8368989: Use NMethodMarkingScope and ThreadsClaimTokenScope in shenandoahSTWMark In-Reply-To: References: Message-ID: On Wed, 1 Oct 2025 08:57:07 GMT, Francesco Andreuzzi wrote: > Replace `StrongRootsScope` with `ThreadsClaimTokenScope` in `shenandoahSTWMark` to be more precise with what is needed and why. > > - `ShenandoahSTWMark` uses `MarkingNMethodClosure`, so we also need `NMethodMarkingScope`. > - `nworkers` is guaranteed to be > 0 > > Passes `tier1` and `tier2` (fastdebug). This pull request has now been integrated. Changeset: 1d55adee Author: Francesco Andreuzzi Committer: Paul Hohensee URL: https://git.openjdk.org/jdk/commit/1d55adee11fc2fdbf2e009e1308b763fd7217dad Stats: 9 lines in 1 file changed: 5 ins; 2 del; 2 mod 8368989: Use NMethodMarkingScope and ThreadsClaimTokenScope in shenandoahSTWMark Reviewed-by: shade, ayang ------------- PR: https://git.openjdk.org/jdk/pull/27589 From kdnilsen at openjdk.org Thu Oct 2 23:05:29 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 2 Oct 2025 23:05:29 GMT Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need accurate live_data [v10] In-Reply-To: References: Message-ID: <5T0PXD1oxDN6BXnflm0DFQdBFEfUC95ds21spzVzwMw=.3a538ff0-53da-4397-887d-73ffa98bb9ef@github.com> > The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected. In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region. This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint. > > However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated. In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended. > > This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: reviewer feedback to reduce code duplication ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24319/files - new: https://git.openjdk.org/jdk/pull/24319/files/cc6f1153..f838b5e1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24319&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24319&range=08-09 Stats: 36 lines in 3 files changed: 9 ins; 18 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/24319.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24319/head:pull/24319 PR: https://git.openjdk.org/jdk/pull/24319 From kdnilsen at openjdk.org Thu Oct 2 23:09:50 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Thu, 2 Oct 2025 23:09:50 GMT Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need accurate live_data [v9] In-Reply-To: References: <8GvpkoZ5-Pso8XG-AKeR0QnlBQr0op9E-lvQMS12lTI=.6c88343d-4c74-4f29-a528-f499f559a2bd@github.com> Message-ID: On Tue, 16 Sep 2025 23:15:11 GMT, William Kemper wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix compilation errors after merge > > src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 91: > >> 89: } >> 90: >> 91: // Between consecutive mixed-evacuation cycles, the live data within each candidate region may change due to > > I think we could reduce some duplication and call `recalibrate_old_collection_candidates_live_memory` here if the function didn't have the side effect of updating `_live_bytes_in_unprocessed_candidates`. Perhaps the function could return `total_live_data` and be `const`? Good suggestion. I've refactored a little. I think it can't be const because we sort the _region_data. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24319#discussion_r2400354971 From wkemper at openjdk.org Thu Oct 2 23:16:50 2025 From: wkemper at openjdk.org (William Kemper) Date: Thu, 2 Oct 2025 23:16:50 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet [v12] In-Reply-To: References:

Message-ID: On Tue, 9 Sep 2025 22:07:11 GMT, Kelvin Nilsen wrote: >> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet. In the new code, we keep a single tally of relevant information within ShenandoahFreeSet. >> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet. >> >> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies. These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms. >> >> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > another tweak to make GHA gtest happy src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 55: > 53: class ShenandoahLeftRightIterator { > 54: private: > 55: index_type _idx; Changing this to a different type introduces a lot of noise in the review. It was compiling before this change, can we figure out if it is really necessary to change this type? src/hotspot/share/gc/shenandoah/shenandoahGeneration.hpp line 134: > 132: virtual size_t used_regions_size() const; > 133: virtual size_t free_unaffiliated_regions() const; > 134: size_t used() const override { This is already virtual (since it is marked as `override`) so it makes sense to put these different behaviors in the different generation subclasses. src/hotspot/share/gc/shenandoah/shenandoahGeneration.hpp line 154: > 152: size_t available() const override; > 153: size_t available_with_reserve() const; > 154: size_t used_including_humongous_waste() const { Can we get rid of this method? Just have callers call `used` now? src/hotspot/share/gc/shenandoah/shenandoahGenerationalEvacuationTask.cpp line 253: > 251: if (available_in_region < plab_min_size_in_bytes) { > 252: // The available memory in young had been retired. Retire it in old also. > 253: region_to_be_used_in_old += available_in_region; This looks like a dead store. src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.hpp line 104: > 102: > 103: // Use this only for unit testing. Do not use for production. > 104: inline void set_capacity(size_t bytes) { We should be able to inline this code in `test_shenandoahOldHeuristic.cpp` in the constructor of the test fixture that calls this method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2344980222 PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2344937348 PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2344940289 PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2345035769 PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2345072351 From wkemper at openjdk.org Fri Oct 3 00:03:58 2025 From: wkemper at openjdk.org (William Kemper) Date: Fri, 3 Oct 2025 00:03:58 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet [v12] In-Reply-To: References:

Message-ID: On Tue, 30 Sep 2025 21:55:46 GMT, Kelvin Nilsen wrote: >> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet. In the new code, we keep a single tally of relevant information within ShenandoahFreeSet. >> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet. >> >> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies. These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms. >> >> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books. > > Kelvin Nilsen has updated the pull request incrementally with five additional commits since the last revision: > > - small refactoring > - OO refinements to used_regions_size() > - fix broken assert from previous commit > - OO refinements to free_unaffiliated_regions() > - OO refinements to max_capacity() Mostly nits and questions. src/hotspot/share/gc/shared/gc_globals.hpp line 472: > 470: product(size_t, SoftMaxHeapSize, 0, MANAGEABLE, \ > 471: "Soft limit for maximum heap size (in bytes)") \ > 472: constraint(SoftMaxHeapSizeConstraintFunc,AfterMemoryInit) \ Changing a common file might raise eyebrows. Why do we need this? src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 1153: > 1151: void ShenandoahConcurrentGC::op_final_update_refs() { > 1152: ShenandoahHeap* const heap = ShenandoahHeap::heap(); > 1153: bool is_generational = heap->mode()->is_generational(); Are the changes here necessary? This is a big PR, it would be helpful to minimize unnecessary changes. src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 1145: > 1143: _preserved_marks->reclaim(); > 1144: > 1145: // We defer generation resizing actions until after cset regions have been recycled. We do this even following an Stale comment? src/hotspot/share/gc/shenandoah/shenandoahGenerationSizer.hpp line 1: > 1: /* Is there any point in keeping this file now? Not sure what this class is doing now. src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 745: > 743: // 2. Region's free is less than minimum TLAB size and is retired > 744: // 3. The unused portion of memory in the last region of a humongous object > 745: void ShenandoahHeap::increase_used(const ShenandoahAllocRequest& req) { I don't see the point of this method now. Can we delete it? src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2719: > 2717: assert(used() <= ShenandoahHeap::heap()->max_capacity(), "sanity"); > 2718: assert(committed() <= ShenandoahHeap::heap()->max_capacity(), "sanity"); > 2719: assert(max_capacity() <= ShenandoahHeap::heap()->max_capacity(), "sanity"); This last one is just comparing the results of the same method call. Are we worried about races here? src/hotspot/share/gc/shenandoah/shenandoahMemoryPool.cpp line 65: > 63: // to make sense under the race. See JDK-8207200. > 64: committed = MAX2(used, committed); > 65: assert(used <= committed, "used: %zu, committed: %zu", used, committed); Shouldn't it always be the case that `initial <= used <= committed <= max`? src/hotspot/share/gc/shenandoah/shenandoahSimpleBitMap.cpp line 42: > 40: } > 41: > 42: size_t ShenandoahSimpleBitMap::count_leading_ones(index_type start_idx) const { Did we figure out why we want to rename this type? It adds a lot of noise to this PR and I'd hate to do something like this because of a C++ technicality. src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp line 498: > 496: > 497: class ShenandoahVerifyHeapRegionClosure : public ShenandoahHeapRegionClosure { > 498: private: Formatting the access modifiers like this looks idiosyncratic: % grep -ri -P '^ private:' src/hotspot | wc -l 115 % grep -ri -P '^private:' src/hotspot | wc -l 1444 ------------- Changes requested by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26867#pullrequestreview-3296845640 PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2400422999 PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2400380773 PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2400382789 PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2400397766 PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2400401051 PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2400404948 PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2400410359 PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2400411950 PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2400418474 From wkemper at openjdk.org Fri Oct 3 00:04:00 2025 From: wkemper at openjdk.org (William Kemper) Date: Fri, 3 Oct 2025 00:04:00 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet [v3] In-Reply-To: References:

Message-ID: On Fri, 12 Sep 2025 17:48:23 GMT, William Kemper wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> another tweak to make GHA gtest happy > > src/hotspot/share/gc/shenandoah/shenandoahGenerationalEvacuationTask.cpp line 253: > >> 251: if (available_in_region < plab_min_size_in_bytes) { >> 252: // The available memory in young had been retired. Retire it in old also. >> 253: region_to_be_used_in_old += available_in_region; > > This looks like a dead store. This chunk of code from 253-258 looks like it could be removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2400392332 From kdnilsen at openjdk.org Fri Oct 3 00:21:11 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 3 Oct 2025 00:21:11 GMT Subject: RFR: 8358735: GenShen: bug in #undef'd code in block_start() [v2] In-Reply-To: References: Message-ID: <7zV-fLvjb-4gBVTppg4XTXPNxEheqLfxB0v_WONuinI=.22775b58-42cf-499e-9007-fad07118217d@github.com> > When scanning a range of dirty cards within the GenShen remembered set, we need to find the object that spans the beginning of the left-most dirty card. The existing code is not reliable following class unloading. > > The new code uses the marking context when it is available to determine the location of live objects that reside below TAMS within each region. Above TAMS, all objects are presumed live and parsable. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: fix idiosyncratic formatting ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27353/files - new: https://git.openjdk.org/jdk/pull/27353/files/76979421..668e8615 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27353&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27353&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27353.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27353/head:pull/27353 PR: https://git.openjdk.org/jdk/pull/27353 From kdnilsen at openjdk.org Fri Oct 3 00:25:45 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 3 Oct 2025 00:25:45 GMT Subject: RFR: 8368681: Shenandoah: Add documentation comments for ShenandoahAllocationRate [v2] In-Reply-To: References:

Message-ID: <7OWJnIPeKppSXqKzNJvrqD0vKHOZZzKpLNe--W9CS5Q=.f367368e-e209-4c48-831d-65c080426d1c@github.com> On Thu, 25 Sep 2025 23:45:38 GMT, William Kemper wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix several typos > > src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp line 52: > >> 50: // The sampled allocation rate is computed from (allocated - _last_sample_value) / (current_time - _last_sample_time). >> 51: // Return the newly computed rate if the sample is taken, zero if it is not an appropriate time to add a sample. >> 52: // In the case that a new sample is not take, overwrite unaccounted_bytes_allocated with bytes allocated since > > s/take/taken Fixed. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27505#discussion_r2400443230 From xpeng at openjdk.org Fri Oct 3 00:33:46 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Fri, 3 Oct 2025 00:33:46 GMT Subject: RFR: 8368681: Shenandoah: Add documentation comments for ShenandoahAllocationRate [v2] In-Reply-To: References:

Message-ID: On Sat, 27 Sep 2025 23:13:34 GMT, Kelvin Nilsen wrote: >> Add documentation to ShenandoahAllocationRate > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > Fix several typos Looks good to me, thanks! ------------- Marked as reviewed by xpeng (Committer). PR Review: https://git.openjdk.org/jdk/pull/27505#pullrequestreview-3296939226 From wkemper at openjdk.org Fri Oct 3 00:37:55 2025 From: wkemper at openjdk.org (William Kemper) Date: Fri, 3 Oct 2025 00:37:55 GMT Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need accurate live_data [v10] In-Reply-To: <5T0PXD1oxDN6BXnflm0DFQdBFEfUC95ds21spzVzwMw=.3a538ff0-53da-4397-887d-73ffa98bb9ef@github.com> References: <5T0PXD1oxDN6BXnflm0DFQdBFEfUC95ds21spzVzwMw=.3a538ff0-53da-4397-887d-73ffa98bb9ef@github.com> Message-ID: On Thu, 2 Oct 2025 23:05:29 GMT, Kelvin Nilsen wrote: >> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected. In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region. This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint. >> >> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated. In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended. >> >> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > reviewer feedback to reduce code duplication I think we can delete the field `_mixed_candidate_garbage_words` now with the refactoring. Would also be good to run this through testing again. src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp line 262: > 260: volatile size_t _critical_pins; > 261: > 262: size_t _mixed_candidate_garbage_words; Can we delete this field now? ------------- Changes requested by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24319#pullrequestreview-3296942280 PR Review Comment: https://git.openjdk.org/jdk/pull/24319#discussion_r2400454938 From kdnilsen at openjdk.org Fri Oct 3 18:41:52 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 3 Oct 2025 18:41:52 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet [v3] In-Reply-To: References:

Message-ID: <17APPI-yLZ70C8-EIxK8Olf3iu8mtA5FLB-338EYtV8=.996629b7-0001-4195-8f7f-01dfe4130d91@github.com> On Fri, 12 Sep 2025 17:04:19 GMT, William Kemper wrote: >> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: >> >> another tweak to make GHA gtest happy > > src/hotspot/share/gc/shenandoah/shenandoahGeneration.hpp line 134: > >> 132: virtual size_t used_regions_size() const; >> 133: virtual size_t free_unaffiliated_regions() const; >> 134: size_t used() const override { > > This is already virtual (since it is marked as `override`) so it makes sense to put these different behaviors in the different generation subclasses. Thanks. This is done now. > src/hotspot/share/gc/shenandoah/shenandoahGeneration.hpp line 154: > >> 152: size_t available() const override; >> 153: size_t available_with_reserve() const; >> 154: size_t used_including_humongous_waste() const { > > Can we get rid of this method? Just have callers call `used` now? Correct. It has been removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2402976401 PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2402978481 From sherman at openjdk.org Fri Oct 3 19:10:20 2025 From: sherman at openjdk.org (Xueming Shen) Date: Fri, 3 Oct 2025 19:10:20 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support Message-ID: ### Summary Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions. Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as: **String.equalsIgnoreCase(String)** - Unicode-aware, locale-independent. - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point. - Limited: does not support 1:M mapping defined in Unicode case folding. **Character.toLowerCase(int) / Character.toUpperCase(int)** - Locale-independent, single code point only. - No support for 1:M mappings. **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)** - Based on Unicode SpecialCasing.txt, supports 1:M mappings. - Intended primarily for presentation/display, not structural case-insensitive matching. - Requires full string conversion before comparison, which is less efficient and not intended for structural matching. **1:M mapping example, U+00DF (?)** - String.toUpperCase(Locale.ROOT, "?") ? "SS" - Case folding produces "ss", matching Unicode caseless comparison rules. jshell> "\u00df".equalsIgnoreCase("ss") $22 ==> false jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss") $24 ==> true ### Motivation & Direction Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching. - Unicode-compliant **full** case folding. - Simpler, stable and more efficient case-less matching without workarounds. - Brings Java's string comparison handling in line with other programming languages/libraries. This PR proposes to introduce the following comparison methods in `String` class - boolean equalsFoldCase(String anotherString) - int compareToFoldCase(String anotherString) - Comparator UNICODE_CASEFOLD_ORDER These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required. *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string. However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then passed into APIs where case-folding semantics are not appropriate. ### The New API /** * Compares this {@code String} to another {@code String} for equality, * using Unicode case folding. Two strings are considered equal * by this method if their case-folded forms are identical. *

* Case folding is defined by the Unicode Standard in * CaseFolding.txt, * including 1:M mappings. For example, {@code "Ma?e".equalsFoldCase("MASSE")} * returns {@code true}, since the character {@code U+00DF} (sharp s) folds * to {@code "ss"}. *

* Case folding is locale-independent and language-neutral, unlike * locale-sensitive transformations such as {@link #toLowerCase()} or * {@link #toUpperCase()}. It is intended for caseless matching, * searching, and indexing. * * @apiNote * This method is the Unicode-compliant alternative to * {@link #equalsIgnoreCase(String)}. It implements full case folding as * defined by the Unicode Standard, which may differ from the simpler * per-character mapping performed by {@code equalsIgnoreCase}. * For example: *

{@snippet lang=java :
     * String a = "Ma?e";
     * String b = "MASSE";
     * boolean equalsFoldCase = a.equalsFoldCase(b);       // returns true
     * boolean equalsIgnoreCase = a.equalsIgnoreCase(b);   // returns false
     * }

* * @param anotherString * The {@code String} to compare this {@code String} against * * @return {@code true} if the given object is not {@code null} and represents * the same sequence of characters as this string under Unicode case * folding; {@code false} otherwise. * * @see #compareToFoldCase(String) * @see #equalsIgnoreCase(String) * @since 26 */ public boolean equalsFoldCase(String anotherString) /** * Compares two strings lexicographically using Unicode case folding. * This method returns an integer whose sign is that of calling {@code compareTo} * on the Unicode case folded version of the strings. Unicode Case folding * eliminates differences in case according to the Unicode Standard, using the * mappings defined in * CaseFolding.txt, * including 1:M mappings, such as {@code"?"} ? {@code }"ss"}. *

* Case folding is a locale-independent, language-neutral form of case mapping, * primarily intended for caseless matching. Unlike {@link #compareToIgnoreCase(String)}, * which applies a simpler locale-insensitive uppercase mapping. This method * follows the Unicode full case folding, providing stable and * consistent results across all environments. *

* Note that this method does not take locale into account, and may * produce results that differ from locale-sensitive ordering. Use * {@link java.text.Collator} for locale-sensitive comparison. * * @apiNote * This method is the Unicode-compliant alternative to * {@link #compareToIgnoreCase(String)}. It implements the full case folding * as defined by the Unicode Standard, which may differ from the simpler * per-character mapping performed by {@code compareToIgnoreCase}. * For example: *

{@snippet lang=java :
     * String a = "Ma?e";
     * String b = "MASSE";
     * int cmpFoldCase = a.compareToFoldCase(b);     // returns 0
     * int cmpIgnoreCase = a.compareToIgnoreCase(b); // returns > 0
     * }

* * @param str the {@code String} to be compared. * @return a negative integer, zero, or a positive integer as the specified * String is greater than, equal to, or less than this String, * ignoring case considerations by case folding. * @see #equalsFoldCase(String) * @see #compareToIgnoreCase(String) * @see java.text.Collator * @since 26 */ public int compareToFoldCase(String str) /** * A Comparator that orders {@code String} objects as by * {@link #compareToFoldCase(String) compareToFoldCase()}. * * @see #compareToFoldCase(String) * @since 26 */ public static final Comparator UNICODE_CASEFOLD_ORDER; ### Usage Examples Sharp s (U+00DF) case-folds to "ss" "stra?e".equalsIgnoreCase("strasse"); // false "stra?e".compareToIgnoreCase("strasse"); // != 0 "stra?e".equalsFoldCase("strasse"); // true ### Performance The JMH microbenchmark StringCompareToIgnoreCase has been updated to compare performance of compareToFoldCase with the existing compareToIgnoreCase(). Benchmark Mode Cnt Score Error Units StringCompareToIgnoreCase.asciiGreekLower avgt 15 20.195 ? 0.300 ns/op StringCompareToIgnoreCase.asciiGreekLowerCF avgt 15 11.051 ? 0.254 ns/op StringCompareToIgnoreCase.asciiGreekUpperLower avgt 15 6.035 ? 0.047 ns/op StringCompareToIgnoreCase.asciiGreekUpperLowerCF avgt 15 14.786 ? 0.382 ns/op StringCompareToIgnoreCase.asciiLower avgt 15 17.688 ? 1.396 ns/op StringCompareToIgnoreCase.asciiLowerCF avgt 15 44.552 ? 0.155 ns/op StringCompareToIgnoreCase.asciiUpperLower avgt 15 13.069 ? 0.487 ns/op StringCompareToIgnoreCase.asciiUpperLowerCF avgt 15 58.684 ? 0.274 ns/op StringCompareToIgnoreCase.greekLower avgt 15 20.642 ? 0.082 ns/op StringCompareToIgnoreCase.greekLowerCF avgt 15 7.255 ? 0.271 ns/op StringCompareToIgnoreCase.greekUpperLower avgt 15 5.737 ? 0.013 ns/op StringCompareToIgnoreCase.greekUpperLowerCF avgt 15 11.100 ? 1.147 ns/op StringCompareToIgnoreCase.lower avgt 15 20.192 ? 0.044 ns/op StringCompareToIgnoreCase.lowerrCF avgt 15 11.257 ? 0.259 ns/op StringCompareToIgnoreCase.supLower avgt 15 54.801 ? 0.415 ns/op StringCompareToIgnoreCase.supLowerCF avgt 15 15.207 ? 0.418 ns/op StringCompareToIgnoreCase.supUpperLower avgt 15 14.431 ? 0.188 ns/op StringCompareToIgnoreCase.supUpperLowerCF avgt 15 19.149 ? 0.985 ns/op StringCompareToIgnoreCase.upperLower avgt 15 5.650 ? 0.051 ns/op StringCompareToIgnoreCase.upperLowerCF avgt 15 14.338 ? 0.352 ns/op StringCompareToIgnoreCase.utf16SubLower avgt 15 14.774 ? 0.200 ns/op StringCompareToIgnoreCase.utf16SubLowerCF avgt 15 2.669 ? 0.041 ns/op StringCompareToIgnoreCase.utf16SupUpperLower avgt 15 16.250 ? 0.099 ns/op StringCompareToIgnoreCase.utf16SupUpperLowerCF avgt 15 11.524 ? 0.327 ns/op ### Refs [Unicode Standard 5.18.4 Caseless Matching](https://www.unicode.org/versions/latest/core-spec/chapter-5/#G21790) [Unicode? Standard Annex #44: 5.6 Case and Case Mapping](https://www.unicode.org/reports/tr44/#Casemapping) [Unicode Technical Standard #18: Unicode Regular Expressions RL1.5: Simple Loose Matches](https://www.unicode.org/reports/tr18/#Simple_Loose_Matches) [Unicode SpecialCasing.txt](https://www.unicode.org/Public/UCD/latest/ucd/SpecialCasing.txt) [Unicode CaseFolding.txt](https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt) ### Other Languages **Python string.casefold()** The str.casefold() method in Python returns a casefolded version of a string. Casefolding is a more aggressive form of lowercasing, designed to remove all case distinctions in a string, particularly for the purpose of caseless string comparisons. **Perl?s fc()** Returns the casefolded version of EXPR. This is the internal function implementing the \F escape in double-quoted strings. Casefolding is the process of mapping strings to a form where case differences are erased; comparing two strings in their casefolded form is effectively a way of asking if two strings are equal, regardless of case. Perl only implements the full form of casefolding, but you can access the simple folds using "casefold()" in Unicode::UCD] ad "prop_invmap()" in Unicode::UCD]. **ICU4J UCharacter.foldCase (Java)** Purpose: Provides extensions to the standard Java Character class, including support for more Unicode properties and handling of supplementary characters (code points beyond U+FFFF). Method Signature (String based): public static String foldCase(String str, int options) Method Signature (CharSequence & Appendable based): public static A foldCase(CharSequence src, A dest, int options, Edits edits) Key Features: Case Folding: Converts a string to its case-folded equivalent. Locale Independent: Case folding in UCharacter.foldCase is generally not dependent on locale settings. Context Insensitive: The mapping of a character is not affected by surrounding characters. Turkic Option: An option exists to include or exclude special mappings for Turkish/Azerbaijani text. Result Length: The resulting string can be longer or shorter than the original. Edits Recording: Allows for recording of edits for index mapping, styled text, and getting only changes. **u_strFoldCase (C/C++)** A lower-level C API function for case folding a string. Case Folding Options: Similar options as UCharacter.foldCase for controlling case folding behavior. Availability: Found in the ustring.h and unistr.h headers in the ICU4C library. ------------- Commit messages: - 8365675: Add String Unicode Case-Folding Support Changes: https://git.openjdk.org/jdk/pull/26892/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26892&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365675 Stats: 1279 lines in 12 files changed: 1116 ins; 137 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/26892.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26892/head:pull/26892 PR: https://git.openjdk.org/jdk/pull/26892 From kdnilsen at openjdk.org Fri Oct 3 19:49:41 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 3 Oct 2025 19:49:41 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet [v13] In-Reply-To: References: Message-ID: > This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet. In the new code, we keep a single tally of relevant information within ShenandoahFreeSet. > Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet. > > This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies. These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms. > > The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books. Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: revert introduction of index_type ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26867/files - new: https://git.openjdk.org/jdk/pull/26867/files/43e1358f..f4dadd43 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=11-12 Stats: 244 lines in 7 files changed: 10 ins; 2 del; 232 mod Patch: https://git.openjdk.org/jdk/pull/26867.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867 PR: https://git.openjdk.org/jdk/pull/26867 From kdnilsen at openjdk.org Fri Oct 3 19:49:44 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 3 Oct 2025 19:49:44 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet [v3] In-Reply-To: References:

Message-ID: On Fri, 3 Oct 2025 20:31:10 GMT, Kelvin Nilsen wrote: >> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected. In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region. This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint. >> >> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated. In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended. >> >> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > remove _mixed_candidate_garbage_words from ShenandoahHeapRegion Retesting through internal CI pipeline ------------- PR Comment: https://git.openjdk.org/jdk/pull/24319#issuecomment-3367185418 From kdnilsen at openjdk.org Fri Oct 3 20:53:50 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 3 Oct 2025 20:53:50 GMT Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need accurate live_data [v10] In-Reply-To: References: <5T0PXD1oxDN6BXnflm0DFQdBFEfUC95ds21spzVzwMw=.3a538ff0-53da-4397-887d-73ffa98bb9ef@github.com>

Message-ID: <_Bh5NmZkINYluZJrPU4CmqttX3tl5oMy49WCjoJD_sw=.abe539ff-f71b-4360-b157-e14853d26b72@github.com> On Fri, 3 Oct 2025 20:27:26 GMT, Kelvin Nilsen wrote: >> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp line 262: >> >>> 260: volatile size_t _critical_pins; >>> 261: >>> 262: size_t _mixed_candidate_garbage_words; >> >> Can we delete this field now? > > Good catch. Removed. Thanks. Done. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24319#discussion_r2403313761 From kdnilsen at openjdk.org Fri Oct 3 22:07:53 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 3 Oct 2025 22:07:53 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet [v14] In-Reply-To: References:

Message-ID: On Fri, 3 Oct 2025 20:09:30 GMT, Kelvin Nilsen wrote: >> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet. In the new code, we keep a single tally of relevant information within ShenandoahFreeSet. >> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet. >> >> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies. These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms. >> >> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > simplify implementation of promote_in_place src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 136: > 134: > 135: #ifndef PRODUCT > 136: void dump_bitmap_row(idx_t region_idx) const; maybe revert this. bitmap rows are not idx_t. src/hotspot/share/gc/shenandoah/shenandoahGeneration.hpp line 71: > 69: // Usage > 70: > 71: volatile size_t _used; Get rid of this. no longer needed. (search for volatile, most should go.) do we need _max_capacity? probably not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2403455453 PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2403449921 From kdnilsen at openjdk.org Fri Oct 3 22:07:55 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Fri, 3 Oct 2025 22:07:55 GMT Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet [v3] In-Reply-To: References:

Message-ID: On Thu, 2 Oct 2025 23:31:35 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahGenerationalEvacuationTask.cpp line 253: >> >>> 251: if (available_in_region < plab_min_size_in_bytes) { >>> 252: // The available memory in young had been retired. Retire it in old also. >>> 253: region_to_be_used_in_old += available_in_region; >> >> This looks like a dead store. > > This chunk of code from 253-258 looks like it could be removed. You're right. We can simplify this. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2403216907 From wkemper at openjdk.org Fri Oct 3 23:26:05 2025 From: wkemper at openjdk.org (William Kemper) Date: Fri, 3 Oct 2025 23:26:05 GMT Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation size budgeting Message-ID: Notable changes: * Improvements to logging * More accurate tracking of promotion failures * Use shared allocation for promotions only when the size is above the maximum plab size (not the minimum size) * Use census information gathered during mark to size promotion reserves and old generation With these changes, GenShen is expected to have fewer promotion failures and this is indeed the case. As a result of this, we expect less time to be spent in concurrent marking and update refs for young collections. We may also expect shorter concurrent evacuation phases because GenShen will have fewer densely packed regions stuck in the young generation. With more objects being promoted, we also expect to see longer remembered set scan times. This is generally the case across all benchmarks, but we do also see some counter-intuitive results. Here we are comparing 20 executions (10 on x86, 10 on aarch64) of the changes in the PR (experiment) against 20 executions of the same benchmarks results from tip. This is a summary of statistically significant changes of more than 5% across all benchmarks: Concurrent Evacuation: 7 improvements, 3 regressions ? Best improvements: extremem-large-45g (-29.6%), neo4j-analytics (-26.9%) ? Worst regression: xalan (+53.7%) Concurrent Marking: 15 improvements, 1 regression ? Best improvements: hyperalloc_a2048_o4096 (-30.1%), crypto.rsa (-27.3%) ? Only regression: serial (+8.9%) Concurrent Scan Remembered Set: 7 improvements, 2 regressions ? Best improvements: xalan (-49.4%), pmd (-49.0%), crypto.rsa (-41.8%) ? Worst regression: extremem-phased (+52.4%) Concurrent Update Refs: 5 improvements, 4 regressions ? Best improvements: crypto.rsa (-36.4%), mnemonics (-28.4%) ? Worst regression: xalan (+89.4%) ------------- Commit messages: - Little cleanup - Fix wrong asserts - Only use old generation in generational mode - More accurate method names for cset fields, consider promotion reserves when computing excess old regions - Merge fallout - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements - Tweak comment - Merge remote-tracking branch 'jdk/master' into make-evac-tracking-runtime-option - Merge remote-tracking branch 'earthling-jdk/adaptive-tenuring-threshold' into make-evac-tracking-runtime-option - ... and 42 more: https://git.openjdk.org/jdk/compare/648582ab...fd9619dd Changes: https://git.openjdk.org/jdk/pull/27632/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27632&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314599 Stats: 292 lines in 16 files changed: 145 ins; 72 del; 75 mod Patch: https://git.openjdk.org/jdk/pull/27632.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27632/head:pull/27632 PR: https://git.openjdk.org/jdk/pull/27632 From wkemper at openjdk.org Fri Oct 3 23:35:48 2025 From: wkemper at openjdk.org (William Kemper) Date: Fri, 3 Oct 2025 23:35:48 GMT Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need accurate live_data [v11] In-Reply-To: References:

Message-ID: On Fri, 3 Oct 2025 20:31:10 GMT, Kelvin Nilsen wrote: >> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected. In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region. This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint. >> >> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated. In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended. >> >> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions. > > Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision: > > remove _mixed_candidate_garbage_words from ShenandoahHeapRegion Code looks good to me. Let's double check performance results (especially for non-generational mode). ------------- Marked as reviewed by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24319#pullrequestreview-3301312685