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: On Tue, 14 Oct 2025 20:23:33 GMT, Patricio Chilano Mateo wrote: >> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized. >> >> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too. >> >> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`. >> >> ### Summary of implementation >> >> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too. >> >> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). >> >> ### Notes >> >> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon... > > Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge branch 'master' into JDK-8369238 > - RISC-V support > - Fix whitespaces > - v1 Great enhancement indeed @pchilano! The ppc part of it is almost finished. Unfortunately I'm stuck with a problem in verification code already in initial testing. Please see my comment on `verify_frame_kind`. src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1751: > 1749: RegisterMap::ProcessFrames::skip, > 1750: RegisterMap::WalkContinuation::skip); > 1751: frame fr = top.sender(®_map); I think there's a problem here. I get an assertion on ppc if `top` is a heap frame (calling from `log_preempt_after_freeze`) because in `frame::sender_raw()` we don't take the path we normally would for a frame on heap. Instead `sender_for_compiled_frame()` is called which uses a constructor that asserts alignment of `sp` (see [here](https://github.com/openjdk/jdk/blob/1bd814c3b24eb7ef5633ee34bb418e0981ca1708/src/hotspot/cpu/ppc/frame_ppc.inline.hpp#L81-L86)). The assertion fails because `_on_heap` is false but should be `true`. I think in `sender_raw` `map->in_cont()` should return true if this frame is on heap. It's not quite easy to fix though since `top` can also be on stack. ------------- PR Review: https://git.openjdk.org/jdk/pull/27802#pullrequestreview-3341440114 PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2433336330 From valeriep at openjdk.org Wed Oct 15 17:58:38 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 15 Oct 2025 17:58:38 GMT Subject: RFR: 8326609: New AES implementation with updates specified in FIPS 197 [v4] In-Reply-To: References:

<-QG-DjJMOsPrJDY4lSgr0jOrcwEH_40FmvRgt4CQW90=.df69e912-a5e1-4574-a70d-b30e855c1dcc@github.com> Message-ID: <8Hb0rpkClUOY9-wId7h9oVsyZx6Q1BfCKKEshQ8u6PA=.c3a9339b-0567-47bb-a2f2-92836e1af493@github.com> On Wed, 15 Oct 2025 18:45:24 GMT, Valerie Peng wrote: >> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision: >> >> Add remaining files to be staged > > src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 55: > >> 53: >> 54: private static final int AES_256_ROUNDS = 14; >> 55: private static final int AES_256_NKEYS = 32; > > The `AES_XXX_NKEYS` constants (valued 16, 24, 32) are also defined in `AESConstants` class, maybe we can just refer to that class instead of duplicate the definition here? Or, merge the values defined in `AESConstants` into this class. Either way is fine with me as long as no duplicated values. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2433622686 From pchilanomate at openjdk.org Wed Oct 15 19:35:50 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 15 Oct 2025 19:35:50 GMT Subject: RFR: 8369238: Allow virtual thread preemption on some common class initialization paths [v2] In-Reply-To: References:

Message-ID: On Wed, 15 Oct 2025 16:54:42 GMT, Richard Reingruber wrote: >> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: >> >> - Merge branch 'master' into JDK-8369238 >> - RISC-V support >> - Fix whitespaces >> - v1 > > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1751: > >> 1749: RegisterMap::ProcessFrames::skip, >> 1750: RegisterMap::WalkContinuation::skip); >> 1751: frame fr = top.sender(®_map); > > I think there's a problem here. I get an assertion on ppc if `top` is a heap frame (calling from `log_preempt_after_freeze`) because in `frame::sender_raw()` we don't take the path we normally would for a frame on heap. Instead `sender_for_compiled_frame()` is called which uses a constructor that asserts alignment of `sp` (see [here](https://github.com/openjdk/jdk/blob/1bd814c3b24eb7ef5633ee34bb418e0981ca1708/src/hotspot/cpu/ppc/frame_ppc.inline.hpp#L81-L86)). The assertion fails because `_on_heap` is false but should be `true`. > > I think in `sender_raw` `map->in_cont()` should return true if this frame is on heap. > > It's not quite easy to fix though since `top` can also be on stack. Right, it should be walked as a heap frame. Could you verify if this patch fixes the issue? diff --git a/src/hotspot/share/runtime/continuationFreezeThaw.cpp b/src/hotspot/share/runtime/continuationFreezeThaw.cpp index 86c56fe583f..fb1f66c60f4 100644 --- a/src/hotspot/share/runtime/continuationFreezeThaw.cpp +++ b/src/hotspot/share/runtime/continuationFreezeThaw.cpp @@ -196,7 +196,7 @@ static bool do_verify_after_thaw(JavaThread* thread, stackChunkOop chunk, output static void log_frames(JavaThread* thread, bool dolog = true); static void log_frames_after_thaw(JavaThread* thread, ContinuationWrapper& cont, intptr_t* sp); static void print_frame_layout(const frame& f, bool callee_complete, outputStream* st = tty); -static void verify_frame_kind(const frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr = nullptr, const char** code_name_ptr = nullptr, int* bci_ptr = nullptr); +static void verify_frame_kind(frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr = nullptr, const char** code_name_ptr = nullptr, int* bci_ptr = nullptr, stackChunkOop chunk = nullptr); #define assert_pfl(p, ...) \ do { \ @@ -1723,7 +1723,7 @@ bool FreezeBase::check_valid_fast_path() { return true; } -static void verify_frame_kind(const frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr, const char** code_name_ptr, int* bci_ptr) { +static void verify_frame_kind(frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr, const char** code_name_ptr, int* bci_ptr, stackChunkOop chunk) { Method* m; const char* code_name; int bci; @@ -1747,7 +1747,13 @@ static void verify_frame_kind(const frame& top, Continuation::preempt_kind preem RegisterMap reg_map(current, RegisterMap::UpdateMap::skip, RegisterMap::ProcessFrames::skip, - RegisterMap::WalkContinuation::skip); + RegisterMap::WalkContinuation::include); + if (top.is_heap_frame()) { + assert(chunk != nullptr, ""); + reg_map.set_stack_chunk(chunk); + top = chunk->relativize(top); + top.set_frame_index(0); + } frame fr = top.sender(®_map); vframe* vf = vframe::new_vframe(&fr, ®_map, current); compiledVFrame* cvf = compiledVFrame::cast(vf); @@ -1803,7 +1809,7 @@ static void log_preempt_after_freeze(ContinuationWrapper& cont) { Method* m = nullptr; const char* code_name = nullptr; int bci = InvalidFrameStateBci; - verify_frame_kind(top_frame, pk, &m, &code_name, &bci); + verify_frame_kind(top_frame, pk, &m, &code_name, &bci, cont.tail()); assert(m != nullptr && code_name != nullptr && bci != InvalidFrameStateBci, "should be set"); ResourceMark rm(current); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2433721003 From valeriep at openjdk.org Wed Oct 15 20:48:45 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 15 Oct 2025 20:48:45 GMT Subject: RFR: 8326609: New AES implementation with updates specified in FIPS 197 [v4] In-Reply-To: References:

Message-ID: On Wed, 15 Oct 2025 17:55:58 GMT, Valerie Peng wrote: >> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision: >> >> Add remaining files to be staged > > src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 43: > >> 41: * https://www.internationaljournalcorner.com/index.php/ijird_ojs/article/view/134688 >> 42: */ >> 43: public final class AES_Crypt extends SymmetricCipher { > > This internal class does not need to be public? I'd assume it's only used within the same package? You're right, it doesn't appear to be used externally. Fixed. > src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 920: > >> 918: if (prevKey != null) { >> 919: Arrays.fill(prevKey, (byte) 0); >> 920: } > > Can be moved down to be right before `prevKey = key.clone()` call? This way, `sessionK` assignments are together and not separated by this call It can be and I agree. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434164829 PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434165068 From duke at openjdk.org Wed Oct 15 23:04:13 2025 From: duke at openjdk.org (Shawn M Emery) Date: Wed, 15 Oct 2025 23:04:13 GMT Subject: RFR: 8326609: New AES implementation with updates specified in FIPS 197 [v4] In-Reply-To: <8Hb0rpkClUOY9-wId7h9oVsyZx6Q1BfCKKEshQ8u6PA=.c3a9339b-0567-47bb-a2f2-92836e1af493@github.com> References:

<-QG-DjJMOsPrJDY4lSgr0jOrcwEH_40FmvRgt4CQW90=.df69e912-a5e1-4574-a70d-b30e855c1dcc@github.com> <8Hb0rpkClUOY9-wId7h9oVsyZx6Q1BfCKKEshQ8u6PA=.c3a9339b-0567-47bb-a2f2-92836e1af493@github.com> Message-ID: On Wed, 15 Oct 2025 18:51:29 GMT, Valerie Peng wrote: >> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 55: >> >>> 53: >>> 54: private static final int AES_256_ROUNDS = 14; >>> 55: private static final int AES_256_NKEYS = 32; >> >> The `AES_XXX_NKEYS` constants (valued 16, 24, 32) are also defined in `AESConstants` class, maybe we can just refer to that class instead of duplicate the definition here? > > Or, merge the values defined in `AESConstants` into this class. Either way is fine with me as long as no duplicated values. I've made the update that references the AESConstants to avoid duplication. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2434164972 From valeriep at openjdk.org Wed Oct 15 23:31:03 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 15 Oct 2025 23:31:03 GMT Subject: RFR: 8326609: New AES implementation with updates specified in FIPS 197 [v4] In-Reply-To: <7faVZ8RHcws5sOoA1rfBrE3f7ON__bKvBCra2R3rLNU=.dfd5d4f3-7506-4d99-9ba5-ccb0b4ca0184@github.com> References:

Message-ID: On Wed, 15 Oct 2025 19:33:26 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1751: >> >>> 1749: RegisterMap::ProcessFrames::skip, >>> 1750: RegisterMap::WalkContinuation::skip); >>> 1751: frame fr = top.sender(®_map); >> >> I think there's a problem here. I get an assertion on ppc if `top` is a heap frame (calling from `log_preempt_after_freeze`) because in `frame::sender_raw()` we don't take the path we normally would for a frame on heap. Instead `sender_for_compiled_frame()` is called which uses a constructor that asserts alignment of `sp` (see [here](https://github.com/openjdk/jdk/blob/1bd814c3b24eb7ef5633ee34bb418e0981ca1708/src/hotspot/cpu/ppc/frame_ppc.inline.hpp#L81-L86)). The assertion fails because `_on_heap` is false but should be `true`. >> >> I think in `sender_raw` `map->in_cont()` should return true if this frame is on heap. >> >> It's not quite easy to fix though since `top` can also be on stack. > > Right, it should be walked as a heap frame. Could you verify if this patch fixes the issue? > > > diff --git a/src/hotspot/share/runtime/continuationFreezeThaw.cpp b/src/hotspot/share/runtime/continuationFreezeThaw.cpp > index 86c56fe583f..fb1f66c60f4 100644 > --- a/src/hotspot/share/runtime/continuationFreezeThaw.cpp > +++ b/src/hotspot/share/runtime/continuationFreezeThaw.cpp > @@ -196,7 +196,7 @@ static bool do_verify_after_thaw(JavaThread* thread, stackChunkOop chunk, output > static void log_frames(JavaThread* thread, bool dolog = true); > static void log_frames_after_thaw(JavaThread* thread, ContinuationWrapper& cont, intptr_t* sp); > static void print_frame_layout(const frame& f, bool callee_complete, outputStream* st = tty); > -static void verify_frame_kind(const frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr = nullptr, const char** code_name_ptr = nullptr, int* bci_ptr = nullptr); > +static void verify_frame_kind(frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr = nullptr, const char** code_name_ptr = nullptr, int* bci_ptr = nullptr, stackChunkOop chunk = nullptr); > > #define assert_pfl(p, ...) \ > do { \ > @@ -1723,7 +1723,7 @@ bool FreezeBase::check_valid_fast_path() { > return true; > } > > -static void verify_frame_kind(const frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr, const char** code_name_ptr, int* bci_ptr) { > +static void verify_frame_kind(frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr, const char** code_name_ptr, int* bci_ptr, stackChunkOop chunk) { > Method* m; > const char* code_name; > int bci; > @@ -1747,7 +1747,13 @@ static void verify_frame_kind(const frame& top, Continuation::preempt_kind preem > RegisterMap reg_map(current, > RegisterMap::UpdateMap::skip, > RegisterMap::ProcessFrames::skip, > - RegisterMap::WalkContinuation::skip); > + RegisterMap::WalkContinuation::include); > + if (top.is_heap_frame()) { > + assert(chunk != nullptr, ""); > + reg_map.set_stack_chunk(chunk); > + top = chunk->relativize(top); > + top.set_frame_index(0); > + } > frame fr = top.sender(®_map); > vframe* vf = vframe::new_vframe(&fr, ®_map, current); > compiledVFrame* cvf = compiledVFrame::cast(vf); > @@ -1803,7 +1809,7 @@ static void log_preempt_after_freeze(ContinuationWrapper& cont) { > Method* m = nullptr; > const char* code_name = nu... Your patch fixes the issue. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2434828305 From aph at openjdk.org Thu Oct 16 09:08:13 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 16 Oct 2025 09:08:13 GMT Subject: RFR: 8369238: Allow virtual thread preemption on some common class initialization paths [v2] In-Reply-To: References:

Message-ID: On Tue, 14 Oct 2025 20:23:33 GMT, Patricio Chilano Mateo wrote: >> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized. >> >> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too. >> >> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`. >> >> ### Summary of implementation >> >> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too. >> >> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). >> >> ### Notes >> >> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon... > > Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge branch 'master' into JDK-8369238 > - RISC-V support > - Fix whitespaces > - v1 src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 209: > 207: // the last_sp saved in the frame (remove possible alignment added while > 208: // thawing, see ThawBase::finish_thaw()). We also need to clear the last_sp > 209: // saved in the frame as it is not expected to be set in case we preempt again. A bit stronger? Suggestion: // saved in the frame because it must be clear if we freeze again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2435147223 From pchilanomate at openjdk.org Thu Oct 16 16:13:43 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 16 Oct 2025 16:13:43 GMT Subject: RFR: 8369238: Allow virtual thread preemption on some common class initialization paths [v2] In-Reply-To: References:

Message-ID: On Thu, 16 Oct 2025 07:15:33 GMT, Richard Reingruber wrote: >> Right, it should be walked as a heap frame. Could you verify if this patch fixes the issue? >> >> >> diff --git a/src/hotspot/share/runtime/continuationFreezeThaw.cpp b/src/hotspot/share/runtime/continuationFreezeThaw.cpp >> index 86c56fe583f..fb1f66c60f4 100644 >> --- a/src/hotspot/share/runtime/continuationFreezeThaw.cpp >> +++ b/src/hotspot/share/runtime/continuationFreezeThaw.cpp >> @@ -196,7 +196,7 @@ static bool do_verify_after_thaw(JavaThread* thread, stackChunkOop chunk, output >> static void log_frames(JavaThread* thread, bool dolog = true); >> static void log_frames_after_thaw(JavaThread* thread, ContinuationWrapper& cont, intptr_t* sp); >> static void print_frame_layout(const frame& f, bool callee_complete, outputStream* st = tty); >> -static void verify_frame_kind(const frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr = nullptr, const char** code_name_ptr = nullptr, int* bci_ptr = nullptr); >> +static void verify_frame_kind(frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr = nullptr, const char** code_name_ptr = nullptr, int* bci_ptr = nullptr, stackChunkOop chunk = nullptr); >> >> #define assert_pfl(p, ...) \ >> do { \ >> @@ -1723,7 +1723,7 @@ bool FreezeBase::check_valid_fast_path() { >> return true; >> } >> >> -static void verify_frame_kind(const frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr, const char** code_name_ptr, int* bci_ptr) { >> +static void verify_frame_kind(frame& top, Continuation::preempt_kind preempt_kind, Method** m_ptr, const char** code_name_ptr, int* bci_ptr, stackChunkOop chunk) { >> Method* m; >> const char* code_name; >> int bci; >> @@ -1747,7 +1747,13 @@ static void verify_frame_kind(const frame& top, Continuation::preempt_kind preem >> RegisterMap reg_map(current, >> RegisterMap::UpdateMap::skip, >> RegisterMap::ProcessFrames::skip, >> - RegisterMap::WalkContinuation::skip); >> + RegisterMap::WalkContinuation::include); >> + if (top.is_heap_frame()) { >> + assert(chunk != nullptr, ""); >> + reg_map.set_stack_chunk(chunk); >> + top = chunk->relativize(top); >> + top.set_frame_index(0); >> + } >> frame fr = top.sender(®_map); >> vframe* vf = vframe::new_vframe(&fr, ®_map, current); >> compiledVFrame* cvf = compiledVFrame::cast(vf); >> @@ -1803,7 +1809,7 @@ static void log_preempt_after_freeze(... > > Your patch fixes the issue. Thanks! Great, pushed fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2436600849 From pchilanomate at openjdk.org Thu Oct 16 16:13:42 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 16 Oct 2025 16:13:42 GMT Subject: RFR: 8369238: Allow virtual thread preemption on some common class initialization paths [v3] In-Reply-To: References: Message-ID: > If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized. > > As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too. > > This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`. > > ### Summary of implementation > > The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too. > > If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). > > ### Notes > > `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::monitorenter`, was renamed to `In... Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: fix verify_frame_kind ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27802/files - new: https://git.openjdk.org/jdk/pull/27802/files/79fce80f..ac557152 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27802&range=01-02 Stats: 10 lines in 1 file changed: 6 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27802.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27802/head:pull/27802 PR: https://git.openjdk.org/jdk/pull/27802 From pchilanomate at openjdk.org Thu Oct 16 16:26:09 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 16 Oct 2025 16:26:09 GMT Subject: RFR: 8369238: Allow virtual thread preemption on some common class initialization paths [v2] In-Reply-To: References:

Message-ID: On Thu, 16 Oct 2025 09:05:24 GMT, Andrew Haley wrote: >> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: >> >> - Merge branch 'master' into JDK-8369238 >> - RISC-V support >> - Fix whitespaces >> - v1 > > src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 209: > >> 207: // the last_sp saved in the frame (remove possible alignment added while >> 208: // thawing, see ThawBase::finish_thaw()). We also need to clear the last_sp >> 209: // saved in the frame as it is not expected to be set in case we preempt again. > > A bit stronger? > Suggestion: > > // saved in the frame because it must be clear if we freeze again. Just to add more context, not clearing last_sp will make this assert [1] fire if we freeze again. That assert is mostly a verification check, because we know the interpreter doesn?t set last_sp for the top frame when calling into the VM. But I don?t see a fundamental reason why it must be cleared (removing the assert and not clearing last_sp works). I don?t see any other code that checks last_sp needs to be cleared for the top frame (other than in the interpreter before calling into the VM). How about changing that last sentence with: `We also clear last_sp to match the behavior when calling the VM from the interpreter (we check for this in FreezeBase::prepare_freeze_interpreted_top_frame).` [1] https://github.com/openjdk/jdk/blob/87092ef1d97e00ddb6674b0e309f2f904d307604/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L136 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2436641958 From valeriep at openjdk.org Thu Oct 16 20:04:35 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 16 Oct 2025 20:04:35 GMT Subject: RFR: 8326609: New AES implementation with updates specified in FIPS 197 [v7] In-Reply-To: References:

Message-ID: On Thu, 16 Oct 2025 19:58:40 GMT, Valerie Peng wrote: >> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision: >> >> Updates for code review comments from @valeriepeng > > src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1040: > >> 1038: * @param p [in] the plaintext to be encrypted. >> 1039: * @param po [in] the plaintext offset in the array of bytes. >> 1040: * @param c [out] the encrypted ciphertext output. > > nit: ciphertext already implied to be encrypted. Maybe no need for the "encrypted" adj. Agreed. Fixed. > src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1195: > >> 1193: ^ T3[(ti0 >> 16) & 0xFF] & 0xFF0000 >> 1194: ^ T0[(ti1 >> 8) & 0xFF] & 0xFF00 >> 1195: ^ T1[ti2 & 0xFF] & 0xFF ^ K[w+3]; > > Here you always use the last 4 elements of `K`, so you can just use `w = K.length - 4` and no need to keep tracking it in the earlier 2 blocks. Agreed. I've changed decryption as well. Fixed. > src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 1220: > >> 1218: * @param c [in] the ciphertext to be decrypted. >> 1219: * @param co [in] the ciphertext offset in the array of bytes. >> 1220: * @param p [out] the decrypted plaintext output. > > nit: same comment for removing "decrypted" adj. Agreed. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2437361415 PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2437361126 PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2437362009 From valeriep at openjdk.org Fri Oct 17 05:44:04 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 17 Oct 2025 05:44:04 GMT Subject: RFR: 8326609: New AES implementation with updates specified in FIPS 197 [v8] In-Reply-To: References:

<2_eqasQo7DtbnrxwxuFYvl_yhVh7P6wzlxwPEl_DB-Q=.ff81a933-2c29-4d69-826b-d1ccf04d2e1c@github.com> Message-ID: <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com> On Fri, 17 Oct 2025 05:41:25 GMT, Valerie Peng wrote: >> Shawn M Emery has updated the pull request incrementally with one additional commit since the last revision: >> >> Updates for code review comments from @valeriepeng > > src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 911: > >> 909: } >> 910: sessionK[0] = genRoundKeys(key, rounds); >> 911: sessionK[1] = invGenRoundKeys(); > > Given the decryption round keys are somewhat based on the encryption round keys, we could combine these two methods into one, e.g. > > private static int[][] genRoundKeys(byte[] key, int rounds) { > int[][] ks = new int[2][]; // key schedule > > int wLen = (rounds + 1) * WB; > int nk = key.length / WB; > > // generate the round keys for encryption > int[] w = new int[wLen]; > for (int i = 0, j = 0; i < nk; i++, j+=4) { > w[i] = ((key[j] & 0xFF) << 24) > | ((key[j + 1] & 0xFF) << 16) > | ((key[j + 2] & 0xFF) << 8) > | (key[j + 3] & 0xFF); > } > for (int i = nk; i < wLen; i++) { > int tmp = w[i - 1]; > if (i % nk == 0) { > int rW = (tmp << 8) & 0xFFFFFF00 | (tmp >>> 24); > tmp = subWord(rW) ^ RCON[(i / nk) - 1]; > } else if ((nk > 6) && ((i % nk) == WB)) { > tmp = subWord(tmp); > } > w[i] = w[i - nk] ^ tmp; > } > ks[0] = w; > > // generate the decryption round keys based on encryption ones > int[] dw = new int[wLen]; > int[] temp = new int[WB]; > > // Intrinsics requires the inverse key expansion to be reverse order > // except for the first and last round key as the first two round keys > // are without a mix column transform. > for (int i = 1; i < rounds; i++) { > System.arraycopy(w, i * WB, temp, 0, WB); > invMixRKey(temp); > System.arraycopy(temp, 0, dw, wLen - (i * WB), WB); > } > // dw[0...3] <- w[0...3] AND dw[4...7] <- w[(wLen - 4)...(wLen -1)] > System.arraycopy(w, 0, dw, 0, WB); > System.arraycopy(w, wLen - WB, dw, WB, WB); > ks[1] = dw; > Arrays.fill(temp, 0); > > return ks; > } These two methods were only the few that I was able to make that were compact and singular in purpose (gen round key, gen inverse round key) code as the coding style guidelines espouse. The rest of the methods' construction were dictated by performance improvements, where compactness came at the cost of interpreter speed. > src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 958: > >> 956: * @return the processed round key row. >> 957: */ >> 958: private static int invMix(int[] state, int idx) { > > It seems that we can just use an `int` argument and make the callers do the array dereferencing. This way we can get rid of the temporary buffer inside `invMixRKey(int[])` as passing an integer to `invMix(int)` method will not affect the array, e.g. > > private static void invMixRKey(int[] state) { > state[0] = invMix(state[0]); > state[1] = invMix(state[1]); > state[2] = invMix(state[2]); > state[3] = invMix(state[3]); > } I've removed this method and inlined this logic in the invGenRoundKeys method. > src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 976: > >> 974: * @param state [in, out] the round key for inverse mix column processing. >> 975: */ >> 976: private static void invMixRKey(int[] state) { > > nit: name the method "invMixColumns(int[])". This name matches the spec psuedo code and goes better with the "state" argument name. Or use "invMixRoundKey(int[] roundKey)"? I've removed this method and inlined this logic in the invGenRoundKeys method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2438587221 PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2438587085 PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2438586207 From valeriep at openjdk.org Fri Oct 17 07:07:11 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 17 Oct 2025 07:07:11 GMT Subject: RFR: 8326609: New AES implementation with updates specified in FIPS 197 [v8] In-Reply-To: <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com> References:

<2_eqasQo7DtbnrxwxuFYvl_yhVh7P6wzlxwPEl_DB-Q=.ff81a933-2c29-4d69-826b-d1ccf04d2e1c@github.com> <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com> Message-ID: <3IhmbTDiDNPdMTe_K1OZx6sC67UGjObzOXwX8Ekp7pA=.0e742e44-4dba-4680-8f24-7321f8516071@github.com> On Fri, 17 Oct 2025 06:52:39 GMT, Shawn M Emery wrote: >> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 958: >> >>> 956: * @return the processed round key row. >>> 957: */ >>> 958: private static int invMix(int[] state, int idx) { >> >> It seems that we can just use an `int` argument and make the callers do the array dereferencing. This way we can get rid of the temporary buffer inside `invMixRKey(int[])` as passing an integer to `invMix(int)` method will not affect the array, e.g. >> >> private static void invMixRKey(int[] state) { >> state[0] = invMix(state[0]); >> state[1] = invMix(state[1]); >> state[2] = invMix(state[2]); >> state[3] = invMix(state[3]); >> } > > I've removed this method and inlined this logic in the invGenRoundKeys method. Sure, this works as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2438612714 From epeter at openjdk.org Fri Oct 17 13:02:04 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Fri, 17 Oct 2025 13:02:04 GMT Subject: RFR: 8326609: New AES implementation with updates specified in FIPS 197 [v9] In-Reply-To: References:

<2_eqasQo7DtbnrxwxuFYvl_yhVh7P6wzlxwPEl_DB-Q=.ff81a933-2c29-4d69-826b-d1ccf04d2e1c@github.com> <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com> Message-ID: On Fri, 17 Oct 2025 06:52:44 GMT, Shawn M Emery wrote: >> src/java.base/share/classes/com/sun/crypto/provider/AES_Crypt.java line 911: >> >>> 909: } >>> 910: sessionK[0] = genRoundKeys(key, rounds); >>> 911: sessionK[1] = invGenRoundKeys(); >> >> Given the decryption round keys are somewhat based on the encryption round keys, we could combine these two methods into one, e.g. >> >> private static int[][] genRoundKeys(byte[] key, int rounds) { >> int[][] ks = new int[2][]; // key schedule >> >> int wLen = (rounds + 1) * WB; >> int nk = key.length / WB; >> >> // generate the round keys for encryption >> int[] w = new int[wLen]; >> for (int i = 0, j = 0; i < nk; i++, j+=4) { >> w[i] = ((key[j] & 0xFF) << 24) >> | ((key[j + 1] & 0xFF) << 16) >> | ((key[j + 2] & 0xFF) << 8) >> | (key[j + 3] & 0xFF); >> } >> for (int i = nk; i < wLen; i++) { >> int tmp = w[i - 1]; >> if (i % nk == 0) { >> int rW = (tmp << 8) & 0xFFFFFF00 | (tmp >>> 24); >> tmp = subWord(rW) ^ RCON[(i / nk) - 1]; >> } else if ((nk > 6) && ((i % nk) == WB)) { >> tmp = subWord(tmp); >> } >> w[i] = w[i - nk] ^ tmp; >> } >> ks[0] = w; >> >> // generate the decryption round keys based on encryption ones >> int[] dw = new int[wLen]; >> int[] temp = new int[WB]; >> >> // Intrinsics requires the inverse key expansion to be reverse order >> // except for the first and last round key as the first two round keys >> // are without a mix column transform. >> for (int i = 1; i < rounds; i++) { >> System.arraycopy(w, i * WB, temp, 0, WB); >> invMixRKey(temp); >> System.arraycopy(temp, 0, dw, wLen - (i * WB), WB); >> } >> // dw[0...3] <- w[0...3] AND dw[4...7] <- w[(wLen - 4)...(wLen -1)] >> System.arraycopy(w, 0, dw, 0, WB); >> System.arraycopy(w, wLen - WB, dw, WB, WB); >> ks[1] = dw; >> Arrays.fill(temp, 0); >> >> return ks; >> } > > These two methods were only the few that I was able to make that were compact and singular in purpose (gen round key, gen inverse round key) code as the coding style guidelines espouse. The rest of the methods' construction were dictated by performance improvements, where compactness came at the cost of interpreter speed. I did make changes based on your code to eliminate len and updates to variable names. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2441096947 From valeriep at openjdk.org Fri Oct 17 20:21:02 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 17 Oct 2025 20:21:02 GMT Subject: RFR: 8326609: New AES implementation with updates specified in FIPS 197 [v8] In-Reply-To: References:

<2_eqasQo7DtbnrxwxuFYvl_yhVh7P6wzlxwPEl_DB-Q=.ff81a933-2c29-4d69-826b-d1ccf04d2e1c@github.com> <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com>

Message-ID: <7kU60fP_Aw4oiwfwMN48YfFwC70wVObcHQpSXqZvyC4=.5094fe4c-de7e-4a96-8000-121a9db66ae5@github.com> On Fri, 17 Oct 2025 20:18:24 GMT, Valerie Peng wrote: >> I did make changes based on your code to eliminate len and updates to variable names. > > Yes, I take a second look and maybe a smaller adjustments would work as well. E.g, > 1) nit: method name `invGenRoundKeys` -> `genInvRoundKeys` > 2) make this method static by passing `sessionKey[0]` and `rounds` as arguments, > 3) no need for `len` since it's always `WB` > 4) for the intermediate buffer of 4 words, can we not use `w` as this name is used in both the spec and genRoundKeys method as "Word array for the key schedule". It'd help people understand the code better if we adopt the same naming convention in "Algorithm 5 Pseudocode for KEYEXPANSIONEIC()", e.g. `temp` for the intermediate buffer and `dw` for the final result. Sorry, missed this comment in the melee. Re: 1) method name, agreed; 2) to static, agreed; 3) remove len, prior commit; 4) variable name alignment, agreed. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2442722654 From rrich at openjdk.org Mon Oct 20 06:33:02 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Mon, 20 Oct 2025 06:33:02 GMT Subject: RFR: 8369238: Allow virtual thread preemption on some common class initialization paths In-Reply-To: References:

Message-ID: <8SlbTQ-LN3PIBw1M6hERwi8KyA02Avg5KrYrZISR_4o=.5ef0f9a9-48ef-4a36-a2ef-ffb2b77863ec@github.com> On Fri, 17 Oct 2025 05:43:49 GMT, David Holmes wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> fix verify_frame_kind > > src/hotspot/share/interpreter/linkResolver.hpp line 192: > >> 190: }; >> 191: >> 192: enum class StaticMode : uint8_t { > > Need to think of a better name for this ... `ClassInitMode`? Yes, much better. Changed. > src/hotspot/share/interpreter/linkResolver.hpp line 195: > >> 193: dont_initialize_klass, >> 194: initialize_klass, >> 195: initialize_klass_preemptable > > And maybe more concisely: > Suggestion: > > dont_init > init > init_preemptable > > ? Yes, changed. > src/hotspot/share/oops/instanceKlass.cpp line 1284: > >> 1282: // Block preemption once we are the initializer thread. Unmounting now >> 1283: // would complicate the reentrant case (identity is platform thread). >> 1284: NoPreemptMark npm(THREAD); > > How does this affect unrelated "preemption" that may occur in the Java code called as part of ``? While executing the `` method the vthread is pinned because of the call_stub in the stack (freeze will fail if we try to unmount), regardless of this `NoPreemptMark`. So this is for the other places where it is preemptable, mainly when initializing the super klass below. > src/hotspot/share/oops/klass.hpp line 583: > >> 581: // initializes the klass >> 582: virtual void initialize(TRAPS); >> 583: virtual void initialize_preemptable(TRAPS); > > Can we not define these on `instanceKlass` instead of `klass`? Seems really odd to declare virtual methods for which the base class version should never be called (they should be pure virtuals in that case I would think?). Ok. Just to double check, casting to `InstanceKlass*` where we call `initialize_preemptable` for the `invokestatic` and `getstatic/putstatic` cases should be always safe right? I don?t see how we could get there for an `ArrayKlass`. > src/hotspot/share/runtime/continuationEntry.cpp line 117: > >> 115: assert(thread->has_last_Java_frame(), "Wrong place to use this assertion"); >> 116: >> 117: if (preempted) return true; > > I don't see the point of adding a new parameter just so the method can check it and return immediately. Shouldn't the caller be checking this? Right, fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2445862480 PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2445862813 PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2445864285 PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2445868222 PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2445869014 From pchilanomate at openjdk.org Mon Oct 20 19:23:16 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 20 Oct 2025 19:23:16 GMT Subject: RFR: 8369238: Allow virtual thread preemption on some common class initialization paths [v3] In-Reply-To: References:

<2_eqasQo7DtbnrxwxuFYvl_yhVh7P6wzlxwPEl_DB-Q=.ff81a933-2c29-4d69-826b-d1ccf04d2e1c@github.com> <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com> <3IhmbTDiDNPdMTe_K1OZx6sC67UGjObzOXwX8Ekp7pA=.0e742e44-4dba-4680-8f24-7321f8516071@github.com> Message-ID: <56yK_DbZSYd0QHrNIo3kAy5wxesDss6VTTB0Ii6q_JU=.12a00665-fd8d-4e44-a169-5fec560fc0b2@github.com> On Fri, 17 Oct 2025 07:04:47 GMT, Valerie Peng wrote: >> I've removed this method and inlined this logic in the invGenRoundKeys method. > > Sure, this works as well. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27807#discussion_r2446428127 From duke at openjdk.org Tue Oct 21 00:21:07 2025 From: duke at openjdk.org (Shawn M Emery) Date: Tue, 21 Oct 2025 00:21:07 GMT Subject: RFR: 8326609: New AES implementation with updates specified in FIPS 197 [v8] In-Reply-To: <5SGZrrpgKtrf7IKtfEDPFb4LnggKNoeaZpFVGuHu-p4=.1ec8dd26-e125-4c8a-ba22-9006c7da4024@github.com> References: