From fyang at openjdk.org Wed Oct 1 00:22:33 2025 From: fyang at openjdk.org (Fei Yang) Date: Wed, 1 Oct 2025 00:22:33 GMT Subject: RFR: 8367601: Remove held_monitor_count In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 09:43:51 GMT, Fredrik Bredberg wrote: > Since we have removed all other locking modes than lightweight locking (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)), we no longer need: > - `_held_monitor_count` > - `_parent_held_monitor_count` > - `_jni_monitor_count` > > This PR removes them from shared code as well as from `X86`, `AArch64`, `PowerPC` and `RISC-V`. > They are not present in other platforms. > > Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change. > `PowerPC` and `RISC-V` has been sanity checked using QEMU. RISC-V part of the change seems fine to me. My local hs:tier1-hs:tier3 passed with fastdebug build. ------------- Marked as reviewed by fyang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27570#pullrequestreview-3287111055 From fbredberg at openjdk.org Wed Oct 1 13:35:52 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 1 Oct 2025 13:35:52 GMT Subject: RFR: 8367601: Remove held_monitor_count [v2] In-Reply-To: References: Message-ID: > Since we have removed all other locking modes than lightweight locking (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)), we no longer need: > - `_held_monitor_count` > - `_parent_held_monitor_count` > - `_jni_monitor_count` > > This PR removes them from shared code as well as from `X86`, `AArch64`, `PowerPC` and `RISC-V`. > They are not present in other platforms. > > Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change. > `PowerPC` and `RISC-V` has been sanity checked using QEMU. Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: Update after review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27570/files - new: https://git.openjdk.org/jdk/pull/27570/files/f05981b1..a3f09e85 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27570&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27570&range=00-01 Stats: 16 lines in 4 files changed: 0 ins; 6 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/27570.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27570/head:pull/27570 PR: https://git.openjdk.org/jdk/pull/27570 From fbredberg at openjdk.org Wed Oct 1 13:39:56 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 1 Oct 2025 13:39:56 GMT Subject: RFR: 8367601: Remove held_monitor_count In-Reply-To: References:

Message-ID: On Tue, 30 Sep 2025 13:32:24 GMT, Martin Doerr wrote: >> Since we have removed all other locking modes than lightweight locking (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)), we no longer need: >> - `_held_monitor_count` >> - `_parent_held_monitor_count` >> - `_jni_monitor_count` >> >> This PR removes them from shared code as well as from `X86`, `AArch64`, `PowerPC` and `RISC-V`. >> They are not present in other platforms. >> >> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change. >> `PowerPC` and `RISC-V` has been sanity checked using QEMU. > > Looks correct (PPC64 and shared code changes) and tier1 has passed. Would be nice to clean up unused temp registers > > diff --git a/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp b/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp > index 0bcc24a23bf..9fe7e1f22ff 100644 > --- a/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp > +++ b/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp > @@ -1639,7 +1639,6 @@ static void fill_continuation_entry(MacroAssembler* masm, Register reg_cont_obj, > assert_different_registers(reg_cont_obj, reg_flags); > Register zero = R8_ARG6; > Register tmp2 = R9_ARG7; > - Register tmp3 = R10_ARG8; > > DEBUG_ONLY(__ block_comment("fill {")); > #ifdef ASSERT > @@ -1678,7 +1677,6 @@ static void fill_continuation_entry(MacroAssembler* masm, Register reg_cont_obj, > static void continuation_enter_cleanup(MacroAssembler* masm) { > Register tmp1 = R8_ARG6; > Register tmp2 = R9_ARG7; > - Register tmp3 = R10_ARG8; > > #ifdef ASSERT > __ block_comment("clean {"); > @@ -1689,8 +1687,8 @@ static void continuation_enter_cleanup(MacroAssembler* masm) { > > __ ld_ptr(tmp1, ContinuationEntry::parent_cont_fastpath_offset(), R1_SP); > __ st_ptr(tmp1, JavaThread::cont_fastpath_offset(), R16_thread); > - __ ld_ptr(tmp3, ContinuationEntry::parent_offset(), R1_SP); > - __ st_ptr(tmp3, JavaThread::cont_entry_offset(), R16_thread); > + __ ld_ptr(tmp2, ContinuationEntry::parent_offset(), R1_SP); > + __ st_ptr(tmp2, JavaThread::cont_entry_offset(), R16_thread); > DEBUG_ONLY(__ block_comment("} clean")); > } > > > Thanks for doing it for all platforms! @TheRealMDoerr > Would be nice to clean up unused temp registers Fixed those. > Thanks for doing it for all platforms! The same ways as eating different types of food enriches your life, so does programming for different CPUs. :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27570#issuecomment-3356372605 From fbredberg at openjdk.org Wed Oct 1 13:40:00 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 1 Oct 2025 13:40:00 GMT Subject: RFR: 8367601: Remove held_monitor_count [v2] In-Reply-To: References:

Message-ID: On Tue, 30 Sep 2025 15:51:14 GMT, Patricio Chilano Mateo wrote: >> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: >> >> Update after review > > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1742: > >> 1740: log_develop_debug(continuations)("PINNED due to critical section"); >> 1741: verify_continuation(cont.continuation()); >> 1742: freeze_result res = entry->is_pinned() ? freeze_pinned_cs : freeze_pinned_monitor; > > We can remove this and always return freeze_pinned_cs. We should remove freeze_pinned_monitor (there is a matching definition in Continuation.java). Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27570#discussion_r2394622676 From fbredberg at openjdk.org Wed Oct 1 14:13:35 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 1 Oct 2025 14:13:35 GMT Subject: RFR: 8367601: Remove held_monitor_count [v2] In-Reply-To: References:

Message-ID: On Wed, 1 Oct 2025 14:01:57 GMT, Martin Doerr wrote: >> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: >> >> Update after review > > I guess you want to update the Copyright headers eventually. @TheRealMDoerr > I guess you want to update the Copyright headers eventually. Think I updated all the years to 2025. `grep -i 'copyright' $(git diff --name-only master) | grep -i oracle` Did you see something I missed? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27570#issuecomment-3356537891 From mdoerr at openjdk.org Wed Oct 1 14:20:13 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 1 Oct 2025 14:20:13 GMT Subject: RFR: 8367601: Remove held_monitor_count [v2] In-Reply-To: References:

Message-ID: <2HZuTvrbG5DED7c-r-MBu-itrFiIzJiy4B2WCjXxdiw=.cb10434a-3390-4c48-b27f-ad0ac7e6092f@github.com> On Wed, 1 Oct 2025 14:01:57 GMT, Martin Doerr wrote: >> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: >> >> Update after review > > I guess you want to update the Copyright headers eventually. > @TheRealMDoerr > > > I guess you want to update the Copyright headers eventually. > > Think I updated all the years to 2025. `grep -i 'copyright' $(git diff --name-only master) | grep -i oracle` > > Did you see something I missed? I thought I had seen 2024 somewhere. But, I can't find it again. I guess I had looked at the wrong file. Your Copyright updates look fine. Sorry. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27570#issuecomment-3356572661 From mdoerr at openjdk.org Wed Oct 1 14:04:52 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 1 Oct 2025 14:04:52 GMT Subject: RFR: 8367601: Remove held_monitor_count [v2] In-Reply-To: References:

Message-ID: On Wed, 1 Oct 2025 13:35:52 GMT, Fredrik Bredberg wrote: >> Since we have removed all other locking modes than lightweight locking (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)), we no longer need: >> - `_held_monitor_count` >> - `_parent_held_monitor_count` >> - `_jni_monitor_count` >> >> This PR removes them from shared code as well as from `X86`, `AArch64`, `PowerPC` and `RISC-V`. >> They are not present in other platforms. >> >> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change. >> `PowerPC` and `RISC-V` has been sanity checked using QEMU. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > Update after review Looks good to me, thanks! ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27570#pullrequestreview-3289970713 From dlong at openjdk.org Thu Oct 2 00:54:54 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 2 Oct 2025 00:54:54 GMT Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v4] In-Reply-To: References: <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com> Message-ID: On Tue, 2 Sep 2025 21:09:27 GMT, Vladimir Ivanov wrote: >> Dean Long 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 seven additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into 8366461-mh-invoke >> - revert whitespace change >> - undo debug changes >> - cleanup >> - arm32 build >> - Merge branch 'openjdk:master' into 8366461-mh-invoke >> - first pass > > Nice cleanup! Looks good. @iwanowww , I think I need you to re-review the final version. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27059#issuecomment-3358642300 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 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 vlivanov at openjdk.org Thu Oct 2 20:52:48 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 2 Oct 2025 20:52:48 GMT Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v9] In-Reply-To: References:

Message-ID: On Fri, 26 Sep 2025 20:07:36 GMT, Dean Long wrote: >> At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)). > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Frame.java > > Co-authored-by: Manuel H?ssig Still looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27059#pullrequestreview-3296355729 From dlong at openjdk.org Thu Oct 2 22:24:02 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 2 Oct 2025 22:24:02 GMT Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v9] In-Reply-To: References:

Message-ID: <9wbYkH5F7FQqsuagYmsja5H-_YOZSel32FHZA0Ofet0=.e3faece6-0131-43e1-ae22-e9f50d81588f@github.com> On Fri, 26 Sep 2025 20:07:36 GMT, Dean Long wrote: >> At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)). > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Frame.java > > Co-authored-by: Manuel H?ssig Thanks Vladimir for the re-review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27059#issuecomment-3363412878 From dlong at openjdk.org Thu Oct 2 22:24:03 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 2 Oct 2025 22:24:03 GMT Subject: Integrated: 8366461: Remove obsolete method handle invoke logic In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 19:21:48 GMT, Dean Long wrote: > At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)). This pull request has now been integrated. Changeset: da7121af Author: Dean Long URL: https://git.openjdk.org/jdk/commit/da7121aff9eccb046b82a75093034f1cdbd9b9e4 Stats: 899 lines in 76 files changed: 22 ins; 825 del; 52 mod 8366461: Remove obsolete method handle invoke logic Reviewed-by: vlivanov, mhaessig ------------- PR: https://git.openjdk.org/jdk/pull/27059 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 fbredberg at openjdk.org Mon Oct 6 08:13:03 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Mon, 6 Oct 2025 08:13:03 GMT Subject: RFR: 8367601: Remove held_monitor_count [v2] In-Reply-To: References:

Message-ID: <30EG_sC2od4Xwsibk4Uv1XW_XROt9OtbYSaEDwFmycY=.c2c59c3b-dbfe-4d52-a353-08b7f41bab1d@github.com> On Thu, 25 Sep 2025 08:52:09 GMT, erifan wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Update callGenerator.hpp copyright year > > test/hotspot/jtreg/compiler/vectorapi/TestSliceOptValueTransforms.java line 45: > >> 43: public static final VectorSpecies SSP = ShortVector.SPECIES_PREFERRED; >> 44: public static final VectorSpecies ISP = IntVector.SPECIES_PREFERRED; >> 45: public static final VectorSpecies LSP = LongVector.SPECIES_PREFERRED; > > The implementation supports floating point types, but why doesn't the test include fp types? It might be better to consider **partial cases**. I looked at the aarch64 situation and found that different implementations are needed for partial and non-partial cases. The test indices in `test/jdk/jdk/incubator/vector/` are randomly generated, so it might be better to test different vector species here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2409431981