From dholmes at openjdk.org Mon Sep 1 00:59:46 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 1 Sep 2025 00:59:46 GMT Subject: RFR: 8366024: Remove unnecessary InstanceKlass::cast() [v2] In-Reply-To: References: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com> Message-ID: <26NJ6xwmV3vbZdHpM320sGwZHiJ8Mn7d3gtJ--Ygz2U=.551378e5-35ff-4162-8984-ec0b5b585984@github.com> On Wed, 27 Aug 2025 18:11:33 GMT, Ioi Lam wrote: >> We have a lot of `InstanceKlass::cast(k)` calls where `k` is statically known to be an `InstanceKlass`. I fixed many instances of this pattern: >> >> >> InstanceKlass* x = ....; >> Klass* s = x->super(); // should call java_super() >> InstanceKlass::cast(s)->xyz(); >> >> >> The `super()` method has a very confusing API. It has the return type of `Klass*` because for for an `ObjArrayKlass` like `[Ljava/lang/String;`: >> >> - `super()` returns `[Ljava/lang/Object;` >> - `java_super()` returns `Ljava/lang/Object;` >> >> However, for `[Ljava/lang/Object;`, all `TypeArrayKlasses` and all `InstanceKlasses`, `super()` and `java_super()` return an identical value of that always have the actual type of `InstanceKlass*`. >> >> See here about the difference between `super()` and `java_super()`: https://github.com/openjdk/jdk/blob/7b9969dc8f20989497ff617abb45543d182b684d/src/hotspot/share/oops/klass.hpp#L218-L221 >> >> Unfortunately, we have a lot of code that incorrectly uses `super()` instead of `java_super()`, which leads to ` InstanceKlass::cast()` calls. I tried to fixed a bunch of easy ones in this PR, although there are a few more to go. >> >> I also fixed some calls to `local_interafaces()->at()` that widens the return type for `InstanceKlass*` to `Klass*`, which may lead to unnecessary ` InstanceKlass::cast()` calls. >> >> I also removed the `Klass::superklass()` API. This was used only in a few places and all of them can be safely replaced with `Klass::java_super()`. >> >> To avoid confusion, I think we should rename `super()` to something more obvious, but let's do that in a future PR. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @adinn comment - remove InstanceKlass::cast() in edgeUtils.cpp This seems fine though I will also comment that `java_super` seems completely mis-named in relation to `super` as there is nothing more `Java` about it. The implementation of `java_super` for arrays is quite odd - I'm not sure when we don't care about the actual superclass and want to go straight to object. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26908#pullrequestreview-3171880405 From iklam at openjdk.org Mon Sep 1 01:01:35 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 1 Sep 2025 01:01:35 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v6] In-Reply-To: References: Message-ID: <6PEn-0OmUy07dFkwXP2h1ytoJFpt7ax4Q3KYOY6NEwk=.d56bf938-c47b-4be3-8e39-00f16ff6393f@github.com> > During the assembly phase of the AOT cache, we link and verify all classes that were loaded during the training run. When verifying a class like this: > > > class X { > A getA() { return new B(); } // Verifier requires B to be a subtype of A. > } > > > We remember `A` and `B` as the "verification dependencies" of `X`. A class will be excluded from the AOT cache if any of its verification dependencies are excluded. For example, `X` will be excluded if > > - `A` fails verification > - `B` is a signed class, which is always excluded from the AOT cache > > Conversely, if both `A` and `B` are included in the AOT cache, in the production run, they will be unconditionally loaded during VM bootstrap. Therefore, we can guarantee that the verification result computed for `X` will remain valid during the production run. > > Notes for reviewers: > > - The checks for verification dependencies are done inside `SystemDictionaryShared::check_exclusion_for_self_and_dependencies()`. These checks are done for both old and new classes. Since the dependencies can form a cyclic graph, the checks cannot be implemented with a simple recursion. See "Algorithm notes" in this function for details. > - The verification dependencies for "new" classes are already stored in `DumpTimeClassInfo::_verifier_constraints`. > - This PR adds code to record the verification dependencies for "old" classes into `DumpTimeClassInfo::_old_verifier_dependencies`, by intercepting `JVM_FindClassFromCaller()`. > - This new functionality (store old classes in linked state) is available only when using the AOT cache. For simplicity, this functionality is not available with the old CDS workflows. See comments in `CDSConfig::is_preserving_verification_dependencies()`. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: updated comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26754/files - new: https://git.openjdk.org/jdk/pull/26754/files/fc9e29c8..b5bd8123 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26754&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26754&range=04-05 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26754/head:pull/26754 PR: https://git.openjdk.org/jdk/pull/26754 From iklam at openjdk.org Mon Sep 1 01:01:38 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 1 Sep 2025 01:01:38 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v4] In-Reply-To: References: Message-ID: <1y0xCycdMMkto_A7zYSbGYKJY_2AjnMv_uwyFya0kAg=.016425b2-06e3-48af-834d-0768d377121b@github.com> On Fri, 29 Aug 2025 18:57:23 GMT, Coleen Phillimore wrote: >> Ioi Lam 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 five additional commits since the last revision: >> >> - Merge branch 'master' into 8317269-store-old-classes-in-linked-state-in-aot-cache >> - @coleenp comments >> - More bug fixes from JCK testing >> - Fixed bugs found in JCK testing >> - 8317269: Store old classes in linked state in AOT cache > > src/hotspot/share/cds/runTimeClassInfo.hpp line 204: > >> 202: u4* old_verifier_dependencies() { >> 203: assert(_num_old_verifier_dependencies > 0, "sanity"); >> 204: return (u4*)(address(this) + old_verifier_dependencies_offset()); > > This seems like it should have a checked_cast<> around it rather than a plain cast. `checked_cast<>` only checks size difference of the source and target types, but here both are pointer types so they have the same size. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2312711414 From iklam at openjdk.org Mon Sep 1 01:01:41 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 1 Sep 2025 01:01:41 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v5] In-Reply-To: <92PKx4jRrCfYgf-jdR3WG6Npmo6Sao4mtt2tAQdrv5U=.aeef13b1-2ab5-4fd7-af0d-6c9eab9a204d@github.com> References: <92PKx4jRrCfYgf-jdR3WG6Npmo6Sao4mtt2tAQdrv5U=.aeef13b1-2ab5-4fd7-af0d-6c9eab9a204d@github.com> Message-ID: <1WzJLDW8mkbrCvucRTvQCTHNzqcs_43-ay8XWS2PiC0=.da2d6fa8-c8da-41ec-98b3-8317ee0cec39@github.com> On Fri, 29 Aug 2025 21:48:54 GMT, Coleen Phillimore wrote: >> Ioi Lam 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 nine additional commits since the last revision: >> >> - Merge branch 'master' into 8317269-store-old-classes-in-linked-state-in-aot-cache >> - @matias9927 comments: fixed typos >> - clean up; removed unrelated change >> - Cleaned up iterate_verification_dependency_names so a return value of false from means early termination (similar to HashTable::iterate()) >> - Merge branch 'master' into 8317269-store-old-classes-in-linked-state-in-aot-cache >> - @coleenp comments >> - More bug fixes from JCK testing >> - Fixed bugs found in JCK testing >> - 8317269: Store old classes in linked state in AOT cache > > src/hotspot/share/classfile/systemDictionaryShared.cpp line 469: > >> 467: >> 468: // Returns true if the DumpTimeClassInfo::is_excluded() is true for at least one of k's exclusion dependencies. >> 469: bool SystemDictionaryShared::check_dependencies_exclusion(InstanceKlass* k, DumpTimeClassInfo* info) { > > So this checks one level of InstanceKlass* k's dependencies, and the table above collects one level of k or k's subclass's dependencies and calls this for those. > > class K : extends B implements I, J verifies C {} - the above hashtable has B, I and J and C. > > This function takes B - so checks B class. > > class B : extends A implements intf verifies C again, why not {} > > So it'd check A and intf and C again. But when do we check A's super? > > It seems like the hashtable should be created for all levels of the hierarchy, so only one bit of code should walk the hierarchy, not two. The ExclusionCheckCandidates table contains all (recursive) supertypes -- E.g., its `add_candidate(k)` method calls `add_candidate(k->java_super())`. > src/hotspot/share/classfile/systemDictionaryShared.cpp line 542: > >> 540: } >> 541: >> 542: Klass* SystemDictionaryShared::find_verification_dependency_bottom_class(InstanceKlass* k, Symbol* dependency_class_name) { > > Why don't you have this return InstanceKlasss so that the callers don't have to check the same thing. What you want is the bottom InstanceKlass so for [Lfoo; - you want foo. Since class foo is the thing you care about. Maybe the comment about why you return nullptr from check_verification_dependency_exclusion() could be here instead. > > These names are a bit repetative, can you just call this find_bottom_instance_klass() and maybe it could be used for other things too. The problem is if `k` is the ObjArrayKlass of `[[I`, then `k->bottom_klass()` is `[I`, which is not an InstanceKlass. If we change the return type to `InstanceKlass*`, then we would have to return `nullptr`. However, that would make it more difficult to explain the following case (I've updated the comments): bool SystemDictionaryShared::check_verification_dependency_exclusion(InstanceKlass* k, Symbol* dependency_class_name) { Klass* dependency_bottom_class = find_verification_dependency_bottom_class(k, dependency_class_name); if (dependency_bottom_class == nullptr) { // Dependency_class_name has not yet been loaded. This happens when the new verifier was checking // if dependency_class_name is assignable to an interface, and found the answer without resolving // dependency_class_name. // // Since this class is not even loaded, it surely cannot be excluded. return false; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2312711042 PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2312711119 From iklam at openjdk.org Mon Sep 1 01:01:42 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 1 Sep 2025 01:01:42 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v5] In-Reply-To: References: <92PKx4jRrCfYgf-jdR3WG6Npmo6Sao4mtt2tAQdrv5U=.aeef13b1-2ab5-4fd7-af0d-6c9eab9a204d@github.com> Message-ID: On Fri, 29 Aug 2025 20:56:25 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/systemDictionaryShared.cpp line 1036: >> >>> 1034: DumpTimeClassInfo* info = get_info(ik); >>> 1035: Handle loader(current, ik->class_loader()); >>> 1036: Klass* k = SystemDictionary::find_instance_or_array_klass(current, name, loader); >> >> The caller just did this, didn't it? So, you should just be able to pass in from_class (unless it's null). > > I would kind of prefer old_verifier_dependency rather than old_verification - the latter seems to say that we had some verification that is no longer valid. old_verifier makes it clearer it's for old classfiles and the old verifier. Also 'verification' is used for the regular verifier so it's less of a same name. > The caller just did this, didn't it? There is a different caller (SystemDictionaryShared::copy_verification_info_from_preimage) which has only the class name. > I would kind of prefer old_verifier_dependency The current code is kind of messy. For example, we have _verifier_constraints in DumpTimeClassInfo, but other places use "verification_constraints". Maybe I should rename all old and new cases of verification_xxx to verifier_xxx? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2312711164 From iklam at openjdk.org Mon Sep 1 01:01:43 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 1 Sep 2025 01:01:43 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v4] In-Reply-To: References: Message-ID: <5NQG0QYNv1XT5_JuE_BGf5k4qWGSjErXxkR8a0bnrHI=.e9593639-d70c-4dc5-a0d9-730376fa4166@github.com> On Fri, 29 Aug 2025 21:51:45 GMT, Coleen Phillimore wrote: >> src/hotspot/share/prims/jvm.cpp line 854: >> >>> 852: >>> 853: #if INCLUDE_CDS >>> 854: if (CDSConfig::is_preserving_verification_dependencies() && from_class->is_instance_klass()) { >> >> It looks like from_class can be null so you have to check for null here. >> Which doesn't make sense because the logging doesn't have null checks. > > This looks like something that should be cleaned up apart from this change. "from" can never be null. I created [JDK-8366488](https://bugs.openjdk.org/browse/JDK-8366488) - "JVM_FindClassFromClass should assert that from class is never null" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2312711385 From iklam at openjdk.org Mon Sep 1 01:05:41 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 1 Sep 2025 01:05:41 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v2] In-Reply-To: <4CuIk4X6i570N7wUdCfCdiwla8tAKyyn9iHkj-fIR-A=.680f53c2-7d13-460f-82e6-7eb46453ef9e@github.com> References: <5PF9YneXIfGjkmxmIY51Zr28yk9fA23dMPAEXcD-9Cc=.86bee7bf-ee81-4196-83e5-cd2b2b4c1ad6@github.com> <4CuIk4X6i570N7wUdCfCdiwla8tAKyyn9iHkj-fIR-A=.680f53c2-7d13-460f-82e6-7eb46453ef9e@github.com> Message-ID: On Fri, 29 Aug 2025 21:49:48 GMT, Coleen Phillimore wrote: >> We need to know if are are at the CDS safepoint, not any safepoint. > > I don't think we share safepoints anymore (?) This code is used by places like this in methodData.cpp: static bool is_excluded(Klass* k) { #if INCLUDE_CDS if (CDSConfig::is_at_cds_safepoint()) { // Check for CDS exclusion only at CDS safe point. if (k->is_instance_klass() && !InstanceKlass::cast(k)->is_loaded()) { log_debug(aot, training)("Purged %s from MDO: unloaded class", k->name()->as_C_string()); return true; } else { bool excluded = SystemDictionaryShared::should_be_excluded(k); if (excluded) { log_debug(aot, training)("Purged %s from MDO: excluded class", k->name()->as_C_string()); } return excluded; } } #endif return false; } This function is usually called with GC safepoints (for class unloading, etc). If that's the case, we must not call `SystemDictionaryShared::should_be_excluded(k)`, because the exclusion check is not yet complete. So we need to distinguish whether the current safepoint is CDS or not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2312714685 From iklam at openjdk.org Mon Sep 1 01:27:24 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 1 Sep 2025 01:27:24 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v7] In-Reply-To: References: Message-ID: > During the assembly phase of the AOT cache, we link and verify all classes that were loaded during the training run. When verifying a class like this: > > > class X { > A getA() { return new B(); } // Verifier requires B to be a subtype of A. > } > > > We remember `A` and `B` as the "verification dependencies" of `X`. A class will be excluded from the AOT cache if any of its verification dependencies are excluded. For example, `X` will be excluded if > > - `A` fails verification > - `B` is a signed class, which is always excluded from the AOT cache > > Conversely, if both `A` and `B` are included in the AOT cache, in the production run, they will be unconditionally loaded during VM bootstrap. Therefore, we can guarantee that the verification result computed for `X` will remain valid during the production run. > > Notes for reviewers: > > - The checks for verification dependencies are done inside `SystemDictionaryShared::check_exclusion_for_self_and_dependencies()`. These checks are done for both old and new classes. Since the dependencies can form a cyclic graph, the checks cannot be implemented with a simple recursion. See "Algorithm notes" in this function for details. > - The verification dependencies for "new" classes are already stored in `DumpTimeClassInfo::_verifier_constraints`. > - This PR adds code to record the verification dependencies for "old" classes into `DumpTimeClassInfo::_old_verifier_dependencies`, by intercepting `JVM_FindClassFromCaller()`. > - This new functionality (store old classes in linked state) is available only when using the AOT cache. For simplicity, this functionality is not available with the old CDS workflows. See comments in `CDSConfig::is_preserving_verification_dependencies()`. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Added assert that SystemDictionaryShared::should_be_excluded() can only be called within CDS safepoint ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26754/files - new: https://git.openjdk.org/jdk/pull/26754/files/b5bd8123..db57b101 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26754&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26754&range=05-06 Stats: 15 lines in 2 files changed: 15 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26754/head:pull/26754 PR: https://git.openjdk.org/jdk/pull/26754 From iklam at openjdk.org Mon Sep 1 01:27:24 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 1 Sep 2025 01:27:24 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v2] In-Reply-To: References: <5PF9YneXIfGjkmxmIY51Zr28yk9fA23dMPAEXcD-9Cc=.86bee7bf-ee81-4196-83e5-cd2b2b4c1ad6@github.com> <4CuIk4X6i570N7wUdCfCdiwla8tAKyyn9iHkj-fIR-A=.680f53c2-7d13-460f-82e6-7eb46453ef9e@github.com> Message-ID: <_zPVmdQfMPNXvWuhzq8QS5A02yKQdWPa9xrb3xyaflo=.5122ff52-e60e-4e6a-a627-90df1c90715c@github.com> On Mon, 1 Sep 2025 01:03:17 GMT, Ioi Lam wrote: >> I don't think we share safepoints anymore (?) > > This code is used by places like this in methodData.cpp: > > > static bool is_excluded(Klass* k) { > #if INCLUDE_CDS > if (CDSConfig::is_at_cds_safepoint()) { > // Check for CDS exclusion only at CDS safe point. > if (k->is_instance_klass() && !InstanceKlass::cast(k)->is_loaded()) { > log_debug(aot, training)("Purged %s from MDO: unloaded class", k->name()->as_C_string()); > return true; > } else { > bool excluded = SystemDictionaryShared::should_be_excluded(k); > if (excluded) { > log_debug(aot, training)("Purged %s from MDO: excluded class", k->name()->as_C_string()); > } > return excluded; > } > } > #endif > return false; > } > > > This function is usually called with GC safepoints (for class unloading, etc). If that's the case, we must not call `SystemDictionaryShared::should_be_excluded(k)`, because the exclusion check is not yet complete. > > So we need to distinguish whether the current safepoint is CDS or not. I added an assert for this. See commit db57b101267f407535ffdc1f3cb685738d898f80 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2312729461 From iklam at openjdk.org Mon Sep 1 04:06:49 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 1 Sep 2025 04:06:49 GMT Subject: RFR: 8366024: Remove unnecessary InstanceKlass::cast() In-Reply-To: References: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com> Message-ID: On Wed, 27 Aug 2025 09:17:31 GMT, Andrew Dinn wrote: >> We have a lot of `InstanceKlass::cast(k)` calls where `k` is statically known to be an `InstanceKlass`. I fixed many instances of this pattern: >> >> >> InstanceKlass* x = ....; >> Klass* s = x->super(); // should call java_super() >> InstanceKlass::cast(s)->xyz(); >> >> >> The `super()` method has a very confusing API. It has the return type of `Klass*` because for for an `ObjArrayKlass` like `[Ljava/lang/String;`: >> >> - `super()` returns `[Ljava/lang/Object;` >> - `java_super()` returns `Ljava/lang/Object;` >> >> However, for `[Ljava/lang/Object;`, all `TypeArrayKlasses` and all `InstanceKlasses`, `super()` and `java_super()` return an identical value of that always have the actual type of `InstanceKlass*`. >> >> See here about the difference between `super()` and `java_super()`: https://github.com/openjdk/jdk/blob/7b9969dc8f20989497ff617abb45543d182b684d/src/hotspot/share/oops/klass.hpp#L218-L221 >> >> Unfortunately, we have a lot of code that incorrectly uses `super()` instead of `java_super()`, which leads to ` InstanceKlass::cast()` calls. I tried to fixed a bunch of easy ones in this PR, although there are a few more to go. >> >> I also fixed some calls to `local_interafaces()->at()` that widens the return type for `InstanceKlass*` to `Klass*`, which may lead to unnecessary ` InstanceKlass::cast()` calls. >> >> I also removed the `Klass::superklass()` API. This was used only in a few places and all of them can be safely replaced with `Klass::java_super()`. >> >> To avoid confusion, I think we should rename `super()` to something more obvious, but let's do that in a future PR. > > I found two more occurrences of casting super() to InstanceKlass: > > src/hotspot/share/jfr/leakprofiler/chains/edgeUtils.cpp:79 > > ik = (const InstanceKlass*)ik->super(); > > src/hotspot/share/prims/jni.cpp:209 > > Klass* field_klass = k; > Klass* super_klass = field_klass->super(); > // With compressed oops the most super class with nonstatic fields would > // be the owner of fields embedded in the header. > while (InstanceKlass::cast(super_klass)->has_nonstatic_fields() && > InstanceKlass::cast(super_klass)->contains_field_offset(offset)) { > field_klass = super_klass; // super contains the field also > super_klass = field_klass->super(); > } > > The first one ought perhaps to be using InstanceKlass::superklass()? Thanks @adinn @dholmes-ora @coleenp for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/26908#issuecomment-3240791556 From iklam at openjdk.org Mon Sep 1 04:06:49 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 1 Sep 2025 04:06:49 GMT Subject: RFR: 8366024: Remove unnecessary InstanceKlass::cast() [v2] In-Reply-To: <26NJ6xwmV3vbZdHpM320sGwZHiJ8Mn7d3gtJ--Ygz2U=.551378e5-35ff-4162-8984-ec0b5b585984@github.com> References: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com> <26NJ6xwmV3vbZdHpM320sGwZHiJ8Mn7d3gtJ--Ygz2U=.551378e5-35ff-4162-8984-ec0b5b585984@github.com> Message-ID: <9PsU6uvER6LcD__iFv6n23heIOuIAD3kxgkhAq-rA8A=.398b2031-0c5b-4444-b1e1-8dd32bcac4bc@github.com> On Mon, 1 Sep 2025 00:56:43 GMT, David Holmes wrote: > This seems fine though I will also comment that `java_super` seems completely mis-named in relation to `super` as there is nothing more `Java` about it. The implementation of `java_super` for arrays is quite odd - I'm not sure when we don't care about the actual superclass and want to go straight to object. As we discussed offline, I will try to add a new `InstanceKlass* InstanceKlass::super()` method. Then in most case people can just call `ik->super()` and it will do "the right thing". ------------- PR Comment: https://git.openjdk.org/jdk/pull/26908#issuecomment-3240793456 From iklam at openjdk.org Mon Sep 1 04:06:50 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 1 Sep 2025 04:06:50 GMT Subject: Integrated: 8366024: Remove unnecessary InstanceKlass::cast() In-Reply-To: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com> References: <7QAphYNlPFcXmHo86DFEuVPnjjOwjoYMsksNtXFnsl0=.aa09352d-087e-4e23-805b-c05e38bb658d@github.com> Message-ID: <-_Xcpc5liL09SoygjhPedFMbo5EPoBsVlxm4LhEX1Co=.d6515314-7994-4867-848b-5eb43dab2d72@github.com> On Fri, 22 Aug 2025 23:45:41 GMT, Ioi Lam wrote: > We have a lot of `InstanceKlass::cast(k)` calls where `k` is statically known to be an `InstanceKlass`. I fixed many instances of this pattern: > > > InstanceKlass* x = ....; > Klass* s = x->super(); // should call java_super() > InstanceKlass::cast(s)->xyz(); > > > The `super()` method has a very confusing API. It has the return type of `Klass*` because for for an `ObjArrayKlass` like `[Ljava/lang/String;`: > > - `super()` returns `[Ljava/lang/Object;` > - `java_super()` returns `Ljava/lang/Object;` > > However, for `[Ljava/lang/Object;`, all `TypeArrayKlasses` and all `InstanceKlasses`, `super()` and `java_super()` return an identical value of that always have the actual type of `InstanceKlass*`. > > See here about the difference between `super()` and `java_super()`: https://github.com/openjdk/jdk/blob/7b9969dc8f20989497ff617abb45543d182b684d/src/hotspot/share/oops/klass.hpp#L218-L221 > > Unfortunately, we have a lot of code that incorrectly uses `super()` instead of `java_super()`, which leads to ` InstanceKlass::cast()` calls. I tried to fixed a bunch of easy ones in this PR, although there are a few more to go. > > I also fixed some calls to `local_interafaces()->at()` that widens the return type for `InstanceKlass*` to `Klass*`, which may lead to unnecessary ` InstanceKlass::cast()` calls. > > I also removed the `Klass::superklass()` API. This was used only in a few places and all of them can be safely replaced with `Klass::java_super()`. > > To avoid confusion, I think we should rename `super()` to something more obvious, but let's do that in a future PR. This pull request has now been integrated. Changeset: 2427c901 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/2427c901b31dbdccc6f8f39404875a0140460479 Stats: 99 lines in 16 files changed: 0 ins; 16 del; 83 mod 8366024: Remove unnecessary InstanceKlass::cast() Reviewed-by: coleenp, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/26908 From dholmes at openjdk.org Mon Sep 1 05:13:45 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 1 Sep 2025 05:13:45 GMT Subject: RFR: 8365937: post_method_exit might incorrectly set was_popped_by_exception and value in the middle of stack unwinding [v4] In-Reply-To: <2SqwKSSfcLR6krBk2CYQZ8Q5X2T1eK4gaM4D6Hte2WA=.f4e906aa-4ffe-4d50-ba59-0ef12fb2f790@github.com> References: <2SqwKSSfcLR6krBk2CYQZ8Q5X2T1eK4gaM4D6Hte2WA=.f4e906aa-4ffe-4d50-ba59-0ef12fb2f790@github.com> Message-ID: On Fri, 29 Aug 2025 06:54:13 GMT, Leonid Mesnik wrote: >> But we are only in this method because the Java method has completed normally so there cannot be a pending exception at this point. ??? > > There is might be exception if current method has been called after exception has been thrown. It is quite rare case, but I've seem when add `assert(!exception_exit, "")`. It might happens if exception thrown and there were other upcals in the same thread before exception has been caught. I think I've seen it during classloading or some method bootstrapping. > > The test `TestMethodExitWithPendingException` simulates the same issue by calling method in the MethodExit event call back. > For method `upCall` the `exception_exit` would be true, because the method is called while exception is pending. However, the method `upCall` exits normally and is not unwinded. So this method `post_method_exit` is called. > > Here is the example of such stack in the on of the tests were assertion has been hit. The VM tries to load classes when exception is throwing. > > V [libjvm.so+0x1415d6c] JvmtiExport::post_method_exit(JavaThread*, Method*, frame)+0x29c (jvmtiExport.cpp:1847) > V [libjvm.so+0x1066b86] InterpreterRuntime::post_method_exit(JavaThread*)+0xe6 (interpreterRuntime.cpp:1278) > j java.lang.Object.()V+0 java.base at 26-internal > j java.lang.Throwable.(Ljava/lang/String;)V+1 java.base at 26-internal > j java.lang.Error.(Ljava/lang/String;)V+2 java.base at 26-internal > j java.lang.LinkageError.(Ljava/lang/String;)V+2 java.base at 26-internal > j java.lang.NoClassDefFoundError.(Ljava/lang/String;)V+2 java.base at 26-internal > v ~StubRoutines::Stub Generator call_stub_stub 0x00007f81b7c876fd > V [libjvm.so+0x1089117] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4f7 (javaCalls.cpp:415) > V [libjvm.so+0x108ab3f] JavaCalls::call_special(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x18f (javaCalls.cpp:323) > V [libjvm.so+0x108b3c6] JavaCalls::construct_new_instance(InstanceKlass*, Symbol*, JavaCallArguments*, JavaThread*)+0x116 (javaCalls.cpp:289) > V [libjvm.so+0xd74f4b] Exceptions::new_exception(JavaThread*, Symbol*, Symbol*, JavaCallArguments*, Handle)+0x1db (exceptions.cpp:320) > V [libjvm.so+0xd7517f] Exceptions::new_exception(JavaThread*, Symbol*, Symbol*, JavaCallArguments*, Handle, Handle)+0x2f (exceptions.cpp:341) > V [libjvm.so+0xd7609f] Exceptions::new_exception(JavaThread*, Symbol*, char const*, Handle, Handle, Exceptions::ExceptionMsgToUtf8Mode)+0x3bf (exceptions.cpp:424) > V [libjvm.so+0xd7b9a0] Exceptions::_throw_msg_cause(JavaThread*, char const*, int, Symbol*, char co... Sorry I still can't see this. Method A throws an exception. The callback for the method-exit event for method A then invokes Java method B. Method B also has a callback enabled and so we are processing the method-exit for B. Method B has completed normally, but the exception from method A is still listed as pending? I can't see how that would come about as we must (temporarily) clear the pending exception to do the upcall else the upcall method would immediately throw that pending exception. But if we have cleared it then the upcall method's method-exit event shouldn't be able to see it. Similarly we must save/restore the JvmtiThreadState else we would be processing the normal exit as if it were an exception one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2312899717 From dholmes at openjdk.org Mon Sep 1 05:22:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 1 Sep 2025 05:22:53 GMT Subject: RFR: 8365937: post_method_exit might incorrectly set was_popped_by_exception and value in the middle of stack unwinding [v4] In-Reply-To: References: <2SqwKSSfcLR6krBk2CYQZ8Q5X2T1eK4gaM4D6Hte2WA=.f4e906aa-4ffe-4d50-ba59-0ef12fb2f790@github.com> Message-ID: <1n0gbxAE37Nf7SHwUFLwCr1fJ2W4EuPh88kxMyO8un0=.5e803b50-f08f-4887-8d4c-3eb37156a754@github.com> On Mon, 1 Sep 2025 05:11:32 GMT, David Holmes wrote: >> There is might be exception if current method has been called after exception has been thrown. It is quite rare case, but I've seem when add `assert(!exception_exit, "")`. It might happens if exception thrown and there were other upcals in the same thread before exception has been caught. I think I've seen it during classloading or some method bootstrapping. >> >> The test `TestMethodExitWithPendingException` simulates the same issue by calling method in the MethodExit event call back. >> For method `upCall` the `exception_exit` would be true, because the method is called while exception is pending. However, the method `upCall` exits normally and is not unwinded. So this method `post_method_exit` is called. >> >> Here is the example of such stack in the on of the tests were assertion has been hit. The VM tries to load classes when exception is throwing. >> >> V [libjvm.so+0x1415d6c] JvmtiExport::post_method_exit(JavaThread*, Method*, frame)+0x29c (jvmtiExport.cpp:1847) >> V [libjvm.so+0x1066b86] InterpreterRuntime::post_method_exit(JavaThread*)+0xe6 (interpreterRuntime.cpp:1278) >> j java.lang.Object.()V+0 java.base at 26-internal >> j java.lang.Throwable.(Ljava/lang/String;)V+1 java.base at 26-internal >> j java.lang.Error.(Ljava/lang/String;)V+2 java.base at 26-internal >> j java.lang.LinkageError.(Ljava/lang/String;)V+2 java.base at 26-internal >> j java.lang.NoClassDefFoundError.(Ljava/lang/String;)V+2 java.base at 26-internal >> v ~StubRoutines::Stub Generator call_stub_stub 0x00007f81b7c876fd >> V [libjvm.so+0x1089117] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4f7 (javaCalls.cpp:415) >> V [libjvm.so+0x108ab3f] JavaCalls::call_special(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x18f (javaCalls.cpp:323) >> V [libjvm.so+0x108b3c6] JavaCalls::construct_new_instance(InstanceKlass*, Symbol*, JavaCallArguments*, JavaThread*)+0x116 (javaCalls.cpp:289) >> V [libjvm.so+0xd74f4b] Exceptions::new_exception(JavaThread*, Symbol*, Symbol*, JavaCallArguments*, Handle)+0x1db (exceptions.cpp:320) >> V [libjvm.so+0xd7517f] Exceptions::new_exception(JavaThread*, Symbol*, Symbol*, JavaCallArguments*, Handle, Handle)+0x2f (exceptions.cpp:341) >> V [libjvm.so+0xd7609f] Exceptions::new_exception(JavaThread*, Symbol*, char const*, Handle, Handle, Exceptions::ExceptionMsgToUtf8Mode)+0x3bf (exceptions.cpp:424) >> V [libjvm.so+0xd7b9a0] Exceptions::_throw_msg_cause(Jav... > > Sorry I still can't see this. Method A throws an exception. The callback for the method-exit event for method A then invokes Java method B. Method B also has a callback enabled and so we are processing the method-exit for B. Method B has completed normally, but the exception from method A is still listed as pending? I can't see how that would come about as we must (temporarily) clear the pending exception to do the upcall else the upcall method would immediately throw that pending exception. But if we have cleared it then the upcall method's method-exit event shouldn't be able to see it. Similarly we must save/restore the JvmtiThreadState else we would be processing the normal exit as if it were an exception one. Or mabye I do get it. The actual pending exception (on the ThreadShadow) must be saved, cleared and later restored, else we can't execute the Java upcall. But because we have separate paths for normal and exceptional method-exit processing, maybe we don't have to save/restore the JvmtiThreadState exception fields? But in that case are those fields even useful? To be honest I can't see how the two fields interact: there is either no exception being thrown, or there is - so only one field needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2312908009 From duke at openjdk.org Mon Sep 1 06:30:50 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 1 Sep 2025 06:30:50 GMT Subject: Integrated: 8366331: Sort share/prims includes In-Reply-To: <3GeZOb9TuI9DDfsnncjo522fS-dh6k8UXfE8bDy7PDc=.bf40e61a-6edc-4cf6-acab-53457dbc574d@github.com> References: <3GeZOb9TuI9DDfsnncjo522fS-dh6k8UXfE8bDy7PDc=.bf40e61a-6edc-4cf6-acab-53457dbc574d@github.com> Message-ID: On Thu, 28 Aug 2025 09:04:04 GMT, Francesco Andreuzzi wrote: > This PR sorts the includes in `hotspot/share/prims` using `SortIncludes.java`, and removes some unnecessary ones. I'm also adding the directory to `TestIncludesAreSorted`. > > Passes `tier1`. This pull request has now been integrated. Changeset: 12dc568b Author: Francesco Andreuzzi Committer: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/12dc568b3d270e4ab6dcd07e1bcddbb024ad724a Stats: 71 lines in 26 files changed: 30 ins; 39 del; 2 mod 8366331: Sort share/prims includes Reviewed-by: shade, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/26980 From dholmes at openjdk.org Mon Sep 1 07:00:45 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 1 Sep 2025 07:00:45 GMT Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to MetaspaceObj::in_aot_cache() [v2] In-Reply-To: References: Message-ID: On Sat, 30 Aug 2025 17:34:38 GMT, Ioi Lam wrote: >> This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology): >> >> Rename `is_shared()` in `Metaspace` (and various other classes) to `in_aot_cache()` to reflect its true meaning: >> - tests if an object is inside the AOT cache's metaspace region. >> >> Also various forms of "shared metaspace" are updated to "aot metaspace" >> >> Please start your review with allocations.hpp > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Removed MetaspaceShared -> AOTMetaspace changes that are intended for https://github.com/openjdk/jdk/pull/27017 Maybe the JBS title should be a bit more generic as you seem to be renaming many occurrences of "shared" not just the one listed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27016#issuecomment-3241088446 From duke at openjdk.org Mon Sep 1 07:19:55 2025 From: duke at openjdk.org (Anton Artemov) Date: Mon, 1 Sep 2025 07:19:55 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v36] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 08:41:03 GMT, Anton Artemov wrote: >> Hi, >> >> in this PR the output value types for functions which return memory are changed, namely: >> >> >> static julong available_memory(); --> static bool available_memory(size_t& value); >> static julong used_memory(); --> static bool used_memory(size_t& value); >> static julong free_memory(); --> static bool free_memory(size_t& value); >> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); >> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); >> static julong physical_memory(); --> static size_t physical_memory(size_t& value); >> >> >> The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. >> >> Tested in GHA and Tiers 1-5. > > Anton Artemov has updated the pull request incrementally with two additional commits since the last revision: > > - 8357086: Removed extra empty line. > - 8357086: Removed placeholder for nodiscard attribute. I assume that those who wanted to express opinion about this PR have already done that, let's ------------- PR Comment: https://git.openjdk.org/jdk/pull/25450#issuecomment-3241136696 From duke at openjdk.org Mon Sep 1 07:19:55 2025 From: duke at openjdk.org (duke) Date: Mon, 1 Sep 2025 07:19:55 GMT Subject: RFR: 8357086: os::xxx functions returning memory size should return size_t [v36] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 08:41:03 GMT, Anton Artemov wrote: >> Hi, >> >> in this PR the output value types for functions which return memory are changed, namely: >> >> >> static julong available_memory(); --> static bool available_memory(size_t& value); >> static julong used_memory(); --> static bool used_memory(size_t& value); >> static julong free_memory(); --> static bool free_memory(size_t& value); >> static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); >> static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); >> static julong physical_memory(); --> static size_t physical_memory(size_t& value); >> >> >> The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. >> >> Tested in GHA and Tiers 1-5. > > Anton Artemov has updated the pull request incrementally with two additional commits since the last revision: > > - 8357086: Removed extra empty line. > - 8357086: Removed placeholder for nodiscard attribute. @toxaart Your change (at version 6ac6840024e719c96faee099205f7a967bc4af47) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25450#issuecomment-3241141060 From duke at openjdk.org Mon Sep 1 07:46:01 2025 From: duke at openjdk.org (Anton Artemov) Date: Mon, 1 Sep 2025 07:46:01 GMT Subject: Integrated: 8357086: os::xxx functions returning memory size should return size_t In-Reply-To: References: Message-ID: On Mon, 26 May 2025 12:56:26 GMT, Anton Artemov wrote: > Hi, > > in this PR the output value types for functions which return memory are changed, namely: > > > static julong available_memory(); --> static bool available_memory(size_t& value); > static julong used_memory(); --> static bool used_memory(size_t& value); > static julong free_memory(); --> static bool free_memory(size_t& value); > static jlong total_swap_space(); --> static bool total_swap_space(size_t& value); > static jlong free_swap_space(); --> static bool free_swap_space(size_t& value); > static julong physical_memory(); --> static size_t physical_memory(size_t& value); > > > The return boolean value, where available, indicates success, whereas the actual value is assigned to the input argument. The following recommended usage pattern is introduced: where applicable, an unsuccessful call is logged. > > Tested in GHA and Tiers 1-5. This pull request has now been integrated. Changeset: d5d94db1 Author: Anton Artemov Committer: David Holmes URL: https://git.openjdk.org/jdk/commit/d5d94db12a6d82a6fe9da18b5f8ce3733a6ee7e7 Stats: 256 lines in 22 files changed: 94 ins; 2 del; 160 mod 8357086: os::xxx functions returning memory size should return size_t Reviewed-by: stefank, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/25450 From lkorinth at openjdk.org Mon Sep 1 08:07:48 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 08:07:48 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v8] In-Reply-To: References: Message-ID: <1SVkL88-a7Es6cosezvIjvZ63F4nv-2Kut2oKG27Eo8=.f2e2a083-b51d-4df9-ab6e-ec324467ebb9@github.com> > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... Leo Korinth 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 10 additional commits since the last revision: - new timeouts - Merge branch '_master_jdk' into _8260555 - update copyright - revert added timeout, it is not needed - feedback from Mark Sheppard - update testing.md, remove makefile link, fix bad text - after suggestion from Daniel - added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD - After suggestions from Erik and Andrey - 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26749/files - new: https://git.openjdk.org/jdk/pull/26749/files/4b33904a..7ca719c8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=06-07 Stats: 37788 lines in 1054 files changed: 23834 ins; 9562 del; 4392 mod Patch: https://git.openjdk.org/jdk/pull/26749.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749 PR: https://git.openjdk.org/jdk/pull/26749 From jsjolen at openjdk.org Mon Sep 1 08:16:24 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 1 Sep 2025 08:16:24 GMT Subject: RFR: 8366456: Allow AllocFailStrategy for RBTree Message-ID: Right now the RBTree forces you to use the intrusive tree if you want fine-grained control of the out-of-memory strategy of the node allocations. We can change this to be a bit more flexible. One of the tests were incorrectly indented, so I fixed that. I also changed from `typedef` to `using`, turns out that `typedef` can give strange errors when the template instantiation is incorrect[0]. [0] For my particular gcc ------------- Commit messages: - Fix - ? - Allow OOM strategy for RBTree Changes: https://git.openjdk.org/jdk/pull/27011/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27011&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366456 Stats: 46 lines in 2 files changed: 21 ins; 0 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/27011.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27011/head:pull/27011 PR: https://git.openjdk.org/jdk/pull/27011 From cnorrbin at openjdk.org Mon Sep 1 08:45:41 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 1 Sep 2025 08:45:41 GMT Subject: RFR: 8366456: Allow AllocFailStrategy for RBTree In-Reply-To: References: Message-ID: <0fUdaBBBBygInmHUhN8Ll91L_kn8KhoCPqABkJtCJug=.029535eb-108b-4bcd-8047-b40236c20d80@github.com> On Fri, 29 Aug 2025 19:17:58 GMT, Johan Sj?len wrote: > Right now the RBTree forces you to use the intrusive tree if you want fine-grained control of the out-of-memory strategy of the node allocations. We can change this to be a bit more flexible. > > One of the tests were incorrectly indented, so I fixed that. I also changed from `typedef` to `using`, turns out that `typedef` can give strange errors when the template instantiation is incorrect[0]. > > [0] For my particular gcc Thank you for this. Would make the tree more flexible to use. This comment at the top needs to be edited/removed since we can now handle allocations failing. Looks good otherwise! https://github.com/openjdk/jdk/blob/fe4c7a0429a2cf9ef47701d68d0852ce44e1a9ab/src/hotspot/share/utilities/rbTree.hpp#L64 ------------- PR Review: https://git.openjdk.org/jdk/pull/27011#pullrequestreview-3172706368 From jsjolen at openjdk.org Mon Sep 1 08:57:30 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 1 Sep 2025 08:57:30 GMT Subject: RFR: 8366456: Allow AllocFailStrategy for RBTree [v2] In-Reply-To: References: Message-ID: > Right now the RBTree forces you to use the intrusive tree if you want fine-grained control of the out-of-memory strategy of the node allocations. We can change this to be a bit more flexible. > > One of the tests were incorrectly indented, so I fixed that. I also changed from `typedef` to `using`, turns out that `typedef` can give strange errors when the template instantiation is incorrect[0]. > > [0] For my particular gcc Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Remove ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27011/files - new: https://git.openjdk.org/jdk/pull/27011/files/8af9afc7..997e9592 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27011&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27011&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27011.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27011/head:pull/27011 PR: https://git.openjdk.org/jdk/pull/27011 From jsjolen at openjdk.org Mon Sep 1 08:57:30 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 1 Sep 2025 08:57:30 GMT Subject: RFR: 8366456: Allow AllocFailStrategy for RBTree [v2] In-Reply-To: <0fUdaBBBBygInmHUhN8Ll91L_kn8KhoCPqABkJtCJug=.029535eb-108b-4bcd-8047-b40236c20d80@github.com> References: <0fUdaBBBBygInmHUhN8Ll91L_kn8KhoCPqABkJtCJug=.029535eb-108b-4bcd-8047-b40236c20d80@github.com> Message-ID: On Mon, 1 Sep 2025 08:43:05 GMT, Casper Norrbin wrote: > Thank you for this. Would make the tree more flexible to use. > > This comment at the top needs to be edited/removed since we can now handle allocations failing. Looks good otherwise! > > https://github.com/openjdk/jdk/blob/fe4c7a0429a2cf9ef47701d68d0852ce44e1a9ab/src/hotspot/share/utilities/rbTree.hpp#L64 I decided to just remove the comment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27011#issuecomment-3241486886 From cnorrbin at openjdk.org Mon Sep 1 09:09:42 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 1 Sep 2025 09:09:42 GMT Subject: RFR: 8366456: Allow AllocFailStrategy for RBTree [v2] In-Reply-To: References: Message-ID: <7O_rR7ovfMNoc5ybXvhENhWdY1YMlUv-AWSX7e7e9Uc=.11b3e382-d89f-428c-8518-bc63bc168012@github.com> On Mon, 1 Sep 2025 08:57:30 GMT, Johan Sj?len wrote: >> Right now the RBTree forces you to use the intrusive tree if you want fine-grained control of the out-of-memory strategy of the node allocations. We can change this to be a bit more flexible. >> >> One of the tests were incorrectly indented, so I fixed that. I also changed from `typedef` to `using`, turns out that `typedef` can give strange errors when the template instantiation is incorrect[0]. >> >> [0] For my particular gcc > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Remove Marked as reviewed by cnorrbin (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27011#pullrequestreview-3172798497 From jsjolen at openjdk.org Mon Sep 1 09:16:43 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 1 Sep 2025 09:16:43 GMT Subject: RFR: 8366238: Improve RBTree API with stricter comparator semantics and pluggable validation/printing hooks. [v3] In-Reply-To: <9p4A1E9arftDmwBvVfAMxnqbvBUZ9heQ4jbYXeEowrw=.76647921-46a2-4be2-9c7a-f19b167a71e9@github.com> References: <9p4A1E9arftDmwBvVfAMxnqbvBUZ9heQ4jbYXeEowrw=.76647921-46a2-4be2-9c7a-f19b167a71e9@github.com> Message-ID: On Thu, 28 Aug 2025 11:21:00 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> The current red-black tree can be made safer, and its inspection capabilities improved. >> >> As briefly discussed in #26904, `COMPARATOR::cmp` could be made clearer and more robust. In particular, its `int` return type invites unsafe `return a ? b` arithmetic, and the boolean validation function also named `cmp` is misleading. >> >> To address this, I?ve introduced the `RBTreeOrdering` enum, inspired by C++20?s `<=>`, which makes incorrect arithmetic impossible. The return type of `COMPARATOR::cmp` is now this enum, forcing users to write an explicit and safe comparison. From the discussion in that PR, I have also renamed the boolean `cmp` to `less`, making its purpose obvious and preventing confusion between the two functions. >> >> Inspection has also been improved, especially for intrusive trees. Previously, `verify_self` only verified core RB-tree properties, yet intrusive nodes often hold additional data with their own separate invariants. Users had to perform those checks in a second traversal, and if an error occurs `print_on` produced little diagnostic value by only printing node addresses. >> >> To solve this, the tree now accepts user-supplied verification and printing callables. This lets users validate their custom node data during the same walk and print richer information when errors occur. >> >> Everything is implemented via template parameters with set defaults, so existing code remains unchanged while new code can opt in to the expanded functionality. >> >> Testing: >> - Oracle tiers 1-3 > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > albert feedback src/hotspot/share/utilities/rbTree.hpp line 65: > 63: // Nodes are address stable and will not change during its lifetime. > 64: > 65: enum class RBTreeOrdering : int { less = -1, equal = 0, greater = 1 }; Is assigning the elements to specific values necessary? src/hotspot/share/utilities/rbTree.hpp line 133: > 131: size_t& tree_depth, bool expect_visited, NodeVerifier verifier, > 132: const USER_VERIFIER& extra_verifier) const; > 133: `NodeType` is unused. Here we have two different naming standards for the template name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26981#discussion_r2313349689 PR Review Comment: https://git.openjdk.org/jdk/pull/26981#discussion_r2313358762 From jsjolen at openjdk.org Mon Sep 1 09:16:44 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 1 Sep 2025 09:16:44 GMT Subject: RFR: 8366238: Improve RBTree API with stricter comparator semantics and pluggable validation/printing hooks. [v3] In-Reply-To: References: <9p4A1E9arftDmwBvVfAMxnqbvBUZ9heQ4jbYXeEowrw=.76647921-46a2-4be2-9c7a-f19b167a71e9@github.com> Message-ID: On Mon, 1 Sep 2025 09:04:17 GMT, Johan Sj?len wrote: >> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: >> >> albert feedback > > src/hotspot/share/utilities/rbTree.hpp line 65: > >> 63: // Nodes are address stable and will not change during its lifetime. >> 64: >> 65: enum class RBTreeOrdering : int { less = -1, equal = 0, greater = 1 }; > > Is assigning the elements to specific values necessary? Personally, I'd prefer LT, EQ, GT to be the enum members. I'd like to see a `TotalOrdering` enum class in the future, to replace this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26981#discussion_r2313370588 From duke at openjdk.org Mon Sep 1 09:20:42 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 1 Sep 2025 09:20:42 GMT Subject: RFR: 8366155: Serial: Obsolete PretenureSizeThreshold In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 11:44:35 GMT, Albert Mingkun Yang wrote: > Remove obj-size checking before young/old-gen allocation -- an allocation succeeds iff there is enough free space. > > This simplifies the allocation logic: > 1. before attempting gc: `mem_allocate_work` does young-gen allocation then old-gen-no-expansion allocation > 2. after gc (still inside gc safepoint): `satisfy_failed_allocation` does young-gen allocation old-gen-with-expansion allocation > > Test: tier1-3 Marked as reviewed by fandreuz at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/26941#pullrequestreview-3172831747 From jsjolen at openjdk.org Mon Sep 1 09:27:52 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 1 Sep 2025 09:27:52 GMT Subject: RFR: 8366456: Allow AllocFailStrategy for RBTree [v2] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 08:57:30 GMT, Johan Sj?len wrote: >> Right now the RBTree forces you to use the intrusive tree if you want fine-grained control of the out-of-memory strategy of the node allocations. We can change this to be a bit more flexible. >> >> One of the tests were incorrectly indented, so I fixed that. I also changed from `typedef` to `using`, turns out that `typedef` can give strange errors when the template instantiation is incorrect[0]. >> >> [0] For my particular gcc > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Remove Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27011#issuecomment-3241582575 From aboldtch at openjdk.org Mon Sep 1 09:27:51 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 1 Sep 2025 09:27:51 GMT Subject: RFR: 8366456: Allow AllocFailStrategy for RBTree [v2] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 08:57:30 GMT, Johan Sj?len wrote: >> Right now the RBTree forces you to use the intrusive tree if you want fine-grained control of the out-of-memory strategy of the node allocations. We can change this to be a bit more flexible. >> >> One of the tests were incorrectly indented, so I fixed that. I also changed from `typedef` to `using`, turns out that `typedef` can give strange errors when the template instantiation is incorrect[0]. >> >> [0] For my particular gcc > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Remove lgtm. ------------- Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27011#pullrequestreview-3172844423 From jsjolen at openjdk.org Mon Sep 1 09:27:52 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 1 Sep 2025 09:27:52 GMT Subject: Integrated: 8366456: Allow AllocFailStrategy for RBTree In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 19:17:58 GMT, Johan Sj?len wrote: > Right now the RBTree forces you to use the intrusive tree if you want fine-grained control of the out-of-memory strategy of the node allocations. We can change this to be a bit more flexible. > > One of the tests were incorrectly indented, so I fixed that. I also changed from `typedef` to `using`, turns out that `typedef` can give strange errors when the template instantiation is incorrect[0]. > > [0] For my particular gcc This pull request has now been integrated. Changeset: 98af1892 Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/98af18921aa3c274ef7ece03005337b58df3da96 Stats: 47 lines in 2 files changed: 21 ins; 1 del; 25 mod 8366456: Allow AllocFailStrategy for RBTree Reviewed-by: cnorrbin, aboldtch ------------- PR: https://git.openjdk.org/jdk/pull/27011 From adinn at openjdk.org Mon Sep 1 09:54:45 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 1 Sep 2025 09:54:45 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v2] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Thu, 28 Aug 2025 22:25:24 GMT, Dean Long wrote: >> Ruben has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > If we end up adding a nop or illegal instruction, then we can also undo the work-around that we did in JDK-8172844 for a similar problem. @dean-long I think there is an alternative fix for this that we should consider. The problem here arises because a return address for a legitimate call from the body may alias the nmethod's deopt_handler start. However, that aliasing is solely down to how we are recording and comparing addresses and I think we can easily and safely avoid it. The nmethod's deopt handler offset is set to identify the start of the deopt handler code generated into the stubs area. We need to be able to identify that stub's first instruction because we have to patch it into the stack or link register as a return address and then return to it in order to initiate a deopt. Removing the exception handler means it is now possible for it to directly follow the main code and alias the return address of a trailing call. We actually work hard to ensure that this same start address is recorded on the stack when we enter the deopt blob. The generated handler code always uses a jump to enter the deopt blob. However, it makes that jump look like a call by patching in a return address that equals the stub start. On Intel we make a fake call in order to push a return address and then carefully decrement the pushed address to refer to the stub start rather than the pushed address (i.e. the one that follows the fake call). On aarch64 it requires less work. The stub start is loaded into lr before jumping effectively simulating a call that just preceded the start address. Doing all this fiddling of the return pc is what makes the frame code test for a deopt caller frame both *simple* -- just compare the pc to the nmethod's deopt address -- and *ambiguous* -- oops it could have been a trailing call in the main code. However, we can easily avoid the ambiguity. We can switch to an actual call in the generated code and adjust the deopt_pc test in the frame code to look for the nmethod's deopt address *plus* some arch-specific constant offset. The offset's size is determined by whatever instructions we need to plant in order to get to and make the call. We can make this safe against code changes by binding a label after the call and asserting that the difference between the label address and stub start address equals the relevant constant. That will give correct results if we traverse the frame stack inside or below the deopt blob code. But what about when we fiddle the return stack to force a return into the deopt stub? i.e. when the return address is the nmethod's deopt stub address? I don't believe we will ever traverse the stack while it is in that state because it only happens transiently when we are returning into the deopt handler. WDYT? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3241676272 From aph at openjdk.org Mon Sep 1 10:14:42 2025 From: aph at openjdk.org (Andrew Haley) Date: Mon, 1 Sep 2025 10:14:42 GMT Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when UseBlockZeroing is false [v2] In-Reply-To: <79QlFmmh7CAbxtU89RNVbf8sRBE_u8TbDLA90FqWyEM=.4e8b48ac-21b5-4881-9ca0-29bc87bfe032@github.com> References: <79QlFmmh7CAbxtU89RNVbf8sRBE_u8TbDLA90FqWyEM=.4e8b48ac-21b5-4881-9ca0-29bc87bfe032@github.com> Message-ID: On Fri, 29 Aug 2025 11:34:26 GMT, Patrick Zhang wrote: >> In AArch64 port, `UseBlockZeroing` is by default set to true and `BlockZeroingLowLimit` is initialized to 256. If `DC ZVA` is supported, `BlockZeroingLowLimit` is later updated to `4 * VM_Version::zva_length()`. When `UseBlockZeroing` is set to false, all related conditional checks should ignore `BlockZeroingLowLimit`. However, the function `MacroAssembler::zero_words(Register base, uint64_t cnt)` still evaluates the lower limit and bases its code generation logic on it, which appears to be an incomplete conditional check. >> >> This PR, >> 1. In `MacroAssembler::zero_words(Register base, uint64_t cnt)`, added the checking of `UseBlockZeroing` to the if-cond `cnt > (uint64_t)BlockZeroingLowLimit / BytesPerWord`, strengthened the condition. >> 2. In `MacroAssembler::zero_words(Register ptr, Register cnt)`, check `UseBlockZeroing` before checking the conditions of calling the stub function `zero_blocks`, which wraps the `DC ZVA` related instructions and works as the inner part of `zero_words`. Refined code and comments. >> 3. For `generate_zero_blocks()`, removed the `UseBlockZeroing` checking and added an assertion, moved unrolled `STP` code-gen out to the caller side >> 4. Added a warning message for if UseBlockZeroing is false and BlockZeroingLowLimit gets manually configured. >> 5. Added more testing sizes to test/micro/org/openjdk/bench/vm/gc/RawAllocationRate.java >> >> These changes improved the if-conds in `zero_words` functions around `BlockZeroingLowLimit`, ignore it if `UseBlockZeroing` is false. Performance tests are done on the bundled JMH `vm.compiler.ClearMemory`, and `vm.gc.RawAllocationRate` including `arrayTest` and `instanceTest`. >> >> Tests include, >> 1. The wall time of `zero_words_reg_imm` got significantly improved under a particularly designed test case: `-XX:-UseBlockZeroing -XX:BlockZeroingLowLimit=8`, `size=32` (`arrayTest` and `instanceTest`), the average wall time per call dropped from 309 ns (baseline) to 65 ns (patched), about -80%. The average call count also decreased from 335 to 202, in a 30s run. For example, `jdk/bin/java -jar images/test/micro/benchmarks.jar RawAllocationRate.arrayTest_C1 -bm thrpt -gc false -wi 0 -w 30 -i 1 -r 30 -t 1 -f 1 -tu s -jvmArgs "-XX:-UseBlockZeroing -XX:BlockZeroingLowLimit=8" -p size=32`. >> 2. `JMH RawAllocationRate` shows no obvious regression results. In details, patched vs baseline shows average ~70% positive impact, but ratios are minor around +0.5%, since the generated instruction sequences g... > > Patrick Zhang has updated the pull request incrementally with one additional commit since the last revision: > > Roll back main changes on zero_words_reg_reg and generate_zero_blocks > > Signed-off-by: Patrick Zhang It's difficult for anyone to predict all the possibilities of `-XX` command-line arguments that users might try, despite them not making any sense. To begin with, please add this short patch, then see if any of this PR provides an advantage. diff --git a/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp b/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp index 9321dd0542e..14a584c5106 100644 --- a/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp +++ b/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp @@ -446,6 +446,11 @@ void VM_Version::initialize() { FLAG_SET_DEFAULT(UseBlockZeroing, false); } + if (!UseBlockZeroing && !FLAG_IS_DEFAULT(BlockZeroingLowLimit)) { + warning("BlockZeroingLowLimit has been ignored because UseBlockZeroing is disabled"); + FLAG_SET_DEFAULT(BlockZeroingLowLimit, 4 * VM_Version::zva_length()); + } + if (VM_Version::supports_sve2()) { if (FLAG_IS_DEFAULT(UseSVE)) { FLAG_SET_DEFAULT(UseSVE, 2); ------------- PR Comment: https://git.openjdk.org/jdk/pull/26917#issuecomment-3241755892 From aph-open at littlepinkcloud.com Mon Sep 1 10:19:13 2025 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Mon, 1 Sep 2025 11:19:13 +0100 Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when UseBlockZeroing is false In-Reply-To: References: Message-ID: <66bf3e97-eeb6-4af3-8d30-89cd8d4367ec@littlepinkcloud.com> On 29/08/2025 12:10, Patrick Zhang wrote: > Regarding the impact to code caches, I measured JMH That's not going to tell you anything. The zeroing code is expanded many times during a compilation, and code cache size is limited. Every time we needlessly expand intrinsics inline we kick user's code out. -- Andrew Haley (he/him) Java Platform Lead Engineer https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph-open at littlepinkcloud.com Mon Sep 1 10:20:18 2025 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Mon, 1 Sep 2025 11:20:18 +0100 Subject: Random crashes/failures on Linux Aarch64 In-Reply-To: References: Message-ID: <9c47ee52-fddc-42b8-8f31-680e6d1ca676@littlepinkcloud.com> On 25/08/2025 00:03, David Holmes wrote: > Still collecting data and trying to see the pattern(s) here, but was > wondering if other CI's have also been seeing any issues? I'm not aware of any. Do you know when this started happening? -- Andrew Haley (he/him) Java Platform Lead Engineer https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aboldtch at openjdk.org Mon Sep 1 10:22:44 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 1 Sep 2025 10:22:44 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer In-Reply-To: References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> <-Ct2yCIbRn7bSazmFKxlMPMeP85zAZk3kUfP9ele4so=.78e5ec0f-2d17-45e6-a68d-9fff149577c1@github.com> Message-ID: On Fri, 29 Aug 2025 10:14:22 GMT, Afshin Zafari wrote: > To answer 'when/how does this happen?', this issue can be reproduced by running `runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java`, in which invalid values of options will be tested, particularly here `0` for `HeapBaseMinAddress`. Yeah I as I mentioned I figured that part out, it occurs when `MaxHeapSize` is not default set. I am not sure that `0` is an invalid value for `HeapBaseMinAddress` nor that it is what the test is testing. It tests both valid and invalid values. As mentioned when manually checking extreme values in `HeapBaseMinAddress` I could provoke an arithmetic overflow cause crash. `TestOptionsWithRanges.java` fails to capture this because of limitations in our `PrintFlagsRanges` option, which does not capture constraints. It prints: size_t HeapBaseMinAddress [ 0 ... 18446744073709551615 ] But on my machine (running with G1) the actual upper limit is `18446744072635809792` And running `./images/jdk/bin/java -XX:HeapBaseMinAddress=18446744072635809792 -Xmx1g --version` results in: # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (src/hotspot/share/utilities/globalDefinitions.hpp:440), pid=1726885, tid=1726886 # assert(left >= right) failed: avoid underflow - left: 0x00000000c0000000 right: 0xffffffffc0000000 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3241790796 From adinn at openjdk.org Mon Sep 1 10:31:43 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 1 Sep 2025 10:31:43 GMT Subject: RFR: 8365501: Remove special AdapterHandlerEntry for abstract methods [v3] In-Reply-To: References: Message-ID: <3Rdyz0i6XIKqcVC5Rbw1eDU4qZyawLb5JYWws3UARIw=.68cf8962-f5d5-47de-8cc3-d9b18b1453f0@github.com> On Wed, 27 Aug 2025 19:35:04 GMT, Ashutosh Mehra wrote: >> This PR removes the need for having AdapterHandlerEntry for abstract methods. The check for abstract method is now done in the accessor functions in Method such as Method::get_i2c_entry(). >> Motivation for this change is described in the JBS issue. > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Address review comment - swap conditions > > Signed-off-by: Ashutosh Mehra Looks good but I would appreciate an explanation as to why we don't need the lock. src/hotspot/share/runtime/sharedRuntime.cpp line 2567: > 2565: { > 2566: ResourceMark rm; > 2567: MutexLocker mu(AdapterHandlerLibrary_lock); Why are we ok to drop this lock here? Was it unnecessary even before this change? ------------- Marked as reviewed by adinn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26764#pullrequestreview-3173094876 PR Review Comment: https://git.openjdk.org/jdk/pull/26764#discussion_r2313562473 From krk at openjdk.org Mon Sep 1 11:42:17 2025 From: krk at openjdk.org (Kerem Kat) Date: Mon, 1 Sep 2025 11:42:17 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands Message-ID: Prevents segmentation faults during `gdb` sessions. The crashes were caused by the `ResourceMark` constructor being called on a native thread, which is not supported. This happened when invoking debug commands that require a `Thread` or `JavaThread` context from an incorrect thread type. ### Solution This change introduces `onThread()` and `onJavaThread()` helper methods to the `Command` class. These methods validate the thread context and ensure `ResourceMark` is only created when on a valid VM thread. All thread-dependent debug commands now use these guards to validate the context, printing a clear error and exiting gracefully upon failure. ### Testing Manually verified using `gdb` by calling the modified commands (`ps`, `universe`, `pns`, etc.) from different thread contexts (native, Java, and non-java threads) to ensure they fail gracefully with an error message instead of crashing the debug session. ------------- Commit messages: - Update src/hotspot/share/utilities/debug.cpp - 8366154: Validate thread type requirements in debug commands Changes: https://git.openjdk.org/jdk/pull/27033/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27033&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366154 Stats: 63 lines in 1 file changed: 45 ins; 4 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/27033.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27033/head:pull/27033 PR: https://git.openjdk.org/jdk/pull/27033 From duke at openjdk.org Mon Sep 1 11:42:17 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 1 Sep 2025 11:42:17 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 11:36:21 GMT, Kerem Kat wrote: > Prevents segmentation faults during `gdb` sessions. The crashes were caused by the `ResourceMark` constructor being called on a native thread, which is not supported. This happened when invoking debug commands that require a `Thread` or `JavaThread` context from an incorrect thread type. > > ### Solution > > This change introduces `onThread()` and `onJavaThread()` helper methods to the `Command` class. These methods validate the thread context and ensure `ResourceMark` is only created when on a valid VM thread. All thread-dependent debug commands now use these guards to validate the context, printing a clear error and exiting gracefully upon failure. > > ### Testing > > Manually verified using `gdb` by calling the modified commands (`ps`, `universe`, `pns`, etc.) from different thread contexts (native, Java, and non-java threads) to ensure they fail gracefully with an error message instead of crashing the debug session. src/hotspot/share/utilities/debug.cpp line 338: > 336: if (JavaThread::active() == nullptr) { > 337: tty->print_cr("Failed: Current thread is not a java thread or the vm thread"); > 338: return false; Suggestion: return false; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27033#discussion_r2313718023 From duke at openjdk.org Mon Sep 1 11:50:01 2025 From: duke at openjdk.org (Ruben) Date: Mon, 1 Sep 2025 11:50:01 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v3] In-Reply-To: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: > The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. > > According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. Ruben has updated the pull request incrementally with one additional commit since the last revision: Ensure stub code is not adjacent to a call ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26678/files - new: https://git.openjdk.org/jdk/pull/26678/files/2d8012a3..1f6546e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26678&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26678&range=01-02 Stats: 17 lines in 1 file changed: 12 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/26678.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26678/head:pull/26678 PR: https://git.openjdk.org/jdk/pull/26678 From duke at openjdk.org Mon Sep 1 12:16:47 2025 From: duke at openjdk.org (Ruben) Date: Mon, 1 Sep 2025 12:16:47 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v2] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Mon, 1 Sep 2025 09:51:38 GMT, Andrew Dinn wrote: >> If we end up adding a nop or illegal instruction, then we can also undo the work-around that we did in JDK-8172844 for a similar problem. > > @dean-long I think there is an alternative fix for this that we should consider. The problem here arises because a return address for a legitimate call from the body may alias the nmethod's deopt_handler start. However, that aliasing is solely down to how we are recording and comparing addresses and I think we can easily and safely avoid it. > > The nmethod's deopt handler offset is set to identify the start of the deopt handler code generated into the stubs area. We need to be able to identify that stub's first instruction because we have to patch it into the stack or link register as a return address and then return to it in order to initiate a deopt. Removing the exception handler means it is now possible for it to directly follow the main code and alias the return address of a trailing call. > > We actually work hard to ensure that this same start address is recorded on the stack when we enter the deopt blob. The generated handler code always uses a jump to enter the deopt blob. However, it makes that jump look like a call by patching in a return address that equals the stub start. On Intel we make a fake call in order to push a return address and then carefully decrement the pushed address to refer to the stub start rather than the pushed address (i.e. the one that follows the fake call). On aarch64 it requires less work. The stub start is loaded into lr before jumping effectively simulating a call that just preceded the start address. > > Doing all this fiddling of the return pc is what makes the frame code test for a deopt caller frame both *simple* -- just compare the pc to the nmethod's deopt address -- and *ambiguous* -- oops! it could have been a trailing call in the main code. However, we can easily avoid the ambiguity. We can switch to an actual call in the generated code and adjust the deopt_pc test in the frame code to look for the nmethod's deopt address *plus* some arch-specific constant offset. The offset's size is determined by whatever instructions we need to plant in order to get to and make the call. We can make this safe against code changes by binding a label after the call and asserting that the difference between the label address and stub start address equals the relevant constant. > > That will give correct results if we traverse the frame stack inside or below the deopt blob code. But what about when we fiddle the return stack to force a return into the deopt stub? i.e. when the return address is the nmethod's deopt stub address? I don't b... Thank you for the feedback and suggestions, @adinn and @dean-long. I've prototyped adding a NOP at the end of main code region if otherwise the last instruction is a call - not an illegal instruction only to avoid tweaking the logic behind `MachHaltNode` or introducing a new node type. If `MachHaltNode` is used as is, it would add more than one instruction - otherwise, the signal handlers might have to be updated. > We can switch to an actual call in the generated code and adjust the deopt_pc test in the frame code to look for the nmethod's deopt address plus some arch-specific constant offset. I believe this alternative approach would work. I am planning to spend some time to prototype this. Also, I'm attempting to find an approach which would not require each `nmethod` to have a deoptimization handler stub code - the per-nmethod offset to the "original PC" stack slot appears to be the main obstacle in this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3242134771 From cnorrbin at openjdk.org Mon Sep 1 12:27:43 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 1 Sep 2025 12:27:43 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock In-Reply-To: <-Z6DWW-tqahqtLzZt0ULHvFrTwL3uINZemJFO2OivhA=.0d918002-6ea9-4330-a97a-4b36521b7ab5@github.com> References: <-Z6DWW-tqahqtLzZt0ULHvFrTwL3uINZemJFO2OivhA=.0d918002-6ea9-4330-a97a-4b36521b7ab5@github.com> Message-ID: On Fri, 29 Aug 2025 19:02:16 GMT, Johan Sj?len wrote: >> Hi, >> >> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. > > src/hotspot/share/utilities/rbTree.hpp line 454: > >> 452: public: >> 453: RBTree() : BaseType(), _allocator() {} >> 454: RBTree(const RBTree& other) : BaseType(), _allocator() { > > @caspernorrbin , I added this. Does it look correct? Looks correct to me, as long as the value type can also be properly copy-constructible. Maybe we can add in an assert to avoid potential future misuse? :-) Something like: `assert(std::is_copy_constructible(), "Value type must be copy-constructible");` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27003#discussion_r2313812719 From duke at openjdk.org Mon Sep 1 12:55:31 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 1 Sep 2025 12:55:31 GMT Subject: RFR: 8366556: Sort share/runtime includes Message-ID: This PR sorts the includes in `hotspot/share/runtime` using `SortIncludes.java`, and removes some unnecessary ones. I'm also adding the directory to `TestIncludesAreSorted`. Passes tier1. ------------- Commit messages: - sort Changes: https://git.openjdk.org/jdk/pull/27034/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27034&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366556 Stats: 98 lines in 39 files changed: 45 ins; 52 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27034.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27034/head:pull/27034 PR: https://git.openjdk.org/jdk/pull/27034 From tschatzl at openjdk.org Mon Sep 1 12:59:41 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 1 Sep 2025 12:59:41 GMT Subject: RFR: 8366155: Serial: Obsolete PretenureSizeThreshold In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 11:44:35 GMT, Albert Mingkun Yang wrote: > Remove obj-size checking before young/old-gen allocation -- an allocation succeeds iff there is enough free space. > > This simplifies the allocation logic: > 1. before attempting gc: `mem_allocate_work` does young-gen allocation then old-gen-no-expansion allocation > 2. after gc (still inside gc safepoint): `satisfy_failed_allocation` does young-gen allocation old-gen-with-expansion allocation > > Test: tier1-3 Seems good. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26941#pullrequestreview-3173572869 From jsjolen at openjdk.org Mon Sep 1 13:15:45 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 1 Sep 2025 13:15:45 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock In-Reply-To: References: <-Z6DWW-tqahqtLzZt0ULHvFrTwL3uINZemJFO2OivhA=.0d918002-6ea9-4330-a97a-4b36521b7ab5@github.com> Message-ID: On Mon, 1 Sep 2025 12:25:25 GMT, Casper Norrbin wrote: >> src/hotspot/share/utilities/rbTree.hpp line 454: >> >>> 452: public: >>> 453: RBTree() : BaseType(), _allocator() {} >>> 454: RBTree(const RBTree& other) : BaseType(), _allocator() { >> >> @caspernorrbin , I added this. Does it look correct? > > Looks correct to me, as long as the value type can also be properly copy-constructible. Maybe we can add in an assert to avoid potential future misuse? :-) > > Something like: > `assert(std::is_copy_constructible(), "Value type must be copy-constructible");` Yeah, we can do that! I'll put it in a static_assert even. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27003#discussion_r2313930488 From ayang at openjdk.org Mon Sep 1 13:16:57 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 1 Sep 2025 13:16:57 GMT Subject: RFR: 8366556: Sort share/runtime includes In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 12:49:20 GMT, Francesco Andreuzzi wrote: > This PR sorts the includes in `hotspot/share/runtime` using `SortIncludes.java`, and removes some unnecessary ones. I'm also adding the directory to `TestIncludesAreSorted`. > > Passes tier1. A question regarding preexisting include; otherwise good. src/hotspot/share/runtime/flags/jvmFlagLimit.cpp line 26: > 24: > 25: #include "gc/shared/jvmFlagConstraintsGC.hpp" > 26: #include "gc/shared/referenceProcessor.hpp" Why is `referenceProcessor` needed in this file? ------------- Marked as reviewed by ayang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27034#pullrequestreview-3173626893 PR Review Comment: https://git.openjdk.org/jdk/pull/27034#discussion_r2313931861 From epeter at openjdk.org Mon Sep 1 13:17:46 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 1 Sep 2025 13:17:46 GMT Subject: RFR: 8360389: Support printing from C2 compiled code [v8] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 14:41:21 GMT, Beno?t Maillard wrote: >> This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types. >> >> ## Usage >> >> Suppose we have this piece of Java code, that simply computes an arithmetic operation, and >> that we compile `square` with C2. >> >> class Square { >> static int square(int a) { >> return a * a; >> } >> >> public static void main(String[] args) { >> square(9); >> } >> } >> >> >> We would like to inspect the node that contains the value returned in this method. >> We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect. >> >> ```c++ >> void Compile::return_values(JVMState* jvms) { >> GraphKit kit(jvms); >> Node* ret = new ReturnNode(TypeFunc::Parms, >> kit.control(), >> kit.i_o(), >> kit.reset_memory(), >> kit.frameptr(), >> kit.returnadr()); >> // Add zero or 1 return values >> int ret_size = tf()->range()->cnt() - TypeFunc::Parms; >> >> >> Node* return_value; >> if (ret_size > 0) { >> kit.inc_sp(-ret_size); // pop the return value(s) >> kit.sync_jvms(); >> return_value = kit.argument(0); >> ret->add_req(return_value); >> >> // <-------------------- Simply insert this >> C->make_debug_print("return: ", initial_gvn(), return_value); >> } >> >> // bind it to root >> root()->add_req(ret); >> record_for_igvn(ret); >> initial_gvn()->transform(ret); >> } >> >> >> We can then call run our code with `-XX:CompileCommand="compileonly,Square::square` >> and we get the following output: >> >> >> return: >> int 81 >> >> >> This case is of course trivial, but more useful examples are shown later. >> >> ## Implementation >> >> The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed. >> >> The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the ... > > Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision: > > Fix mismatch with #ifdef COMPILER2 between .hpp and .cpp I have not read the PR in any detail. Just tried to use it in a bug I'm trying to fix. [JDK-8366490](https://bugs.openjdk.org/browse/JDK-8366490) So I did this: diff --git a/src/hotspot/share/opto/vectorization.cpp b/src/hotspot/share/opto/vectorization.cpp index cd5aba6c31d..1b1f7c2f6f2 100644 --- a/src/hotspot/share/opto/vectorization.cpp +++ b/src/hotspot/share/opto/vectorization.cpp @@ -1046,6 +1046,8 @@ BoolNode* VPointer::make_speculative_aliasing_check_with(const VPointer& other) tty->print("size2: "); size2->dump(); tty->print_cr("span1: "); span1->dump_bfs(5, nullptr, ""); tty->print_cr("span2: "); span2->dump_bfs(5, nullptr, ""); + + phase->C->make_debug_print("span ", &igvn, span1); } #endif And ran my test: `./java -XX:CompileCommand=quiet -XX:CompileCommand=compileonly,Reduced1::test -XX:CompileCommand=printcompilation,Reduced1::* -XX:CompileCommand=dontinline,Reduced1::allocateArrays -XX:-TieredCompilation -Xbatch -XX:+StressGCM -XX:+TraceLoopOpts -XX:CompileCommand=TraceAutoVectorization,Reduced1::test,SW_INFO,SPECULATIVE_ALIASING_ANALYSIS -XX:+TraceNewVectors -XX:-LoopMultiversioning -XX:SuperWordAutomaticAlignment=0 -XX:+TraceDeoptimization Reduced1.java` class Reduced1 { static final int N = 400; static void allocateArrays() { for (int i = 0; 200_000 > i; ++i) { int[] a = new int[N]; } } static int[] test() { int a[] = new int[N]; allocateArrays(); for (int k = 0; k < 500; k++) { for (int i = 1; i < 69; i++) { a[i] = 14; a[4] -= 14; } } return a; } public static void main(String[] args) { int[] gold = test(); for (int r = 0; r < 10; r++) { int[] a = test(); System.out.println("a[4]: " + a[4]); if (a[4] != gold[4]) { throw new RuntimeException("wrong value " + gold[4] + " " + a[4]); } } } } But that got me some assert: # Internal Error (/home/empeter/Documents/oracle/jdk-fork2/open/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp:1126), pid=2630187, tid=2630207 # assert((i + 1) < total_args_passed && sig_bt[i + 1] == T_VOID) failed: expecting half 33 Stack: [0x00007fe32ed13000,0x00007fe32ee13000], sp=0x00007fe32ee0e8d0, free space=1006k 34 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) 35 V [libjvm.so+0x19a3163] SharedRuntime::c_calling_convention(BasicType const*, VMRegPair*, int)+0x673 (sharedRuntime_x86_64.cpp:1126) 36 V [libjvm.so+0x1658abe] Matcher::match_sfpt(SafePointNode*)+0xd6e (matcher.cpp:1396) 37 V [libjvm.so+0x165b695] Matcher::xform(Node*, int)+0x1075 (matcher.cpp:1159) 38 V [libjvm.so+0x1661b53] Matcher::match()+0x1113 (matcher.cpp:369) 39 V [libjvm.so+0xb7b6ce] Compile::Code_Gen()+0x1fe (compile.cpp:3024) 40 V [libjvm.so+0xb81103] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1fd3 (compile.cpp:892) 41 V [libjvm.so+0x9a1f76] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x466 (c2compiler.cpp:147) 42 V [libjvm.so+0xb904c8] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xb48 (compileBroker.cpp:2342) 43 V [libjvm.so+0xb91650] CompileBroker::compiler_thread_loop()+0x530 (compileBroker.cpp:1986) 44 V [libjvm.so+0x10f258b] JavaThread::thread_main_inner()+0x13b (javaThread.cpp:775) 45 V [libjvm.so+0x1b63d16] Thread::call_run()+0xb6 (thread.cpp:243) 46 V [libjvm.so+0x17d94d8] thread_native_entry(Thread*)+0x128 (os_linux.cpp:892) Am I doing something wrong here, or is that maybe a limitation of the current implementation? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26475#issuecomment-3242340816 From lkorinth at openjdk.org Mon Sep 1 13:21:49 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 13:21:49 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v9] In-Reply-To: References: Message-ID: > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: changed both test in GetStackTraceALotWhenBlocking to use timeout of 1200 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26749/files - new: https://git.openjdk.org/jdk/pull/26749/files/7ca719c8..5c0bcd19 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26749.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749 PR: https://git.openjdk.org/jdk/pull/26749 From jsjolen at openjdk.org Mon Sep 1 13:22:03 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 1 Sep 2025 13:22:03 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v2] In-Reply-To: References: Message-ID: <_elWT9cp-yBL5OiRriEiVRTq5JPu09BY6jxtjMw4GJI=.1df62cde-de1f-4703-9112-54d282a20a37@github.com> > Hi, > > The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Static assert copy-constructible ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27003/files - new: https://git.openjdk.org/jdk/pull/27003/files/958c9706..a125e582 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27003.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003 PR: https://git.openjdk.org/jdk/pull/27003 From tschatzl at openjdk.org Mon Sep 1 13:24:37 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 1 Sep 2025 13:24:37 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v51] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 68 commits: - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * fix merge error - * forgot to actually save the files - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * remove unused G1DetachedRefinementStats_lock - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - ... and 58 more: https://git.openjdk.org/jdk/compare/98af1892...4a41b40b ------------- Changes: https://git.openjdk.org/jdk/pull/23739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=50 Stats: 7100 lines in 112 files changed: 2584 ins; 3578 del; 938 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From duke at openjdk.org Mon Sep 1 13:26:37 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 1 Sep 2025 13:26:37 GMT Subject: RFR: 8366556: Sort share/runtime includes [v2] In-Reply-To: References: Message-ID: <2bvgNWeNmR_PeSKtYLaY0SG3Bf0wavjjnYRXwyczFsg=.d48df777-38b3-411d-ab05-d94e8479dd10@github.com> > This PR sorts the includes in `hotspot/share/runtime` using `SortIncludes.java`, and removes some unnecessary ones. I'm also adding the directory to `TestIncludesAreSorted`. > > Passes tier1. Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: nn ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27034/files - new: https://git.openjdk.org/jdk/pull/27034/files/0b29949f..279fb946 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27034&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27034&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27034.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27034/head:pull/27034 PR: https://git.openjdk.org/jdk/pull/27034 From duke at openjdk.org Mon Sep 1 13:26:39 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 1 Sep 2025 13:26:39 GMT Subject: RFR: 8366556: Sort share/runtime includes [v2] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 13:13:10 GMT, Albert Mingkun Yang wrote: >> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: >> >> nn > > src/hotspot/share/runtime/flags/jvmFlagLimit.cpp line 26: > >> 24: >> 25: #include "gc/shared/jvmFlagConstraintsGC.hpp" >> 26: #include "gc/shared/referenceProcessor.hpp" > > Why is `referenceProcessor` needed in this file? `jvmFlagLimit.cpp` does not seem to use any of the symbols declared by `referenceProcessor.hpp`, so I guess the include can be removed: 279fb9460609892c693280e0f7b5808da697343c ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27034#discussion_r2313953097 From cnorrbin at openjdk.org Mon Sep 1 13:40:28 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 1 Sep 2025 13:40:28 GMT Subject: RFR: 8366238: Improve RBTree API with stricter comparator semantics and pluggable validation/printing hooks. [v4] In-Reply-To: References: Message-ID: > Hi everyone, > > The current red-black tree can be made safer, and its inspection capabilities improved. > > As briefly discussed in #26904, `COMPARATOR::cmp` could be made clearer and more robust. In particular, its `int` return type invites unsafe `return a ? b` arithmetic, and the boolean validation function also named `cmp` is misleading. > > To address this, I?ve introduced the `RBTreeOrdering` enum, inspired by C++20?s `<=>`, which makes incorrect arithmetic impossible. The return type of `COMPARATOR::cmp` is now this enum, forcing users to write an explicit and safe comparison. From the discussion in that PR, I have also renamed the boolean `cmp` to `less`, making its purpose obvious and preventing confusion between the two functions. > > Inspection has also been improved, especially for intrusive trees. Previously, `verify_self` only verified core RB-tree properties, yet intrusive nodes often hold additional data with their own separate invariants. Users had to perform those checks in a second traversal, and if an error occurs `print_on` produced little diagnostic value by only printing node addresses. > > To solve this, the tree now accepts user-supplied verification and printing callables. This lets users validate their custom node data during the same walk and print richer information when errors occur. > > Everything is implemented via template parameters with set defaults, so existing code remains unchanged while new code can opt in to the expanded functionality. > > Testing: > - Oracle tiers 1-3 Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: johan feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26981/files - new: https://git.openjdk.org/jdk/pull/26981/files/f780a53e..f7ce633b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26981&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26981&range=02-03 Stats: 56 lines in 6 files changed: 8 ins; 0 del; 48 mod Patch: https://git.openjdk.org/jdk/pull/26981.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26981/head:pull/26981 PR: https://git.openjdk.org/jdk/pull/26981 From cnorrbin at openjdk.org Mon Sep 1 13:40:29 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 1 Sep 2025 13:40:29 GMT Subject: RFR: 8366238: Improve RBTree API with stricter comparator semantics and pluggable validation/printing hooks. [v3] In-Reply-To: References: <9p4A1E9arftDmwBvVfAMxnqbvBUZ9heQ4jbYXeEowrw=.76647921-46a2-4be2-9c7a-f19b167a71e9@github.com> Message-ID: <0-Qp9OoEh4x_uB6YBWqTJJiDwcFVnY9xRlqKf2oIBNY=.2f9b5c13-d577-41e2-bf2d-090ca66f07cf@github.com> On Mon, 1 Sep 2025 09:12:49 GMT, Johan Sj?len wrote: >> src/hotspot/share/utilities/rbTree.hpp line 65: >> >>> 63: // Nodes are address stable and will not change during its lifetime. >>> 64: >>> 65: enum class RBTreeOrdering : int { less = -1, equal = 0, greater = 1 }; >> >> Is assigning the elements to specific values necessary? > > Personally, I'd prefer LT, EQ, GT to be the enum members. I'd like to see a `TotalOrdering` enum class in the future, to replace this. I assigned the values so they'd be similar to the previous `int` return, not really needed. I don't mind the other names, so renamed to LT, EQ, GT and removed the values. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26981#discussion_r2313986169 From cnorrbin at openjdk.org Mon Sep 1 13:40:29 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 1 Sep 2025 13:40:29 GMT Subject: RFR: 8366238: Improve RBTree API with stricter comparator semantics and pluggable validation/printing hooks. [v3] In-Reply-To: References: <9p4A1E9arftDmwBvVfAMxnqbvBUZ9heQ4jbYXeEowrw=.76647921-46a2-4be2-9c7a-f19b167a71e9@github.com> Message-ID: <1Rnx8JXn2FoHMMFGa04Nm9kqTNqZdYXJv-ZoOlYIrA8=.41f1a1f2-23cd-4eff-8565-3ffd7e82b2fd@github.com> On Mon, 1 Sep 2025 09:08:00 GMT, Johan Sj?len wrote: >> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: >> >> albert feedback > > src/hotspot/share/utilities/rbTree.hpp line 133: > >> 131: size_t& tree_depth, bool expect_visited, NodeVerifier verifier, >> 132: const USER_VERIFIER& extra_verifier) const; >> 133: > > `NodeType` is unused. Here we have two different naming standards for the template name. `NodeType` is used in the inline file so is needed. Renamed `NodeVerifier` to `NODE_VERIFIER` to fit in with the other templates. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26981#discussion_r2313988884 From alanb at openjdk.org Mon Sep 1 13:55:46 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Sep 2025 13:55:46 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v9] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 13:21:49 GMT, Leo Korinth wrote: >> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). >> >> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have ploughed through test cases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> After the review, I will update the copyrights. >> >> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. >> >> I got 4 timing related faults: >> 1) runtime/Thread/TestThreadDumpMonitorContention.java >> This is probably: https://bugs.openjdk.org/browse/JDK-8361370 >> 2) sun/tools/jhsdb/BasicLauncherTest.java >> I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. >> 3) gc/stress/TestReclaimStringsLeaksMemory.java >> I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. >> 4) sun/security/ssl/X509KeyManager/CertChecking.java >> This is a new test that I got on last rebase. I have added a timeout of 480 to it. >> >> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. >> >> From the review of the cancelled "8356171: ... > > Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: > > changed both test in GetStackTraceALotWhenBlocking to use timeout of 1200 Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26749#pullrequestreview-3173774701 From tschatzl at openjdk.org Mon Sep 1 14:24:34 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 1 Sep 2025 14:24:34 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v52] In-Reply-To: References: Message-ID: <8ppqEuxHuhM5tXXssVXaq-uQlixvWerkx3UxT-XYTmg=.b6a5ee73-33f0-4f58-b14d-808895da6347@github.com> > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * commit merge changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/4a41b40b..b3873d66 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=51 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=50-51 Stats: 11 lines in 2 files changed: 0 ins; 11 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From bmaillard at openjdk.org Mon Sep 1 14:43:45 2025 From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard) Date: Mon, 1 Sep 2025 14:43:45 GMT Subject: RFR: 8360389: Support printing from C2 compiled code [v8] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 13:15:08 GMT, Emanuel Peter wrote: >> Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix mismatch with #ifdef COMPILER2 between .hpp and .cpp > > I have not read the PR in any detail. Just tried to use it in a bug I'm trying to fix. [JDK-8366490](https://bugs.openjdk.org/browse/JDK-8366490) > > So I did this: > > > diff --git a/src/hotspot/share/opto/vectorization.cpp b/src/hotspot/share/opto/vectorization.cpp > index cd5aba6c31d..1b1f7c2f6f2 100644 > --- a/src/hotspot/share/opto/vectorization.cpp > +++ b/src/hotspot/share/opto/vectorization.cpp > @@ -1046,6 +1046,8 @@ BoolNode* VPointer::make_speculative_aliasing_check_with(const VPointer& other) > tty->print("size2: "); size2->dump(); > tty->print_cr("span1: "); span1->dump_bfs(5, nullptr, ""); > tty->print_cr("span2: "); span2->dump_bfs(5, nullptr, ""); > + > + phase->C->make_debug_print("span ", &igvn, span1); > } > #endif > > > And ran my test: > `./java -XX:CompileCommand=quiet -XX:CompileCommand=compileonly,Reduced1::test -XX:CompileCommand=printcompilation,Reduced1::* -XX:CompileCommand=dontinline,Reduced1::allocateArrays -XX:-TieredCompilation -Xbatch -XX:+StressGCM -XX:+TraceLoopOpts -XX:CompileCommand=TraceAutoVectorization,Reduced1::test,SW_INFO,SPECULATIVE_ALIASING_ANALYSIS -XX:+TraceNewVectors -XX:-LoopMultiversioning -XX:SuperWordAutomaticAlignment=0 -XX:+TraceDeoptimization Reduced1.java` > > > class Reduced1 { > static final int N = 400; > > static void allocateArrays() { > for (int i = 0; 200_000 > i; ++i) { > int[] a = new int[N]; > } > } > > static int[] test() { > int a[] = new int[N]; > allocateArrays(); > for (int k = 0; k < 500; k++) { > for (int i = 1; i < 69; i++) { > a[i] = 14; > a[4] -= 14; > } > } > return a; > } > > public static void main(String[] args) { > int[] gold = test(); > for (int r = 0; r < 10; r++) { > int[] a = test(); > System.out.println("a[4]: " + a[4]); > if (a[4] != gold[4]) { > throw new RuntimeException("wrong value " + gold[4] + " " + a[4]); > } > } > } > } > > > But that got me some assert: > > # Internal Error (/home/empeter/Documents/oracle/jdk-fork2/open/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp:1126), pid=2630187, tid=2630207 > # assert((i + 1) < total_args_passed && sig_bt[i + 1] == T_VOID) failed: expecting half > > 33 Stack: [0x00007fe32ed13000,0x00007fe32ee13000], sp=0x00007fe32ee0e8d0, free space=1006k > 34 Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > 35 V [libjvm.so+0x19... When using `jlong` or `jdouble` you need to pass an additional placeholder half node @eme64. Here you can just do this: ```c++ phase->C->make_debug_print("span ", &igvn, span1, phase->C->top()); The first of the additional examples (identity optimizations) hints at this but I should have probably made it more explicit in the description. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26475#issuecomment-3242604663 From epeter at openjdk.org Mon Sep 1 14:43:46 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 1 Sep 2025 14:43:46 GMT Subject: RFR: 8360389: Support printing from C2 compiled code [v8] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 14:41:21 GMT, Beno?t Maillard wrote: >> This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types. >> >> ## Usage >> >> Suppose we have this piece of Java code, that simply computes an arithmetic operation, and >> that we compile `square` with C2. >> >> class Square { >> static int square(int a) { >> return a * a; >> } >> >> public static void main(String[] args) { >> square(9); >> } >> } >> >> >> We would like to inspect the node that contains the value returned in this method. >> We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect. >> >> ```c++ >> void Compile::return_values(JVMState* jvms) { >> GraphKit kit(jvms); >> Node* ret = new ReturnNode(TypeFunc::Parms, >> kit.control(), >> kit.i_o(), >> kit.reset_memory(), >> kit.frameptr(), >> kit.returnadr()); >> // Add zero or 1 return values >> int ret_size = tf()->range()->cnt() - TypeFunc::Parms; >> >> >> Node* return_value; >> if (ret_size > 0) { >> kit.inc_sp(-ret_size); // pop the return value(s) >> kit.sync_jvms(); >> return_value = kit.argument(0); >> ret->add_req(return_value); >> >> // <-------------------- Simply insert this >> C->make_debug_print("return: ", initial_gvn(), return_value); >> } >> >> // bind it to root >> root()->add_req(ret); >> record_for_igvn(ret); >> initial_gvn()->transform(ret); >> } >> >> >> We can then call run our code with `-XX:CompileCommand="compileonly,Square::square` >> and we get the following output: >> >> >> return: >> int 81 >> >> >> This case is of course trivial, but more useful examples are shown later. >> >> ## Implementation >> >> The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed. >> >> The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the ... > > Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision: > > Fix mismatch with #ifdef COMPILER2 between .hpp and .cpp Ah, I see! Could you verify that somehow in your function, to catch it early? Or is there any way we could drop the need for these place-holders? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26475#issuecomment-3242610980 From vaivanov at openjdk.org Mon Sep 1 15:31:48 2025 From: vaivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 1 Sep 2025 15:31:48 GMT Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays [v4] In-Reply-To: References: Message-ID: On Sat, 30 Aug 2025 16:04:00 GMT, Vladimir Ivanov wrote: >> On the SRF platform for runs with intrinsic scores for the ArrayFill test reports ~2x drop for several sizes due to a lot of the 'MEM_UOPS_RETIRED.SPLIT_STORES' events. The 'good' case for the ArraysFill.testCharFill with size=8195 reports numbers like >> MEM_UOPS_RETIRED.SPLIT_LOADS | 22.6711 >> MEM_UOPS_RETIRED.SPLIT_STORES | 4.0859 >> while for 'bad' case these metrics are >> MEM_UOPS_RETIRED.SPLIT_LOADS | 69.1785 >> MEM_UOPS_RETIRED.SPLIT_STORES | 259200.3659 >> >> With alignment on the cache size no score drops due to split_stores but small reduction may be reported due to extra >> SRF 6740E | Size | orig | pathed | pO/orig >> -- | -- | -- | -- | -- >> ArraysFill.testByteFill | 16 | 152031.2 | 157001.2 | 1.03 >> ArraysFill.testByteFill | 31 | 125795.9 | 177399.2 | 1.41 >> ArraysFill.testByteFill | 250 | 57961.69 | 120981.9 | 2.09 >> ArraysFill.testByteFill | 266 | 44900.15 | 147893.8 | 3.29 >> ArraysFill.testByteFill | 511 | 61908.17 | 129830.1 | 2.10 >> ArraysFill.testByteFill | 2047 | 32255.51 | 41986.6 | 1.30 >> ArraysFill.testByteFill | 2048 | 31928.97 | 42154.3 | 1.32 >> ArraysFill.testByteFill | 8195 | 10690.15 | 11036.3 | 1.03 >> ArraysFill.testIntFill | 16 | 145030.7 | 318796.9 | 2.20 >> ArraysFill.testIntFill | 31 | 134138.4 | 212487 | 1.58 >> ArraysFill.testIntFill | 250 | 74179.23 | 79522.66 | 1.07 >> ArraysFill.testIntFill | 266 | 68112.72 | 60116.49 | 0.88 >> ArraysFill.testIntFill | 511 | 39693.28 | 36225.09 | 0.91 >> ArraysFill.testIntFill | 2047 | 11504.14 | 10616.91 | 0.92 >> ArraysFill.testIntFill | 2048 | 11244.71 | 10969.14 | 0.98 >> ArraysFill.testIntFill | 8195 | 2751.289 | 2692.216 | 0.98 >> ArraysFill.testLongFill | 16 | 212532.5 | 212526 | 1.00 >> ArraysFill.testLongFill | 31 | 137432.4 | 137283.3 | 1.00 >> ArraysFill.testLongFill | 250 | 43185 | 43159.78 | 1.00 >> ArraysFill.testLongFill | 266 | 42172.22 | 42170.5 | 1.00 >> ArraysFill.testLongFill | 511 | 23370.15 | 23370.86 | 1.00 >> ArraysFill.testLongFill | 2047 | 6123.008 | 6122.73 | 1.00 >> ArraysFill.testLongFill | 2048 | 5793.722 | 5792.855 | 1.00 >> ArraysFill.testLongFill | 8195 | 616.552 | 616.585 | 1.00 >> ArraysFill.testShortFill | 16 | 152088.6 | 265646.1 | 1.75 >> ArraysFill.testShortFill | 31 | 137369.8 | 185596.4 | 1.35 >> ArraysFill.testShortFill | 250 | 58872.03 | 99621.15 | 1.69 >> ArraysFill.testShortFill | 266 | 91085.31 | 93746.62 | 1.03 >> ArraysFill.testShortFill | 511 | 65331.96 | 78003.83 | 1.19 >> ArraysFill.testShortFill | 2047 | 21716.32 | 21216.81 | 0.98 >> ArraysFill.testShortFill... > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays Later alignment improve performance a little bit. Current numbers are: SRF | size | jdk26 | patched with "+optFill" | patched/jdk26 ArraysFill.testByteFill | 16 | 151937.634 | 175045.819 | 1.15 ArraysFill.testByteFill | 31 | 125661.092 | 211226.668 | 1.68 ArraysFill.testByteFill | 250 | 57599.684 | 123670.638 | 2.15 ArraysFill.testByteFill | 266 | 44617.505 | 147306.352 | 3.30 ArraysFill.testByteFill | 511 | 61541.499 | 129234.48 | 2.10 ArraysFill.testByteFill | 2047 | 32073.997 | 41503.438 | 1.29 ArraysFill.testByteFill | 2048 | 31729.263 | 41977.271 | 1.32 ArraysFill.testByteFill | 8195 | 10620.363 | 10911.334 | 1.03 ArraysFill.testIntFill | 16 | 144924.577 | 264101.45 | 1.82 ArraysFill.testIntFill | 31 | 128877.207 | 211225.233 | 1.64 ArraysFill.testIntFill | 250 | 73785.182 | 79204.674 | 1.07 ArraysFill.testIntFill | 266 | 67703.171 | 75436.831 | 1.11 ArraysFill.testIntFill | 511 | 39489.095 | 36011.078 | 0.91 ArraysFill.testIntFill | 2047 | 11431.835 | 10509.545 | 0.92 ArraysFill.testIntFill | 2048 | 11178.661 | 10882.991 | 0.97 ArraysFill.testIntFill | 8195 | 2629.065 | 2601.19 | 0.99 ArraysFill.testLongFill | 16 | 211218.892 | 211250.585 | 1.00 ArraysFill.testLongFill | 31 | 133026.186 | 137374.876 | 1.03 ArraysFill.testLongFill | 250 | 42907.745 | 42937.988 | 1.00 ArraysFill.testLongFill | 266 | 41935.645 | 41920.801 | 1.00 ArraysFill.testLongFill | 511 | 23217.606 | 23227.904 | 1.00 ArraysFill.testLongFill | 2047 | 6083.099 | 6083.384 | 1.00 ArraysFill.testLongFill | 2048 | 5751.203 | 5753.409 | 1.00 ArraysFill.testLongFill | 8195 | 612.17 | 612.634 | 1.00 ArraysFill.testShortFill | 16 | 151917.079 | 352122.571 | 2.32 ArraysFill.testShortFill | 31 | 138000.217 | 226271.221 | 1.64 ArraysFill.testShortFill | 250 | 58641.362 | 99043.571 | 1.69 ArraysFill.testShortFill | 266 | 90499.649 | 93200.335 | 1.03 ArraysFill.testShortFill | 511 | 64958.462 | 77930.734 | 1.20 ArraysFill.testShortFill | 2047 | 21577.954 | 21210.006 | 0.98 ArraysFill.testShortFill | 2048 | 21538.005 | 21429.382 | 0.99 ArraysFill.testShortFill | 8195 | 5883.097 | 5775.499 | 0.98 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26747#issuecomment-3242746861 From lkorinth at openjdk.org Mon Sep 1 16:00:47 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 16:00:47 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: <9X-5PBm7G1Y8vJ8bw02E501aWdgleLyUWMk3nhSrF08=.bb490a54-e687-49cc-9ecc-df7c051eef18@github.com> On Fri, 22 Aug 2025 15:46:18 GMT, Albert Mingkun Yang wrote: >> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision: >> >> update testing.md, remove makefile link, fix bad text > > test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java line 31: > >> 29: * @compile SuspendResume2.java >> 30: * @run driver jdk.test.lib.FileInstaller . . >> 31: * @run main/othervm/native/timeout=700 > > Why `700` instead of `480` in this file? I think this is one of the earlier tests that failed with a timeout factor of `0.7` on 480. Later on I doubled it, but here I was a bit more conservative. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2314279387 From lkorinth at openjdk.org Mon Sep 1 16:09:44 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 1 Sep 2025 16:09:44 GMT Subject: RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v5] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 13:48:10 GMT, Albert Mingkun Yang wrote: >> It is a way to give a "4x" lowest value, while not multiplying a 10x factor with four resulting in a 40x factor. I think (but I am not sure) that it would sometime time out if I only used the given timeout factor and not "guarding" with the max(x, 4). > >> while not multiplying a 10x factor with four resulting in a 40x factor. > > Why is that undesirable? The base is `(HOLD_TARGET_TIME + 30000) * 4` and the timeout-factor changes that linearly. Using `max(..., 4)` here may come as a surprise to end users, IMO. Because 40x is a very large timeout factor. I think I might misunderstand you in some way. My change is conservative, and will give a timeout that is not smaller than before (but can be larger if an explicit (non-default) timeout factor less than 4 was used before). Does that make sense, or do I answer something different from what you are asking? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2314295263 From david.holmes at oracle.com Mon Sep 1 21:26:42 2025 From: david.holmes at oracle.com (David Holmes) Date: Tue, 2 Sep 2025 07:26:42 +1000 Subject: Random crashes/failures on Linux Aarch64 In-Reply-To: <9c47ee52-fddc-42b8-8f31-680e6d1ca676@littlepinkcloud.com> References: <9c47ee52-fddc-42b8-8f31-680e6d1ca676@littlepinkcloud.com> Message-ID: Hi Andrew, On 1/09/2025 8:20 pm, Andrew Haley wrote: > On 25/08/2025 00:03, David Holmes wrote: >> Still collecting data and trying to see the pattern(s) here, but was >> wondering if other CI's have also been seeing any issues? > > I'm not aware of any. Do you know when this started happening? We have tracked this down to the introduction of new hardware in our CI at the start of August. David From dholmes at openjdk.org Mon Sep 1 22:02:44 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 1 Sep 2025 22:02:44 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 11:36:21 GMT, Kerem Kat wrote: > Prevents segmentation faults during `gdb` sessions. The crashes were caused by the `ResourceMark` constructor being called on a native thread, which is not supported. This happened when invoking debug commands that require a `Thread` or `JavaThread` context from an incorrect thread type. > > ### Solution > > This change introduces `onThread()` and `onJavaThread()` helper methods to the `Command` class. These methods validate the thread context and ensure `ResourceMark` is only created when on a valid VM thread. All thread-dependent debug commands now use these guards to validate the context, printing a clear error and exiting gracefully upon failure. > > ### Testing > > Manually verified using `gdb` by calling the modified commands (`ps`, `universe`, `pns`, etc.) from different thread contexts (native, Java, and non-java threads) to ensure they fail gracefully with an error message instead of crashing the debug session. We typically assume the user knows what they are doing at this level, but I suppose making it a little more robust doesn't hurt. I don't think we quite need everything though. Thanks src/hotspot/share/utilities/debug.cpp line 326: > 324: } > 325: > 326: if (!_has_rm) { Is it even possible for this not to be false with correct usage? src/hotspot/share/utilities/debug.cpp line 327: > 325: > 326: if (!_has_rm) { > 327: ::new (&_rm) ResourceMark(); There should be `#include ` to use global placement-new. src/hotspot/share/utilities/debug.cpp line 341: > 339: } > 340: return true; > 341: } I don't think we need this. The commands that require a JavaThread should be checking that directly themselves. Typically we assume/expect the person debugging to know what they are dealing with and use the appropriate commands. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27033#pullrequestreview-3174512977 PR Review Comment: https://git.openjdk.org/jdk/pull/27033#discussion_r2314601972 PR Review Comment: https://git.openjdk.org/jdk/pull/27033#discussion_r2314595903 PR Review Comment: https://git.openjdk.org/jdk/pull/27033#discussion_r2314599669 From lmesnik at openjdk.org Tue Sep 2 01:16:55 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 2 Sep 2025 01:16:55 GMT Subject: RFR: 8365937: post_method_exit might incorrectly set was_popped_by_exception and value in the middle of stack unwinding [v4] In-Reply-To: <1n0gbxAE37Nf7SHwUFLwCr1fJ2W4EuPh88kxMyO8un0=.5e803b50-f08f-4887-8d4c-3eb37156a754@github.com> References: <2SqwKSSfcLR6krBk2CYQZ8Q5X2T1eK4gaM4D6Hte2WA=.f4e906aa-4ffe-4d50-ba59-0ef12fb2f790@github.com> <1n0gbxAE37Nf7SHwUFLwCr1fJ2W4EuPh88kxMyO8un0=.5e803b50-f08f-4887-8d4c-3eb37156a754@github.com> Message-ID: On Mon, 1 Sep 2025 05:19:51 GMT, David Holmes wrote: >> Sorry I still can't see this. Method A throws an exception. The callback for the method-exit event for method A then invokes Java method B. Method B also has a callback enabled and so we are processing the method-exit for B. Method B has completed normally, but the exception from method A is still listed as pending? I can't see how that would come about as we must (temporarily) clear the pending exception to do the upcall else the upcall method would immediately throw that pending exception. But if we have cleared it then the upcall method's method-exit event shouldn't be able to see it. Similarly we must save/restore the JvmtiThreadState else we would be processing the normal exit as if it were an exception one. > > Or mabye I do get it. The actual pending exception (on the ThreadShadow) must be saved, cleared and later restored, else we can't execute the Java upcall. But because we have separate paths for normal and exceptional method-exit processing, maybe we don't have to save/restore the JvmtiThreadState exception fields? But in that case are those fields even useful? To be honest I can't see how the two fields interact: there is either no exception being thrown, or there is - so only one field needed. BTW, I forget to mention that the `state->is_exception_detected() && !state->is_exception_caught();` is just the same as `state->is_exception_detected()` Because exception state is enum an if it is `ES_DETECTED` then it can't be `ES_CAUGHT`. Am I understand correctly, that you propose to clear/restore `_exception_state` for any upcall since it is the separate execution path? In this case it should be done in every place where java is called from vm while exception is in detected state. It makes sense to keep this field consistent. I looked on the `_exception_state` in the `JvmtiThreadState` and is also used in the `notice_unwind_due_to_exception`. But it is unclear how it can be false in this method. Also, it is used in the `post_exception_throw` and it also unclear what is checked there. And seems it is not used in any other places. So, probably, this state is not useful if method exit/exception posting work without it. Or it is needed to find all places where it is should be saved/restored. It might includes methodExit events but there are other places that should be fixed. It is needed to change this line to assertion and see where it is hit. However, I think it could be done separately. It is too complicated for this fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2314718031 From iklam at openjdk.org Tue Sep 2 01:38:16 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 2 Sep 2025 01:38:16 GMT Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns InstanceKlass* Message-ID: By adding an `InstanceKlass* InstanceKlass::super()` method to shadow `Klass* Klass:super()`, this PR makes it possible to simplify the following code InstanceKlass* ik; InstanceKlass* s; s = InstanceKlass::cast(ik->super()); // before JDK-8366024 s = ik->java_super(); // after JDK-8366024 to s = k->super(); So you no longer need to do casting or need to understand what `java_super()` is. ------------- Commit messages: - 8366584: Add an InstanceKlass::super() method that returns InstanceKlass* Changes: https://git.openjdk.org/jdk/pull/27037/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27037&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366584 Stats: 91 lines in 28 files changed: 8 ins; 2 del; 81 mod Patch: https://git.openjdk.org/jdk/pull/27037.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27037/head:pull/27037 PR: https://git.openjdk.org/jdk/pull/27037 From dholmes at openjdk.org Tue Sep 2 03:57:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 2 Sep 2025 03:57:53 GMT Subject: RFR: 8365937: post_method_exit might incorrectly set was_popped_by_exception and value in the middle of stack unwinding [v4] In-Reply-To: References: <2SqwKSSfcLR6krBk2CYQZ8Q5X2T1eK4gaM4D6Hte2WA=.f4e906aa-4ffe-4d50-ba59-0ef12fb2f790@github.com> <1n0gbxAE37Nf7SHwUFLwCr1fJ2W4EuPh88kxMyO8un0=.5e803b50-f08f-4887-8d4c-3eb37156a754@github.com> Message-ID: <3XY_bM2M8_J57W_owMK6TRa2bQWELfIpVd4KvCPGvcI=.348b3b15-6b59-41f6-a8ea-051eb8a5a0c0@github.com> On Tue, 2 Sep 2025 01:13:40 GMT, Leonid Mesnik wrote: >> Or mabye I do get it. The actual pending exception (on the ThreadShadow) must be saved, cleared and later restored, else we can't execute the Java upcall. But because we have separate paths for normal and exceptional method-exit processing, maybe we don't have to save/restore the JvmtiThreadState exception fields? But in that case are those fields even useful? To be honest I can't see how the two fields interact: there is either no exception being thrown, or there is - so only one field needed. > > BTW, I forget to mention that the > `state->is_exception_detected() && !state->is_exception_caught();` > is just the same as > `state->is_exception_detected()` > Because exception state is enum an if it is `ES_DETECTED` then it can't be `ES_CAUGHT`. > > Am I understand correctly, that you propose to clear/restore `_exception_state` for any upcall since it is the separate execution path? In this case it should be done in every place where java is called from vm while exception is in detected state. It makes sense to keep this field consistent. > > I looked on the `_exception_state` in the `JvmtiThreadState` and is also used in the `notice_unwind_due_to_exception`. But it is unclear how it can be false in this method. > Also, it is used in the `post_exception_throw` and it also unclear what is checked there. And seems it is not used in any other places. > > So, probably, this state is not useful if method exit/exception posting work without it. Or it is needed to find all places where it is should be saved/restored. It might includes methodExit events but there are other places that should be fixed. It is needed to change this line to assertion and see where it is hit. > However, I think it could be done separately. It is too complicated for this fix. I think this state, and its use, needs more examination, but yes that can be deferred to another issue. Thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26886#discussion_r2314852578 From dholmes at openjdk.org Tue Sep 2 04:01:49 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 2 Sep 2025 04:01:49 GMT Subject: RFR: 8366456: Allow AllocFailStrategy for RBTree [v2] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 08:57:30 GMT, Johan Sj?len wrote: >> Right now the RBTree forces you to use the intrusive tree if you want fine-grained control of the out-of-memory strategy of the node allocations. We can change this to be a bit more flexible. >> >> One of the tests were incorrectly indented, so I fixed that. I also changed from `typedef` to `using`, turns out that `typedef` can give strange errors when the template instantiation is incorrect[0]. >> >> [0] For my particular gcc > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Remove Please remember the 24 hour rule for integrations as well. Thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/27011#issuecomment-3243702148 From dholmes at openjdk.org Tue Sep 2 04:45:41 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 2 Sep 2025 04:45:41 GMT Subject: RFR: 8366556: Sort share/runtime includes [v2] In-Reply-To: <2bvgNWeNmR_PeSKtYLaY0SG3Bf0wavjjnYRXwyczFsg=.d48df777-38b3-411d-ab05-d94e8479dd10@github.com> References: <2bvgNWeNmR_PeSKtYLaY0SG3Bf0wavjjnYRXwyczFsg=.d48df777-38b3-411d-ab05-d94e8479dd10@github.com> Message-ID: On Mon, 1 Sep 2025 13:26:37 GMT, Francesco Andreuzzi wrote: >> This PR sorts the includes in `hotspot/share/runtime` using `SortIncludes.java`, and removes some unnecessary ones. I'm also adding the directory to `TestIncludesAreSorted`. >> >> Passes tier1. > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > nn Looks good. I don't agree with the way `SortIncludes` handles underscore, but that is a separate matter. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27034#pullrequestreview-3174852048 From dholmes at openjdk.org Tue Sep 2 05:39:49 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 2 Sep 2025 05:39:49 GMT Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns InstanceKlass* In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 01:31:59 GMT, Ioi Lam wrote: > By adding an `InstanceKlass* InstanceKlass::super()` method to shadow `Klass* Klass:super()`, this PR makes it possible to simplify the following code > > > InstanceKlass* ik; > InstanceKlass* s; > s = InstanceKlass::cast(ik->super()); // before JDK-8366024 > s = ik->java_super(); // after JDK-8366024 > > > to > > > s = k->super(); > > > So you no longer need to do casting or need to understand what `java_super()` is. Looks good! Great to see all those `java_super()` calls disappear. A couple of nits/comments. Thanks src/hotspot/share/memory/heapInspection.cpp line 405: > 403: bool print_subclasses) { > 404: // Set do_print for all superclasses of this class. > 405: InstanceKlass* super = InstanceKlass::cast(cie->klass())->super(); Pre-existing, but if this cast is safe then `KlassInfoEntry::_klass` should be declared `InstanceKlass`. Otherwise this cast is not safe! Separate RFE for that. src/hotspot/share/oops/instanceKlass.hpp line 921: > 919: } > 920: > 921: // This shadows Klass::super(). The _super of an InstanceKlass is Suggestion: // This overrides Klass::super(). The _super of an InstanceKlass is src/hotspot/share/oops/instanceKlass.hpp line 924: > 922: // always an InstanceKlass (or nullptr) > 923: InstanceKlass* super() const { > 924: return (Klass::super() == nullptr) ? nullptr : InstanceKlass::cast(Klass::super()); Is it better/simpler/cleaner to just do: return static_cast(Klass::super()); ? src/hotspot/share/oops/klassVtable.cpp line 1574: > 1572: Klass* super = _klass->super(); > 1573: if (super != nullptr) { > 1574: InstanceKlass* sk = InstanceKlass::cast(super); // why are we sure this is InstanceKlass?? I don't think it is guaranteed to be an IK. But AFAICS we don't actually need an IK here anyway, we should be able to use `super` directly. ------------- PR Review: https://git.openjdk.org/jdk/pull/27037#pullrequestreview-3174870461 PR Review Comment: https://git.openjdk.org/jdk/pull/27037#discussion_r2314910364 PR Review Comment: https://git.openjdk.org/jdk/pull/27037#discussion_r2314913536 PR Review Comment: https://git.openjdk.org/jdk/pull/27037#discussion_r2314912896 PR Review Comment: https://git.openjdk.org/jdk/pull/27037#discussion_r2314951109 From jsjolen at openjdk.org Tue Sep 2 06:42:43 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 2 Sep 2025 06:42:43 GMT Subject: RFR: 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown [v2] In-Reply-To: References: <3TJnBvDoAPUf4p2e8Y0vpckfm3v8e31cKKwfOeyRnnM=.34c016f4-419d-4dd6-9102-b112a7423f7b@github.com> Message-ID: On Fri, 29 Aug 2025 01:02:43 GMT, David Holmes wrote: >> `ostream_exit` was deleting the stream underlying the `xtty` prior to nulling the `xtty` global variable, resulting in a use-after-free-error. Due to races during VM shutdown we cannot make use of `xtty` perfectly safe, but we can certainly narrow the window during which use-after-free is possible. >> >> Testing: >> - tiers 1-3 sanity >> >> Thanks > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into 8364735-xtty > - 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown After considering all of the discussions above and David's subsequent investigation, I think it seems reasonable to accept David's fix. Perhaps a refactoring is due, but that can be in a future PR. ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26832#pullrequestreview-3175082255 From jsjolen at openjdk.org Tue Sep 2 07:03:27 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 2 Sep 2025 07:03:27 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v3] In-Reply-To: References: Message-ID: > Hi, > > The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Add misisng locks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27003/files - new: https://git.openjdk.org/jdk/pull/27003/files/a125e582..800eca26 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=01-02 Stats: 31 lines in 3 files changed: 16 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/27003.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003 PR: https://git.openjdk.org/jdk/pull/27003 From jsjolen at openjdk.org Tue Sep 2 07:07:41 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 2 Sep 2025 07:07:41 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v3] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 07:03:27 GMT, Johan Sj?len wrote: >> Hi, >> >> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. > > Johan Sj?len has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. Oops, I accidentally committed to my current branch, I meant to commit to a new one. I'm going to rewrite history a bit, sorry bot. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27003#issuecomment-3244054097 From dholmes at openjdk.org Tue Sep 2 07:10:43 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 2 Sep 2025 07:10:43 GMT Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns InstanceKlass* In-Reply-To: References: Message-ID: <-jsZbxQ5S-quQBlUaeX5L_uu9f1oZGprF3COQgXUlwg=.4e173397-8a0f-43c5-980c-4f78fee8e59c@github.com> On Tue, 2 Sep 2025 04:59:37 GMT, David Holmes wrote: >> By adding an `InstanceKlass* InstanceKlass::super()` method to shadow `Klass* Klass:super()`, this PR makes it possible to simplify the following code >> >> >> InstanceKlass* ik; >> InstanceKlass* s; >> s = InstanceKlass::cast(ik->super()); // before JDK-8366024 >> s = ik->java_super(); // after JDK-8366024 >> >> >> to >> >> >> s = k->super(); >> >> >> So you no longer need to do casting or need to understand what `java_super()` is. > > src/hotspot/share/oops/instanceKlass.hpp line 921: > >> 919: } >> 920: >> 921: // This shadows Klass::super(). The _super of an InstanceKlass is > > Suggestion: > > // This overrides Klass::super(). The _super of an InstanceKlass is Correction: this is not "overriding" as defined by C++. "shadow" is fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27037#discussion_r2315125979 From lkorinth at openjdk.org Tue Sep 2 07:29:57 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 2 Sep 2025 07:29:57 GMT Subject: Integrated: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth wrote: > This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one) > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files). > > My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have ploughed through test cases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > After the review, I will update the copyrights. > > I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7. > > I got 4 timing related faults: > 1) runtime/Thread/TestThreadDumpMonitorContention.java > This is probably: https://bugs.openjdk.org/browse/JDK-8361370 > 2) sun/tools/jhsdb/BasicLauncherTest.java > I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky. > 3) gc/stress/TestReclaimStringsLeaksMemory.java > I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones. > 4) sun/security/ssl/X509KeyManager/CertChecking.java > This is a new test that I got on last rebase. I have added a timeout of 480 to it. > > In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got. > > From the review of the cancelled "8356171: Increase timeout for test cases as preparation for change of... This pull request has now been integrated. Changeset: 55e7af05 Author: Leo Korinth URL: https://git.openjdk.org/jdk/commit/55e7af0560335ef69af072cee60956cf8e6d00a1 Stats: 901 lines in 342 files changed: 51 ins; 91 del; 759 mod 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 Reviewed-by: alanb, sspitsyn, lmesnik, ihse ------------- PR: https://git.openjdk.org/jdk/pull/26749 From duke at openjdk.org Tue Sep 2 07:55:45 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Tue, 2 Sep 2025 07:55:45 GMT Subject: RFR: 8366556: Sort share/runtime includes [v2] In-Reply-To: References: <2bvgNWeNmR_PeSKtYLaY0SG3Bf0wavjjnYRXwyczFsg=.d48df777-38b3-411d-ab05-d94e8479dd10@github.com> Message-ID: On Tue, 2 Sep 2025 04:42:54 GMT, David Holmes wrote: > I don't agree with the way SortIncludes handles underscore, but that is a separate matter. @dholmes-ora should this be discussed somewhere? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27034#issuecomment-3244204874 From duke at openjdk.org Tue Sep 2 07:55:46 2025 From: duke at openjdk.org (duke) Date: Tue, 2 Sep 2025 07:55:46 GMT Subject: RFR: 8366556: Sort share/runtime includes [v2] In-Reply-To: <2bvgNWeNmR_PeSKtYLaY0SG3Bf0wavjjnYRXwyczFsg=.d48df777-38b3-411d-ab05-d94e8479dd10@github.com> References: <2bvgNWeNmR_PeSKtYLaY0SG3Bf0wavjjnYRXwyczFsg=.d48df777-38b3-411d-ab05-d94e8479dd10@github.com> Message-ID: On Mon, 1 Sep 2025 13:26:37 GMT, Francesco Andreuzzi wrote: >> This PR sorts the includes in `hotspot/share/runtime` using `SortIncludes.java`, and removes some unnecessary ones. I'm also adding the directory to `TestIncludesAreSorted`. >> >> Passes tier1. > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > nn @fandreuz Your change (at version 279fb9460609892c693280e0f7b5808da697343c) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27034#issuecomment-3244206317 From dholmes at openjdk.org Tue Sep 2 07:57:47 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 2 Sep 2025 07:57:47 GMT Subject: RFR: 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown [v2] In-Reply-To: References: <3TJnBvDoAPUf4p2e8Y0vpckfm3v8e31cKKwfOeyRnnM=.34c016f4-419d-4dd6-9102-b112a7423f7b@github.com> Message-ID: On Tue, 2 Sep 2025 06:39:48 GMT, Johan Sj?len wrote: >> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' into 8364735-xtty >> - 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown > > After considering all of the discussions above and David's subsequent investigation, I think it seems reasonable to accept David's fix. Perhaps a refactoring is due, but that can be in a future PR. Thanks for the Review @jdksjolen ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26832#issuecomment-3244213009 From duke at openjdk.org Tue Sep 2 07:59:52 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Tue, 2 Sep 2025 07:59:52 GMT Subject: Integrated: 8366556: Sort share/runtime includes In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 12:49:20 GMT, Francesco Andreuzzi wrote: > This PR sorts the includes in `hotspot/share/runtime` using `SortIncludes.java`, and removes some unnecessary ones. I'm also adding the directory to `TestIncludesAreSorted`. > > Passes tier1. This pull request has now been integrated. Changeset: d19eab4f Author: Francesco Andreuzzi Committer: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/d19eab4f08592140229de43689c7d20ff7fbf4ee Stats: 97 lines in 39 files changed: 44 ins; 52 del; 1 mod 8366556: Sort share/runtime includes Reviewed-by: dholmes, ayang ------------- PR: https://git.openjdk.org/jdk/pull/27034 From dholmes at openjdk.org Tue Sep 2 08:06:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 2 Sep 2025 08:06:53 GMT Subject: RFR: 8366556: Sort share/runtime includes [v2] In-Reply-To: References: <2bvgNWeNmR_PeSKtYLaY0SG3Bf0wavjjnYRXwyczFsg=.d48df777-38b3-411d-ab05-d94e8479dd10@github.com> Message-ID: On Tue, 2 Sep 2025 07:52:42 GMT, Francesco Andreuzzi wrote: > > I don't agree with the way SortIncludes handles underscore, but that is a separate matter. > > @dholmes-ora should this be discussed somewhere? It's okay we had an internal discussion and revisited the history. Thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/27034#issuecomment-3244238501 From azafari at openjdk.org Tue Sep 2 09:02:43 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 2 Sep 2025 09:02:43 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v2] In-Reply-To: <_elWT9cp-yBL5OiRriEiVRTq5JPu09BY6jxtjMw4GJI=.1df62cde-de1f-4703-9112-54d282a20a37@github.com> References: <_elWT9cp-yBL5OiRriEiVRTq5JPu09BY6jxtjMw4GJI=.1df62cde-de1f-4703-9112-54d282a20a37@github.com> Message-ID: <3gCtC-iqis4JAN5y07b-N3K7uHyvHfQD_xsZSDd5Hmc=.c6401659-f561-448d-8bfe-d67dd74ccaa4@github.com> On Mon, 1 Sep 2025 13:22:03 GMT, Johan Sj?len wrote: >> Hi, >> >> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Static assert copy-constructible Thank you @jdksjolen for taking this issue. I have only one concern when we copy a RBTree to a new one. We do a `visit_in_order` on the source tree and `upsert` the key-value to the destination tree. We do a sorted access on both trees. We can avoid one, by a new function like: `visit_all()` for the source tree, or for the destination tree use the `hint_node` somehow (that I don't know how, ping @caspernorrbin) in `RBTree::upsert(K, V, Node* hint_node)` ------------- PR Review: https://git.openjdk.org/jdk/pull/27003#pullrequestreview-3175564256 From azafari at openjdk.org Tue Sep 2 09:11:49 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 2 Sep 2025 09:11:49 GMT Subject: RFR: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp [v6] In-Reply-To: References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> Message-ID: On Wed, 27 Aug 2025 13:57:01 GMT, Kim Barrett wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> used CONST64 for all 64-bits const terms. > > Looks good. Thank you @kimbarrett, @theRealAph and @stefank for your reviews and comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26809#issuecomment-3244465409 From azafari at openjdk.org Tue Sep 2 09:11:50 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 2 Sep 2025 09:11:50 GMT Subject: Integrated: 8365163: [ubsan] left-shift issue in globalDefinitions.hpp In-Reply-To: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> References: <0YDgbtjVs6gVs9Qt79hGrtcdgF5XNEOWzQdejP-s4sQ=.bfaf422f-489f-414c-8ad3-a3d0eb35af4c@github.com> Message-ID: On Sun, 17 Aug 2025 06:49:47 GMT, Afshin Zafari wrote: > There was a left-shift of negative value UB in `set_high` function where the high value sign bit is on and is left-shifted 32 bits to put it in high word of the destination address. > To address it, first the left 32 bits of the provided `high` arg is cleared and then left-shifted 32 bits. > > Tests: > mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product} This pull request has now been integrated. Changeset: ef7872cc Author: Afshin Zafari URL: https://git.openjdk.org/jdk/commit/ef7872cc31d4d7c0a9f311eafc28132ead3476b6 Stats: 39 lines in 2 files changed: 27 ins; 8 del; 4 mod 8365163: [ubsan] left-shift issue in globalDefinitions.hpp Reviewed-by: kbarrett, stefank, aph ------------- PR: https://git.openjdk.org/jdk/pull/26809 From jpai at openjdk.org Tue Sep 2 09:36:46 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Sep 2025 09:36:46 GMT Subject: RFR: 8277444: Data race between JvmtiClassFileReconstituter::copy_bytecodes and class linking [v4] In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 22:48:06 GMT, Evgeny Astigeevich wrote: >> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. >> >> This PR adds linking a class before the `copy_bytecodes` method is called. >> The PR also adds a regression test. >> >> Tested fastdebug and release builds: Linux x86_64 and arm64 >> - The reproducer from JDK-8277444 passed. >> - The regression test passed. >> - Tier1 - tier3 passed. > > Evgeny Astigeevich 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 five additional commits since the last revision: > > - Merge branch 'master' into JDK-8277444 > - Link classes before copy_bytecodes; Add regression test > - Symplify comments; Get JavaThread::current in variable > - Add missing include runtime/synchronizer.hpp > - 8277444: Race condition on Instrumentation.retransformClasses() and class linking > The virtual thread test that is failing in this PR's GitHub actions job is `java/lang/Thread/virtual/stress/GetStackTraceALotWhenBlocking#id0` > It looks like it's taking long to complete and that's causing the test timeout. I recollect that this test failure was addressed some time back, so this appears to be a new occurrence. In any case, this failure doesn't look related to the changes in this PR because I see some other PRs having failed with this same issue. I'll check and file an issue later today/tomorrow (unless anyone else gets to it first). I've filed https://bugs.openjdk.org/browse/JDK-8366669 to track this failure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3244555487 From krk at openjdk.org Tue Sep 2 09:39:44 2025 From: krk at openjdk.org (Kerem Kat) Date: Tue, 2 Sep 2025 09:39:44 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 21:58:02 GMT, David Holmes wrote: >> Prevents segmentation faults during `gdb` sessions. The crashes were caused by the `ResourceMark` constructor being called on a native thread, which is not supported. This happened when invoking debug commands that require a `Thread` or `JavaThread` context from an incorrect thread type. >> >> ### Solution >> >> This change introduces `onThread()` and `onJavaThread()` helper methods to the `Command` class. These methods validate the thread context and ensure `ResourceMark` is only created when on a valid VM thread. All thread-dependent debug commands now use these guards to validate the context, printing a clear error and exiting gracefully upon failure. >> >> ### Testing >> >> Manually verified using `gdb` by calling the modified commands (`ps`, `universe`, `pns`, etc.) from different thread contexts (native, Java, and non-java threads) to ensure they fail gracefully with an error message instead of crashing the debug session. > > src/hotspot/share/utilities/debug.cpp line 326: > >> 324: } >> 325: >> 326: if (!_has_rm) { > > Is it even possible for this not to be false with correct usage? No, `onThread` would have to be called at least twice. > src/hotspot/share/utilities/debug.cpp line 327: > >> 325: >> 326: if (!_has_rm) { >> 327: ::new (&_rm) ResourceMark(); > > There should be `#include ` to use global placement-new. added, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27033#discussion_r2315520918 PR Review Comment: https://git.openjdk.org/jdk/pull/27033#discussion_r2315521505 From cnorrbin at openjdk.org Tue Sep 2 09:39:44 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Tue, 2 Sep 2025 09:39:44 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v2] In-Reply-To: <3gCtC-iqis4JAN5y07b-N3K7uHyvHfQD_xsZSDd5Hmc=.c6401659-f561-448d-8bfe-d67dd74ccaa4@github.com> References: <_elWT9cp-yBL5OiRriEiVRTq5JPu09BY6jxtjMw4GJI=.1df62cde-de1f-4703-9112-54d282a20a37@github.com> <3gCtC-iqis4JAN5y07b-N3K7uHyvHfQD_xsZSDd5Hmc=.c6401659-f561-448d-8bfe-d67dd74ccaa4@github.com> Message-ID: <870gPQnYOOc-Fy7DO7kUvAHoHqV3GjAfscrTIWczk_w=.706d8fb6-a4fb-418f-8f00-dbae474b36fa@github.com> On Tue, 2 Sep 2025 09:00:19 GMT, Afshin Zafari wrote: > We can avoid one, by a new function like: `visit_all()` for the source tree, or for the destination tree use the `hint_node` somehow (that I don't know how, ping @caspernorrbin) in `RBTree::upsert(K, V, Node* hint_node)` I don't think we would see much improvement iterating differently on the source tree. However, for the destination tree we traverse down the tree for each upsert, which could have quite an impact on large trees. `hint_node` decides where to start searching from, so if we cache the previous node we can avoid this traversal and start directly at the insert point. To achieve this we could change the return type of `upsert` from `void` to `RBNode*`, which is easily done and change the copy-constructor to something like: ```c++ RBTree(const RBTree& other) : BaseType(), _allocator() { static_assert(std::is_copy_constructible::value, "Key type must be copy-constructible when copying a RBTree"); static_assert(std::is_copy_constructible::value, "Value type must be copy-constructible when copying a RBTree"); RBNode* prev_node = nullptr; other.visit_in_order([&](RBNode* node) { RBNode* new_node = this->upsert(node->key(), node->val(), prev_node); prev_node = new_node; return true; }); } ------------- PR Comment: https://git.openjdk.org/jdk/pull/27003#issuecomment-3244565428 From jsjolen at openjdk.org Tue Sep 2 09:44:42 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 2 Sep 2025 09:44:42 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v2] In-Reply-To: <870gPQnYOOc-Fy7DO7kUvAHoHqV3GjAfscrTIWczk_w=.706d8fb6-a4fb-418f-8f00-dbae474b36fa@github.com> References: <_elWT9cp-yBL5OiRriEiVRTq5JPu09BY6jxtjMw4GJI=.1df62cde-de1f-4703-9112-54d282a20a37@github.com> <3gCtC-iqis4JAN5y07b-N3K7uHyvHfQD_xsZSDd5Hmc=.c6401659-f561-448d-8bfe-d67dd74ccaa4@github.com> <870gPQnYOOc-Fy7DO7kUvAHoHqV3GjAfscrTIWczk_w=.706d8fb6-a4fb-418f-8f00-dbae474b36fa@github.com> Message-ID: On Tue, 2 Sep 2025 09:37:02 GMT, Casper Norrbin wrote: > > We can avoid one, by a new function like: `visit_all()` for the source tree, or for the destination tree use the `hint_node` somehow (that I don't know how, ping @caspernorrbin) in `RBTree::upsert(K, V, Node* hint_node)` > > I don't think we would see much improvement iterating differently on the source tree. However, for the destination tree we traverse down the tree for each upsert, which could have quite an impact on large trees. `hint_node` decides where to start searching from, so if we cache the previous node we can avoid this traversal and start directly at the insert point. > > To achieve this we could change the return type of `upsert` from `void` to `RBNode*`, which is easily done and change the copy-constructor to something like: > > ```c++ > RBTree(const RBTree& other) : BaseType(), _allocator() { > static_assert(std::is_copy_constructible::value, "Key type must be copy-constructible when copying a RBTree"); > static_assert(std::is_copy_constructible::value, "Value type must be copy-constructible when copying a RBTree"); > RBNode* prev_node = nullptr; > other.visit_in_order([&](RBNode* node) { > RBNode* new_node = this->upsert(node->key(), node->val(), prev_node); > prev_node = new_node; > return true; > }); > } > ``` I think we need to switch out the iterator for that to make sense, specifically it needs to be DFS. Anyway, let's do that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27003#issuecomment-3244581331 From krk at openjdk.org Tue Sep 2 09:47:42 2025 From: krk at openjdk.org (Kerem Kat) Date: Tue, 2 Sep 2025 09:47:42 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 21:54:13 GMT, David Holmes wrote: >> Prevents segmentation faults during `gdb` sessions. The crashes were caused by the `ResourceMark` constructor being called on a native thread, which is not supported. This happened when invoking debug commands that require a `Thread` or `JavaThread` context from an incorrect thread type. >> >> ### Solution >> >> This change introduces `onThread()` and `onJavaThread()` helper methods to the `Command` class. These methods validate the thread context and ensure `ResourceMark` is only created when on a valid VM thread. All thread-dependent debug commands now use these guards to validate the context, printing a clear error and exiting gracefully upon failure. >> >> ### Testing >> >> Manually verified using `gdb` by calling the modified commands (`ps`, `universe`, `pns`, etc.) from different thread contexts (native, Java, and non-java threads) to ensure they fail gracefully with an error message instead of crashing the debug session. > > src/hotspot/share/utilities/debug.cpp line 341: > >> 339: } >> 340: return true; >> 341: } > > I don't think we need this. The commands that require a JavaThread should be checking that directly themselves. Typically we assume/expect the person debugging to know what they are dealing with and use the appropriate commands. I will remove this function and do the check in the 3 call sites of it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27033#discussion_r2315539345 From azafari at openjdk.org Tue Sep 2 09:56:45 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 2 Sep 2025 09:56:45 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v3] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 07:03:27 GMT, Johan Sj?len wrote: >> Hi, >> >> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. > > Johan Sj?len has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. When we do a `visit_in_order` we can set `next(right node)` of new nodes one by one. IOW, since Key-Values are retrieved in order, we can insert them one after another. Right? Inspired by the `visit_in_order()` itself: there we first get `leftmost()` and then use `next()` in a loop. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27003#issuecomment-3244624236 From krk at openjdk.org Tue Sep 2 10:08:58 2025 From: krk at openjdk.org (Kerem Kat) Date: Tue, 2 Sep 2025 10:08:58 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands [v2] In-Reply-To: References: Message-ID: > Prevents segmentation faults during `gdb` sessions. The crashes were caused by the `ResourceMark` constructor being called on a native thread, which is not supported. This happened when invoking debug commands that require a `Thread` or `JavaThread` context from an incorrect thread type. > > ### Solution > > This change introduces `onThread()` and `onJavaThread()` helper methods to the `Command` class. These methods validate the thread context and ensure `ResourceMark` is only created when on a valid VM thread. All thread-dependent debug commands now use these guards to validate the context, printing a clear error and exiting gracefully upon failure. > > ### Testing > > Manually verified using `gdb` by calling the modified commands (`ps`, `universe`, `pns`, etc.) from different thread contexts (native, Java, and non-java threads) to ensure they fail gracefully with an error message instead of crashing the debug session. Kerem Kat has updated the pull request incrementally with two additional commits since the last revision: - add include for global placement new - remove onJavaThread and check JavaThread::active null where needed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27033/files - new: https://git.openjdk.org/jdk/pull/27033/files/74d1e08b..0d3ded95 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27033&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27033&range=00-01 Stats: 30 lines in 1 file changed: 15 ins; 13 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27033.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27033/head:pull/27033 PR: https://git.openjdk.org/jdk/pull/27033 From adinn at openjdk.org Tue Sep 2 11:06:46 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 2 Sep 2025 11:06:46 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v4] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Thu, 21 Aug 2025 00:27:48 GMT, David Holmes wrote: >>> I'm not sure I'm really understanding the rules here. Is it the case that the old code would switch between write and exec in a more block structured pattern - changing when needed >> >> The old code doesn't change when needed but at every VM transition whether needed or not. But only 1% of VM transitions need to change. >> >>> and then restoring. But the new approach only changes when needed and never restores? >> >> More or less, yes. (Although obviously we have to reset the mode when returning from VM mode.) >> >>> If so then I worry that the need to change mode at any given point is a function of the code path to that point, rather than being an obvious property of the code itself. >> >> We change mode when we're _all but certain_ that we need to. That seems right to me. If the mode doesn't need changing because it's already set, that's OK. Why do you think this might be a problem? >> >>> The "healing" allows this to work, >> >> To be clear: healing never happens in testing. >> >>> but I'm not sure how you would ever explain the placement rules to anyone. ?? For example, I find the placement within the `Assembler` constructor extremely obscure but presumably the code that creates the `Assembler` instance then proceeds to use that instance to write into the code cache? >> >> Yes, exactly. We create Assembler instances whenever we need to generate code, and we don't share those instances, so the constructor is sweet spot to change mode. We don't keep Assembler instances hanging around. We could argue that this is temporal coupling, a code smell, but WX mode is a temporal property, so to a large extent that can't be helped.. > >> We change mode when we're _all but certain_ that we need to. That seems right to me. If the mode doesn't need changing because it's already set, that's OK. Why do you think this might be a problem? > > My concern is that if we have code that needs a specific mode, but it is not obvious at that piece of code that this is the case, then things will work fine if somewhere on the path to that code we set the right mode. But if we introduce a new path to that code that might not be the case and so we will introduce a new place where we switch modes. That can lead to redundancy. The whole thing (as it has from day one) seems ad-hoc. > > But if the proposed scheme performs better in general, and is not obviously "worse" from the ad-hoc perspective then ... @dholmes-ora I accept that this approach is not fully robust in the face of changes to the code base. However, in mitigation of that risk, the approach of targeting the major gateway calls that precede most subsequent code updates (e.g. creating an assembler instance) means that only a relatively small number of code paths which bypass those known gateways currently are, or will ever be, susceptible to such failure. Furthermore, weighed against that risk are 1) a mechanism we can use both to catch failures during testing and to avoid any danger when something escapes into production and 2) a significant gain in performance from avoiding (literally) millions of unnecessary transitions. I don't normally support pushing changes which are inherently fragile in the face of code updates. However, in this case I think the mechanisms in place to mitigate the risk and limit any damage and the performance gains to be had make it worth adopting. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26562#issuecomment-3244849530 From fbredberg at openjdk.org Tue Sep 2 11:07:00 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Tue, 2 Sep 2025 11:07:00 GMT Subject: RFR: 8365190: Remove LockingMode related code from share Message-ID: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR). This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself. Passes tier1-tier5 with no added problems. ------------- Commit messages: - 8365190: Remove LockingMode related code from share Changes: https://git.openjdk.org/jdk/pull/27041/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27041&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365190 Stats: 1268 lines in 50 files changed: 6 ins; 1129 del; 133 mod Patch: https://git.openjdk.org/jdk/pull/27041.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27041/head:pull/27041 PR: https://git.openjdk.org/jdk/pull/27041 From jsjolen at openjdk.org Tue Sep 2 11:13:45 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 2 Sep 2025 11:13:45 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v4] In-Reply-To: References: Message-ID: <4bty3Tqy3pgig2fRDijwX1frSvNQxXbYNgxQ6GVWQWE=.2df02b1e-022f-4e43-a9e4-8e1b7bd57d1b@github.com> > Hi, > > The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. Johan Sj?len has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Rewrite copying entirely ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27003/files - new: https://git.openjdk.org/jdk/pull/27003/files/800eca26..2e7bd8c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=02-03 Stats: 80 lines in 5 files changed: 40 ins; 18 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/27003.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003 PR: https://git.openjdk.org/jdk/pull/27003 From jsjolen at openjdk.org Tue Sep 2 11:23:01 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 2 Sep 2025 11:23:01 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v5] In-Reply-To: References: Message-ID: > Hi, > > The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision: - Fix - Fix the NodeType* ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27003/files - new: https://git.openjdk.org/jdk/pull/27003/files/2e7bd8c9..69c65fe1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27003.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003 PR: https://git.openjdk.org/jdk/pull/27003 From jsjolen at openjdk.org Tue Sep 2 11:28:03 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 2 Sep 2025 11:28:03 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v6] In-Reply-To: References: Message-ID: > Hi, > > The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: It's const ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27003/files - new: https://git.openjdk.org/jdk/pull/27003/files/69c65fe1..7deb9a1b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27003.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003 PR: https://git.openjdk.org/jdk/pull/27003 From jsjolen at openjdk.org Tue Sep 2 11:33:21 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 2 Sep 2025 11:33:21 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v7] In-Reply-To: References: Message-ID: > Hi, > > The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Rename ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27003/files - new: https://git.openjdk.org/jdk/pull/27003/files/7deb9a1b..7c3f1a41 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=05-06 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27003.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003 PR: https://git.openjdk.org/jdk/pull/27003 From jsjolen at openjdk.org Tue Sep 2 11:44:01 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 2 Sep 2025 11:44:01 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v8] In-Reply-To: References: Message-ID: > Hi, > > The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision: - Aha, missing include - Wait, the VMATree is wrong? ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27003/files - new: https://git.openjdk.org/jdk/pull/27003/files/7c3f1a41..1cceebf2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=06-07 Stats: 3 lines in 2 files changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27003.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003 PR: https://git.openjdk.org/jdk/pull/27003 From coleenp at openjdk.org Tue Sep 2 11:49:44 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 2 Sep 2025 11:49:44 GMT Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns InstanceKlass* In-Reply-To: References: Message-ID: <8XfA1QxtYcE7-4O3qTGtgktxCYg5HpvZtFWrRR0Rt4I=.7468c92f-edf9-4934-94b6-84a0db503781@github.com> On Tue, 2 Sep 2025 04:59:09 GMT, David Holmes wrote: >> By adding an `InstanceKlass* InstanceKlass::super()` method to shadow `Klass* Klass:super()`, this PR makes it possible to simplify the following code >> >> >> InstanceKlass* ik; >> InstanceKlass* s; >> s = InstanceKlass::cast(ik->super()); // before JDK-8366024 >> s = ik->java_super(); // after JDK-8366024 >> >> >> to >> >> >> s = k->super(); >> >> >> So you no longer need to do casting or need to understand what `java_super()` is. > > src/hotspot/share/oops/instanceKlass.hpp line 924: > >> 922: // always an InstanceKlass (or nullptr) >> 923: InstanceKlass* super() const { >> 924: return (Klass::super() == nullptr) ? nullptr : InstanceKlass::cast(Klass::super()); > > Is it better/simpler/cleaner to just do: > > return static_cast(Klass::super()); > > ? I think the term is "hides" not "shadows". InstanceKlass::cast() is better - one additional check that super is always another InstanceKlass. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27037#discussion_r2315826675 From coleenp at openjdk.org Tue Sep 2 11:49:45 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 2 Sep 2025 11:49:45 GMT Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns InstanceKlass* In-Reply-To: <8XfA1QxtYcE7-4O3qTGtgktxCYg5HpvZtFWrRR0Rt4I=.7468c92f-edf9-4934-94b6-84a0db503781@github.com> References: <8XfA1QxtYcE7-4O3qTGtgktxCYg5HpvZtFWrRR0Rt4I=.7468c92f-edf9-4934-94b6-84a0db503781@github.com> Message-ID: On Tue, 2 Sep 2025 11:43:01 GMT, Coleen Phillimore wrote: >> src/hotspot/share/oops/instanceKlass.hpp line 924: >> >>> 922: // always an InstanceKlass (or nullptr) >>> 923: InstanceKlass* super() const { >>> 924: return (Klass::super() == nullptr) ? nullptr : InstanceKlass::cast(Klass::super()); >> >> Is it better/simpler/cleaner to just do: >> >> return static_cast(Klass::super()); >> >> ? > > I think the term is "hides" not "shadows". InstanceKlass::cast() is better - one additional check that super is always another InstanceKlass. Do we still need java_super ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27037#discussion_r2315827420 From jsjolen at openjdk.org Tue Sep 2 11:54:19 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 2 Sep 2025 11:54:19 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v9] In-Reply-To: References: Message-ID: > Hi, > > The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. Johan Sj?len has updated the pull request incrementally with three additional commits since the last revision: - Yup - Some more ugly casts - Aha, _root is typed as an IntrusiveRBNode ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27003/files - new: https://git.openjdk.org/jdk/pull/27003/files/1cceebf2..04b5a99b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=07-08 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27003.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003 PR: https://git.openjdk.org/jdk/pull/27003 From jsjolen at openjdk.org Tue Sep 2 11:56:43 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 2 Sep 2025 11:56:43 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v8] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 11:44:01 GMT, Johan Sj?len wrote: >> Hi, >> >> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. > > Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision: > > - Aha, missing include > - Wait, the VMATree is wrong? Sorry about the ridiculous amount of commits. For each one I thought "this is the last one". I've created a temp branch that I'll push to so you don't have to see this WIP. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27003#issuecomment-3245001621 From coleenp at openjdk.org Tue Sep 2 12:09:46 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 2 Sep 2025 12:09:46 GMT Subject: RFR: 8277444: Data race between JvmtiClassFileReconstituter::copy_bytecodes and class linking [v4] In-Reply-To: References: Message-ID: <1JIJRz2n7-MCQDwQhqWAMC5o1VQ0gYwLZ1jgkjQH8YU=.c06407bf-e13b-4e35-84f9-ab2f4154f754@github.com> On Fri, 29 Aug 2025 22:48:06 GMT, Evgeny Astigeevich wrote: >> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. >> >> This PR adds linking a class before the `copy_bytecodes` method is called. >> The PR also adds a regression test. >> >> Tested fastdebug and release builds: Linux x86_64 and arm64 >> - The reproducer from JDK-8277444 passed. >> - The regression test passed. >> - Tier1 - tier3 passed. > > Evgeny Astigeevich 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 five additional commits since the last revision: > > - Merge branch 'master' into JDK-8277444 > - Link classes before copy_bytecodes; Add regression test > - Symplify comments; Get JavaThread::current in variable > - Add missing include runtime/synchronizer.hpp > - 8277444: Race condition on Instrumentation.retransformClasses() and class linking I had a couple of minor comments but otherwise looks good. Is the test now reliable? Thank you for adding a test. src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 35: > 33: #include "runtime/handles.inline.hpp" > 34: #include "runtime/signature.hpp" > 35: #include "runtime/synchronizer.hpp" You don't need this include anymore. src/hotspot/share/prims/jvmtiEnv.cpp line 3446: > 3444: current_thread->clear_pending_exception(); > 3445: return JVMTI_ERROR_INVALID_CLASS; > 3446: } Can you use the pattern: JavaThread* THREAD = current_thread; ... link_class(THREAD); if (HAS_PENDING_EXCEPTION) etc. ------------- PR Review: https://git.openjdk.org/jdk/pull/26863#pullrequestreview-3176231981 PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2315873660 PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2315880585 From phubner at openjdk.org Tue Sep 2 13:08:50 2025 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Tue, 2 Sep 2025 13:08:50 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v9] In-Reply-To: References: Message-ID: <1C3jv85vHI3m7JZV-XC8PCwUyvBVzwvbibuETkvGHBQ=.89d69791-8270-4164-82d4-44acee14aa67@github.com> On Tue, 2 Sep 2025 11:54:19 GMT, Johan Sj?len wrote: >> Hi, >> >> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. > > Johan Sj?len has updated the pull request incrementally with three additional commits since the last revision: > > - Yup > - Some more ugly casts > - Aha, _root is typed as an IntrusiveRBNode src/hotspot/share/utilities/rbTree.hpp line 464: > 462: struct node_pair { const RBNode* current; RBNode* other_parent; Dir d; }; > 463: struct stack { > 464: node_pair s[64]; Could you clarify the choice of 64 as an upper bound? It's not immediately obvious to me if we guarantee (or if we don't care about) the maximum visitation size in the code below. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27003#discussion_r2316036406 From jsjolen at openjdk.org Tue Sep 2 13:18:44 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 2 Sep 2025 13:18:44 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v9] In-Reply-To: <1C3jv85vHI3m7JZV-XC8PCwUyvBVzwvbibuETkvGHBQ=.89d69791-8270-4164-82d4-44acee14aa67@github.com> References: <1C3jv85vHI3m7JZV-XC8PCwUyvBVzwvbibuETkvGHBQ=.89d69791-8270-4164-82d4-44acee14aa67@github.com> Message-ID: <0QdMYssbmrxll76glB1s9PS55PFbkULHq-ezpr5b5B4=.2b8d7971-14d5-4cf4-bc5f-41a2aaa89d5d@github.com> On Tue, 2 Sep 2025 13:06:02 GMT, Paul H?bner wrote: >> Johan Sj?len has updated the pull request incrementally with three additional commits since the last revision: >> >> - Yup >> - Some more ugly casts >> - Aha, _root is typed as an IntrusiveRBNode > > src/hotspot/share/utilities/rbTree.hpp line 464: > >> 462: struct node_pair { const RBNode* current; RBNode* other_parent; Dir d; }; >> 463: struct stack { >> 464: node_pair s[64]; > > Could you clarify the choice of 64 as an upper bound? It's not immediately obvious to me if we guarantee (or if we don't care about) the maximum visitation size in the code below. It's an arbitrary depth (it's used in other parts of the RBTree code as well). The maximum length of the stack represents the maximum depth of the tree that we support. A perfectly balanced binary tree of depth 64 has 2**64 - 1 nodes, so in practice this will never be reached. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27003#discussion_r2316065902 From bmaillard at openjdk.org Tue Sep 2 13:30:38 2025 From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard) Date: Tue, 2 Sep 2025 13:30:38 GMT Subject: RFR: 8360389: Support printing from C2 compiled code [v9] In-Reply-To: References: Message-ID: > This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types. > > ## Usage > > Suppose we have this piece of Java code, that simply computes an arithmetic operation, and > that we compile `square` with C2. > > class Square { > static int square(int a) { > return a * a; > } > > public static void main(String[] args) { > square(9); > } > } > > > We would like to inspect the node that contains the value returned in this method. > We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect. > > ```c++ > void Compile::return_values(JVMState* jvms) { > GraphKit kit(jvms); > Node* ret = new ReturnNode(TypeFunc::Parms, > kit.control(), > kit.i_o(), > kit.reset_memory(), > kit.frameptr(), > kit.returnadr()); > // Add zero or 1 return values > int ret_size = tf()->range()->cnt() - TypeFunc::Parms; > > > Node* return_value; > if (ret_size > 0) { > kit.inc_sp(-ret_size); // pop the return value(s) > kit.sync_jvms(); > return_value = kit.argument(0); > ret->add_req(return_value); > > // <-------------------- Simply insert this > C->make_debug_print("return: ", initial_gvn(), return_value); > } > > // bind it to root > root()->add_req(ret); > record_for_igvn(ret); > initial_gvn()->transform(ret); > } > > > We can then call run our code with `-XX:CompileCommand="compileonly,Square::square` > and we get the following output: > > > return: > int 81 > > > This case is of course trivial, but more useful examples are shown later. > > ## Implementation > > The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed. > > The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the `CallLeafNode` constructor. > > The first argument to the runtime printing method is the printing message, a static string encoded as a `... Beno?t Maillard 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 51 additional commits since the last revision: - Automatically insert placeholder nodes for jlong and jdouble - Merge branch 'master' into JDK-8360389 - Fix mismatch with #ifdef COMPILER2 between .hpp and .cpp - Avoid having root as control candidate to prevent issue when printing a constant - Fix missing candidates.size() == 0 case when constants are involved - Replace one more \n by print_cr - Add #ifdef COMPILER2 for runtime methods - Use print_cr instead of \n - Update src/hotspot/share/opto/compile.cpp Co-authored-by: Manuel H?ssig - Update src/hotspot/share/runtime/sharedRuntime.cpp Co-authored-by: Manuel H?ssig - ... and 41 more: https://git.openjdk.org/jdk/compare/fccb79ca...13da04e1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26475/files - new: https://git.openjdk.org/jdk/pull/26475/files/233c89a0..13da04e1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26475&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26475&range=07-08 Stats: 88672 lines in 2189 files changed: 55916 ins; 22598 del; 10158 mod Patch: https://git.openjdk.org/jdk/pull/26475.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26475/head:pull/26475 PR: https://git.openjdk.org/jdk/pull/26475 From jsjolen at openjdk.org Tue Sep 2 13:30:59 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 2 Sep 2025 13:30:59 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v10] In-Reply-To: References: Message-ID: > Hi, > > The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: After a lot of casting ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27003/files - new: https://git.openjdk.org/jdk/pull/27003/files/04b5a99b..76ec83f9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=08-09 Stats: 55 lines in 2 files changed: 42 ins; 1 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/27003.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003 PR: https://git.openjdk.org/jdk/pull/27003 From bmaillard at openjdk.org Tue Sep 2 13:35:43 2025 From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard) Date: Tue, 2 Sep 2025 13:35:43 GMT Subject: RFR: 8360389: Support printing from C2 compiled code [v8] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 14:38:59 GMT, Emanuel Peter wrote: > Ah, I see! Could you verify that somehow in your function, to catch it early? Or is there any way we could drop the need for these place-holders? I have made modifications so that placeholder nodes are automatically inserted for `long` and `int` nodes @eme64. Thanks for the suggestion! > FYI: I have it working now, great! ? The sequence of different prints can be a little messed up, but that's probably due to the controls. Just an observation, but I'm fine with that. Yes, this is due to the controls. As suggested on slack, in the future it would be nice if the user could optionally provide a control to attach the call to instead of using the automatic procedure. This would probably help make it more predictable when needed. > Sadly: it seems that the printing scares the bug away I'm trying to reproduce. This will probably always be an inherent limitation unfortunately. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26475#issuecomment-3245371745 From ayang at openjdk.org Tue Sep 2 13:40:41 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 2 Sep 2025 13:40:41 GMT Subject: RFR: 8365190: Remove LockingMode related code from share In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> Message-ID: On Tue, 2 Sep 2025 08:24:10 GMT, Fredrik Bredberg wrote: > Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR). > > This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself. > > Passes tier1-tier5 with no added problems. Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3176613129 From rcastanedalo at openjdk.org Tue Sep 2 13:48:45 2025 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Tue, 2 Sep 2025 13:48:45 GMT Subject: RFR: 8365190: Remove LockingMode related code from share In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> Message-ID: On Tue, 2 Sep 2025 08:24:10 GMT, Fredrik Bredberg wrote: > Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR). > > This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself. > > Passes tier1-tier5 with no added problems. src/hotspot/share/opto/phaseX.cpp line 1672: > 1670: // Found (linux x64 only?) with: > 1671: // serviceability/sa/ClhsdbThreadContext.java > 1672: // -XX:+UnlockExperimentalVMOptions -XX:LockingMode=1 -XX:+IgnoreUnrecognizedVMOptions -XX:VerifyIterativeGVN=1110 For traceability, I suggest leaving this line untouched and adding a comment in the next line clarifying that `-XX:LockingMode` is not available anymore. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2316150051 From azafari at openjdk.org Tue Sep 2 13:58:10 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 2 Sep 2025 13:58:10 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v10] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 13:30:59 GMT, Johan Sj?len wrote: >> Hi, >> >> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > After a lot of casting src/hotspot/share/nmt/memBaseline.cpp line 175: > 173: VirtualMemoryAllocationSite* site; > 174: bool failed_oom = false; > 175: _vma_allocs_replacement->visit_reserved_regions([&](ReservedMemoryRegion& rgn) { The `_vma_allocs_replacement` is used only locally here. Instead of creating a copy of the VMATree, we can do our loop here within a lock. Can't we? Then we save one tree traverse. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27003#discussion_r2316165798 From jsjolen at openjdk.org Tue Sep 2 13:58:10 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 2 Sep 2025 13:58:10 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v10] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 13:51:47 GMT, Afshin Zafari wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> After a lot of casting > > src/hotspot/share/nmt/memBaseline.cpp line 175: > >> 173: VirtualMemoryAllocationSite* site; >> 174: bool failed_oom = false; >> 175: _vma_allocs_replacement->visit_reserved_regions([&](ReservedMemoryRegion& rgn) { > > The `_vma_allocs_replacement` is used only locally here. Instead of creating a copy of the VMATree, we can do our loop here within a lock. Can't we? > Then we save one tree traverse. It's used here: ```c++ void MemDetailReporter::report_virtual_memory_map() { // Virtual memory map always in base address order output()->print_cr("Virtual memory map:"); _baseline.virtual_memory_allocations()->visit_reserved_regions([&](ReservedMemoryRegion& rgn) { report_virtual_memory_region(&rgn); return true; }); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27003#discussion_r2316171652 From jsjolen at openjdk.org Tue Sep 2 13:58:10 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 2 Sep 2025 13:58:10 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v11] In-Reply-To: References: Message-ID: > Hi, > > The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Rename to _vma_allocations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27003/files - new: https://git.openjdk.org/jdk/pull/27003/files/76ec83f9..ac24b5e2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=09-10 Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/27003.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003 PR: https://git.openjdk.org/jdk/pull/27003 From sjohanss at openjdk.org Tue Sep 2 13:59:37 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Tue, 2 Sep 2025 13:59:37 GMT Subject: RFR: 8366434: THP not working properly with G1 after JDK-8345655 Message-ID: Please review this fix to enable transparent huge pages for G1, **Summary** In [JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655) we refactored the memory reservation code to be more maintainable and easier to follow. When doing this one of the code paths changed to always pass in `os::vm_page_size()` where it previously had used a page size provided by the caller. Even if the alignment for `ReservedSpaces` created this way show that they should be aligned to support large pages the page size member for the `ReservedSpace` does not convey that we want large pages for the space. In G1 when using `G1PageBaseVirtualSpace` we use the above mentioned page size as the alignment for the reservation. This leads to reservations (made using the API) not being THP eligible even if `-XX:+UseTransparentHugePages` is specified. This is only an issue when the system is configured with the THP mode `madvise`. If the mode is `always`, we will get THP eligible reservations. So a fairly simple workaround for this issue (given you have access to configuring your system) is to configure the THP mode to always. The fix is to simply change back to the old behavior and pass in the user provided page size to the `ReservedSpace`. We've also added a test that verifies that we try to back the heap with transparent huge pages when `-XX:+UseTransparentHugePages` is specified on the command-line. **Testing** * Mach5 testing tier1-tier5 * Manual testing of the new test both locally and on mach5. Making sure it has been executed on system with both `madvise` and `always` configured. Also made sure the test actually failed without the fix. ------------- Commit messages: - Typo - StefanK review - Test parsing smaps in process - 8366434: THP not working properly with G1 after JDK-8345655 Changes: https://git.openjdk.org/jdk/pull/27051/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27051&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366434 Stats: 156 lines in 3 files changed: 154 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27051.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27051/head:pull/27051 PR: https://git.openjdk.org/jdk/pull/27051 From asmehra at openjdk.org Tue Sep 2 14:57:52 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 2 Sep 2025 14:57:52 GMT Subject: RFR: 8365501: Remove special AdapterHandlerEntry for abstract methods [v3] In-Reply-To: <3Rdyz0i6XIKqcVC5Rbw1eDU4qZyawLb5JYWws3UARIw=.68cf8962-f5d5-47de-8cc3-d9b18b1453f0@github.com> References: <3Rdyz0i6XIKqcVC5Rbw1eDU4qZyawLb5JYWws3UARIw=.68cf8962-f5d5-47de-8cc3-d9b18b1453f0@github.com> Message-ID: On Mon, 1 Sep 2025 10:28:02 GMT, Andrew Dinn wrote: >> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comment - swap conditions >> >> Signed-off-by: Ashutosh Mehra > > src/hotspot/share/runtime/sharedRuntime.cpp line 2567: > >> 2565: { >> 2566: ResourceMark rm; >> 2567: MutexLocker mu(AdapterHandlerLibrary_lock); > > Why are we ok to drop this lock here? Was it unnecessary even before this change? This lock was required because `AdapterHandlerLibrary::create_abstract_method_handler` expected the lock to be held. Now that method is deleted, we don't need to acquire the lock. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26764#discussion_r2316342459 From asmehra at openjdk.org Tue Sep 2 14:57:53 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 2 Sep 2025 14:57:53 GMT Subject: Integrated: 8365501: Remove special AdapterHandlerEntry for abstract methods In-Reply-To: References: Message-ID: On Wed, 13 Aug 2025 18:45:54 GMT, Ashutosh Mehra wrote: > This PR removes the need for having AdapterHandlerEntry for abstract methods. The check for abstract method is now done in the accessor functions in Method such as Method::get_i2c_entry(). > Motivation for this change is described in the JBS issue. This pull request has now been integrated. Changeset: 444a8fa1 Author: Ashutosh Mehra URL: https://git.openjdk.org/jdk/commit/444a8fa14e8ab016b8aae018054c5dc1eb843fee Stats: 55 lines in 5 files changed: 11 ins; 38 del; 6 mod 8365501: Remove special AdapterHandlerEntry for abstract methods Reviewed-by: kvn, adinn ------------- PR: https://git.openjdk.org/jdk/pull/26764 From asmehra at openjdk.org Tue Sep 2 14:57:51 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 2 Sep 2025 14:57:51 GMT Subject: RFR: 8365501: Remove special AdapterHandlerEntry for abstract methods [v3] In-Reply-To: References: Message-ID: <1JlY7ZTfzvPEBEUK8q28muE1wNnTLALxi90fHzvAnbw=.3bca4f8e-cac4-45b8-937a-1caaa84585ab@github.com> On Fri, 29 Aug 2025 22:29:46 GMT, Vladimir Kozlov wrote: >> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comment - swap conditions >> >> Signed-off-by: Ashutosh Mehra > > @adinn, please review these changes. @vnkozlov @adinn thanks for the review. Integrating it now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26764#issuecomment-3245694023 From jwaters at openjdk.org Tue Sep 2 15:01:56 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 2 Sep 2025 15:01:56 GMT Subject: RFR: 8366699: Replace TestNoNULL with a simpler mechanism to forbid using NULL in HotSpot code Message-ID: TestNoNULL was introduced as a way to forbid using the raw NULL macro in HotSpot code. It works well, but a newer way to achieve the same result by poisoning the macro expansion itself would be more accurate given it could properly use the compiler's lexer and parser to detect NULL being introduced. Normally the way typically envisioned to poison macros by redefining them as an unusable sequence of tokens would be too strong and bleed over into third party code, but there is a way to do so in a controllable fashion. This proposes to implement a simple mechanism to replace TestNoNULL within HotSpot's source code itself, and retire TestNoNULL in favour of this new system. For Visual C++ this is simple, it contains support for using a pragma to poison a macro name, and poisoning a macro causes warnings when it is used. These warnings can be switched off by pragmas whenever we need them to be, making for a perfect disabling system when NULL is used in third party code. For the other 2 big compilers, there exists a similar pragma to disable using a macro, but it is too strong, and unlike Visual C++ is a compile error, meaning there is absolutely no way to turn it off whatsoever. Fortunately there is a simple trick one can leverage: Both compilers have a warning pragma that can be used in this case. All that has to be done is redefining the macro in question to expand into nullptr, but also expand into a pragma that contains this warning message. As for disabling it whenever third party code is around, both compilers conveniently have a push and pop macro pragma that can save and restore macro state, which they implemented for compatibility with Visual C++ and are handy for this purpose. Since redefining Standard header macros is not allowed in C++ we can instead target an implementation detail within the headers: NULL expands to __null, so we can define that as a macro for our purposes instead. Currently using GitHub Actions to test the changes, this is not the final state of the Pull Request. ------------- Commit messages: - Deprecate NULL in compilerWarnings_visCPP.hpp - Define __null in compilerWarnings_gcc.hpp - Delete test/hotspot/jtreg/sources/TestNoNULL.java Changes: https://git.openjdk.org/jdk/pull/27054/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27054&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366699 Stats: 158 lines in 3 files changed: 4 ins; 153 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27054.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27054/head:pull/27054 PR: https://git.openjdk.org/jdk/pull/27054 From shade at openjdk.org Tue Sep 2 15:13:42 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 2 Sep 2025 15:13:42 GMT Subject: RFR: 8366434: THP not working properly with G1 after JDK-8345655 In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 13:53:13 GMT, Stefan Johansson wrote: > Please review this fix to enable transparent huge pages for G1, > > **Summary** > In [JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655) we refactored the memory reservation code to be more maintainable and easier to follow. When doing this one of the code paths changed to always pass in `os::vm_page_size()` where it previously had used a page size provided by the caller. > > Even if the alignment for `ReservedSpaces` created this way show that they should be aligned to support large pages the page size member for the `ReservedSpace` does not convey that we want large pages for the space. In G1 when using `G1PageBaseVirtualSpace` we use the above mentioned page size as the alignment for the reservation. This leads to reservations (made using the API) not being THP eligible even if `-XX:+UseTransparentHugePages` is specified. > > This is only an issue when the system is configured with the THP mode `madvise`. If the mode is `always`, we will get THP eligible reservations. So a fairly simple workaround for this issue (given you have access to configuring your system) is to configure the THP mode to always. > > The fix is to simply change back to the old behavior and pass in the user provided page size to the `ReservedSpace`. We've also added a test that verifies that we try to back the heap with transparent huge pages when `-XX:+UseTransparentHugePages` is specified on the command-line. > > **Testing** > * Mach5 testing tier1-tier5 > * Manual testing of the new test both locally and on mach5. Making sure it has been executed on system with both `madvise` and `always` configured. Also made sure the test actually failed without the fix. test/hotspot/jtreg/gc/TestTransparentHugePagesHeap.java line 105: > 103: > 104: final Pattern heapSection = Pattern.compile("^" + heapAddress + ".*"); > 105: final Pattern thpEligible = Pattern.compile("THPeligible:\\s+(\\d)\\s*"); I thought we had the `smaps` parser somewhere, and here it is: https://github.com/openjdk/jdk/blob/444a8fa14e8ab016b8aae018054c5dc1eb843fee/test/hotspot/jtreg/runtime/os/TestTracePageSizes.java#L149 -- maybe yank it from there to some testlib location, and use it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27051#discussion_r2316393324 From vlivanov at openjdk.org Tue Sep 2 16:00:48 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 2 Sep 2025 16:00:48 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v8] In-Reply-To: References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> Message-ID: On Tue, 26 Aug 2025 22:59:54 GMT, Igor Veresov wrote: >> This change fixes multiple issue with training data verification. While the current state of things in the mainline will not cause any issues (because of the absence of the call to `TD::verify()` during the shutdown) it does problems in the leyden repo. This change strengthens verification in the mainline (by adding the shutdown verify call), and fixes the problems that prevent it from working reliably. > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Relax verification invariant src/hotspot/share/oops/trainingData.cpp line 635: > 633: int init_deps_left2 = compute_init_deps_left(); > 634: > 635: bool invariant = (init_deps_left1 >= init_deps_left2); I assume this check takes concurrent class initialization into account and init notification events are processed on a dedicated thread. Can we strengthen the check by repeatedly performing it and ensuring the value converges? Also, maybe take event queue into account? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2316527758 From iveresov at openjdk.org Tue Sep 2 16:19:44 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 2 Sep 2025 16:19:44 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v8] In-Reply-To: References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> Message-ID: On Tue, 2 Sep 2025 15:57:42 GMT, Vladimir Ivanov wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Relax verification invariant > > src/hotspot/share/oops/trainingData.cpp line 635: > >> 633: int init_deps_left2 = compute_init_deps_left(); >> 634: >> 635: bool invariant = (init_deps_left1 >= init_deps_left2); > > I assume this check takes concurrent class initialization into account and init notification events are processed on a dedicated thread. Can we strengthen the check by repeatedly performing it and ensuring the value converges? Also, maybe take event queue into account? It's very hard to do reliably given the way the vm shutdown currently works. There is no way to ensure that all the java threads are stopped, so checking the convergence is problematic. So, the best I can do right now is prove the `>=` property. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2316575038 From iveresov at openjdk.org Tue Sep 2 16:19:45 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 2 Sep 2025 16:19:45 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v8] In-Reply-To: References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> Message-ID: On Tue, 2 Sep 2025 16:15:42 GMT, Igor Veresov wrote: >> src/hotspot/share/oops/trainingData.cpp line 635: >> >>> 633: int init_deps_left2 = compute_init_deps_left(); >>> 634: >>> 635: bool invariant = (init_deps_left1 >= init_deps_left2); >> >> I assume this check takes concurrent class initialization into account and init notification events are processed on a dedicated thread. Can we strengthen the check by repeatedly performing it and ensuring the value converges? Also, maybe take event queue into account? > > It's very hard to do reliably given the way the vm shutdown currently works. There is no way to ensure that all the java threads are stopped, so checking the convergence is problematic. So, the best I can do right now is prove the `>=` property. I mean, I tired, but gave up on the convergence for now. Perhaps we'd make a stab at it another time. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2316577781 From vlivanov at openjdk.org Tue Sep 2 16:59:43 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 2 Sep 2025 16:59:43 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v8] In-Reply-To: References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> Message-ID: On Tue, 26 Aug 2025 22:59:54 GMT, Igor Veresov wrote: >> This change fixes multiple issue with training data verification. While the current state of things in the mainline will not cause any issues (because of the absence of the call to `TD::verify()` during the shutdown) it does problems in the leyden repo. This change strengthens verification in the mainline (by adding the shutdown verify call), and fixes the problems that prevent it from working reliably. > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Relax verification invariant Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26866#pullrequestreview-3177412360 From vlivanov at openjdk.org Tue Sep 2 16:59:44 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 2 Sep 2025 16:59:44 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v8] In-Reply-To: References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> Message-ID: On Tue, 2 Sep 2025 16:16:41 GMT, Igor Veresov wrote: >> It's very hard to do reliably given the way the vm shutdown currently works. There is no way to ensure that all the java threads are stopped, so checking the convergence is problematic. So, the best I can do right now is prove the `>=` property. > > I mean, I tired, but gave up on the convergence for now. Perhaps we'd make a stab at it another time. Ok, sounds good. Thanks for the clarifications. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26866#discussion_r2316665607 From sjohanss at openjdk.org Tue Sep 2 17:02:45 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Tue, 2 Sep 2025 17:02:45 GMT Subject: RFR: 8366434: THP not working properly with G1 after JDK-8345655 In-Reply-To: References: Message-ID: <2YdaC6jCEz-e3ipYY5XxVDtqSw0c8eoiFo1Z9sEzNIk=.a1ad51ad-dee1-4f50-a15c-81acdcf163bf@github.com> On Tue, 2 Sep 2025 15:10:48 GMT, Aleksey Shipilev wrote: >> Please review this fix to enable transparent huge pages for G1, >> >> **Summary** >> In [JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655) we refactored the memory reservation code to be more maintainable and easier to follow. When doing this one of the code paths changed to always pass in `os::vm_page_size()` where it previously had used a page size provided by the caller. >> >> Even if the alignment for `ReservedSpaces` created this way show that they should be aligned to support large pages the page size member for the `ReservedSpace` does not convey that we want large pages for the space. In G1 when using `G1PageBaseVirtualSpace` we use the above mentioned page size as the alignment for the reservation. This leads to reservations (made using the API) not being THP eligible even if `-XX:+UseTransparentHugePages` is specified. >> >> This is only an issue when the system is configured with the THP mode `madvise`. If the mode is `always`, we will get THP eligible reservations. So a fairly simple workaround for this issue (given you have access to configuring your system) is to configure the THP mode to always. >> >> The fix is to simply change back to the old behavior and pass in the user provided page size to the `ReservedSpace`. We've also added a test that verifies that we try to back the heap with transparent huge pages when `-XX:+UseTransparentHugePages` is specified on the command-line. >> >> **Testing** >> * Mach5 testing tier1-tier5 >> * Manual testing of the new test both locally and on mach5. Making sure it has been executed on system with both `madvise` and `always` configured. Also made sure the test actually failed without the fix. > > test/hotspot/jtreg/gc/TestTransparentHugePagesHeap.java line 105: > >> 103: >> 104: final Pattern heapSection = Pattern.compile("^" + heapAddress + ".*"); >> 105: final Pattern thpEligible = Pattern.compile("THPeligible:\\s+(\\d)\\s*"); > > I thought we had the `smaps` parser somewhere, and here it is: https://github.com/openjdk/jdk/blob/444a8fa14e8ab016b8aae018054c5dc1eb843fee/test/hotspot/jtreg/runtime/os/TestTracePageSizes.java#L149 -- maybe yank it from there to some testlib location, and use it? I agree that this is what we want long-term, we talked about this internally as well. At one point we also just extended the `TestTracePageSizes.java` test to ensure THP for the heap to avoid some duplication. In the end we felt creating a new test was the best approach right now, to also allow for small and safe backport to 25u. Created [JDK-8366716](https://bugs.openjdk.org/browse/JDK-8366716) to keep track of this. Are you good with this approach? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27051#discussion_r2316672407 From shade at openjdk.org Tue Sep 2 17:34:42 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 2 Sep 2025 17:34:42 GMT Subject: RFR: 8366434: THP not working properly with G1 after JDK-8345655 In-Reply-To: <2YdaC6jCEz-e3ipYY5XxVDtqSw0c8eoiFo1Z9sEzNIk=.a1ad51ad-dee1-4f50-a15c-81acdcf163bf@github.com> References: <2YdaC6jCEz-e3ipYY5XxVDtqSw0c8eoiFo1Z9sEzNIk=.a1ad51ad-dee1-4f50-a15c-81acdcf163bf@github.com> Message-ID: On Tue, 2 Sep 2025 16:59:50 GMT, Stefan Johansson wrote: >> test/hotspot/jtreg/gc/TestTransparentHugePagesHeap.java line 105: >> >>> 103: >>> 104: final Pattern heapSection = Pattern.compile("^" + heapAddress + ".*"); >>> 105: final Pattern thpEligible = Pattern.compile("THPeligible:\\s+(\\d)\\s*"); >> >> I thought we had the `smaps` parser somewhere, and here it is: https://github.com/openjdk/jdk/blob/444a8fa14e8ab016b8aae018054c5dc1eb843fee/test/hotspot/jtreg/runtime/os/TestTracePageSizes.java#L149 -- maybe yank it from there to some testlib location, and use it? > > I agree that this is what we want long-term, we talked about this internally as well. At one point we also just extended the `TestTracePageSizes.java` test to ensure THP for the heap to avoid some duplication. In the end we felt creating a new test was the best approach right now, to also allow for small and safe backport to 25u. > > Created [JDK-8366716](https://bugs.openjdk.org/browse/JDK-8366716) to keep track of this. > > Are you good with this approach? Yes, OK. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27051#discussion_r2316739575 From duke at openjdk.org Tue Sep 2 17:38:24 2025 From: duke at openjdk.org (Rui Li) Date: Tue, 2 Sep 2025 17:38:24 GMT Subject: RFR: 8246037: Shenandoah: update man pages to mention -XX:+UseShenandoahGC [v7] In-Reply-To: References: Message-ID: > Add documentation of Shenandoah to java man page > > Aside from `-XX:+UseShenandoahGC`, I picked flags from [shenandoah_globals.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp) that are at product level but not experimental / diagnostic to avoid overwhelming info. Two additional flags match: `ShenandoahGCMode` and `ShenandoahGCHeuristics` Rui Li has updated the pull request incrementally with one additional commit since the last revision: update for threshold wording ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26907/files - new: https://git.openjdk.org/jdk/pull/26907/files/1c8d334a..1c25fbbb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26907&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26907&range=05-06 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26907.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26907/head:pull/26907 PR: https://git.openjdk.org/jdk/pull/26907 From ysr at openjdk.org Tue Sep 2 17:41:44 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Tue, 2 Sep 2025 17:41:44 GMT Subject: RFR: 8246037: Shenandoah: update man pages to mention -XX:+UseShenandoahGC [v7] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 17:38:24 GMT, Rui Li wrote: >> Add documentation of Shenandoah to java man page >> >> Aside from `-XX:+UseShenandoahGC`, I picked flags from [shenandoah_globals.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp) that are at product level but not experimental / diagnostic to avoid overwhelming info. Two additional flags match: `ShenandoahGCMode` and `ShenandoahGCHeuristics` > > Rui Li has updated the pull request incrementally with one additional commit since the last revision: > > update for threshold wording Re-reviewed. ? (Apologies for all the bike-shedding!) ------------- Marked as reviewed by ysr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26907#pullrequestreview-3177542864 From iklam at openjdk.org Tue Sep 2 18:10:43 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 2 Sep 2025 18:10:43 GMT Subject: RFR: 8365407: Race condition in MethodTrainingData::verify() [v8] In-Reply-To: References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> Message-ID: On Tue, 26 Aug 2025 22:59:54 GMT, Igor Veresov wrote: >> This change fixes multiple issue with training data verification. While the current state of things in the mainline will not cause any issues (because of the absence of the call to `TD::verify()` during the shutdown) it does problems in the leyden repo. This change strengthens verification in the mainline (by adding the shutdown verify call), and fixes the problems that prevent it from working reliably. > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Relax verification invariant LGTM ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26866#pullrequestreview-3177620970 From kdnilsen at openjdk.org Tue Sep 2 18:37:42 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Tue, 2 Sep 2025 18:37:42 GMT Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to conc_instruction_and_data_patch In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 00:02:42 GMT, Cesar Soares Lucas wrote: > Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64. > > The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%. Thank you for doing this. Looks good to me. ------------- Marked as reviewed by kdnilsen (Committer). PR Review: https://git.openjdk.org/jdk/pull/26999#pullrequestreview-3177693651 From dlong at openjdk.org Tue Sep 2 19:27:37 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 2 Sep 2025 19:27:37 GMT Subject: RFR: 8366461: Remove obsolete method handle invoke logic Message-ID: 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)). ------------- Commit messages: - Merge branch 'openjdk:master' into 8366461-mh-invoke - first pass Changes: https://git.openjdk.org/jdk/pull/27059/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366461 Stats: 538 lines in 68 files changed: 7 ins; 487 del; 44 mod Patch: https://git.openjdk.org/jdk/pull/27059.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27059/head:pull/27059 PR: https://git.openjdk.org/jdk/pull/27059 From wkemper at openjdk.org Tue Sep 2 19:37:42 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 2 Sep 2025 19:37:42 GMT Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to conc_instruction_and_data_patch In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 00:02:42 GMT, Cesar Soares Lucas wrote: > Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64. > > The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%. LGTM ------------- Marked as reviewed by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26999#pullrequestreview-3177866470 From iklam at openjdk.org Tue Sep 2 19:47:41 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 2 Sep 2025 19:47:41 GMT Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to MetaspaceObj::in_aot_cache() [v2] In-Reply-To: References: Message-ID: <6d7OZxH790nUKN0jvkQ2kQjt_6sCTq336F9BrymQrQI=.bb547056-0167-41a4-b4af-cd4decd2e318@github.com> On Mon, 1 Sep 2025 06:58:15 GMT, David Holmes wrote: > Maybe the JBS title should be a bit more generic as you seem to be renaming many occurrences of "shared" not just the one listed. The majority of the changes are about `is_shared` -> `in_aot_cache`. There are other changes like `_shared_metaspace_static_top` -> `_aot_metaspace_static_top`, but these are just implementation details. This PR is one of the (many) subtasks for the "CDS" -> "AOT" renaming (main issue is [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473)). My plan is to name each subtask to indicate its main purpose. Otherwise it will be difficult to be both precise and concise in the JBS title. - I.e., in this step I renamed some "shared" but left others, so I can't precisely describe that without writing a long essay. - If I used a generic title then it's difficult to tell the difference with other subtasks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27016#issuecomment-3246575519 From dlong at openjdk.org Tue Sep 2 19:55:58 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 2 Sep 2025 19:55:58 GMT Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v2] In-Reply-To: References: Message-ID: > 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: arm32 build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27059/files - new: https://git.openjdk.org/jdk/pull/27059/files/4998cacc..303305ae Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27059.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27059/head:pull/27059 PR: https://git.openjdk.org/jdk/pull/27059 From coleenp at openjdk.org Tue Sep 2 20:35:48 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 2 Sep 2025 20:35:48 GMT Subject: RFR: 8365190: Remove LockingMode related code from share In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> Message-ID: On Tue, 2 Sep 2025 08:24:10 GMT, Fredrik Bredberg wrote: > Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR). > > This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself. > > Passes tier1-tier5 with no added problems. A few comments and suggestions for your next RFE. src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 344: > 342: volatile_nonstatic_field(ObjectMonitor, _entry_list, ObjectWaiter*) \ > 343: volatile_nonstatic_field(ObjectMonitor, _succ, int64_t) \ > 344: volatile_nonstatic_field(ObjectMonitor, _stack_locker, BasicLock*) \ There are some jvmci tests that check that the java side of jvmci matches, ie: make test TEST=compiler/jvmci src/hotspot/share/runtime/basicLock.hpp line 51: > 49: void set_bad_metadata_deopt() { set_metadata(badDispHeaderDeopt); } > 50: > 51: static int displaced_header_offset_in_bytes() { return metadata_offset_in_bytes(); } Also delete line 51 ? src/hotspot/share/runtime/javaThread.cpp line 2007: > 2005: #ifdef SUPPORT_MONITOR_COUNT > 2006: // Nothing to do. Just do some sanity check. > 2007: assert(_held_monitor_count == 0, "counter should not be used"); In further cleanup, can we now remove _held_monitor_count next? src/hotspot/share/runtime/lightweightSynchronizer.cpp line 769: > 767: > 768: // LightweightSynchronizer::inflate_locked_or_imse is used to to get an inflated > 769: // ObjectMonitor* when lightweight locking is used. It is used from contexts I guess you don't need the phrase "when lightweight locking is used". src/hotspot/share/runtime/lightweightSynchronizer.cpp line 823: > 821: ObjectMonitor* LightweightSynchronizer::inflate_into_object_header(oop object, ObjectSynchronizer::InflateCause cause, JavaThread* locking_thread, Thread* current) { > 822: > 823: // The JavaThread* locking_thread parameter is only used by lightweight locking and Same here. suggestion: // The JavaThread* locking parameter requires that the locking_thread == JavaThread::current, or is suspended // throughout the call by some other mechanism. src/hotspot/share/runtime/synchronizer.cpp line 542: > 540: } > 541: ObjectMonitor* monitor; > 542: monitor = LightweightSynchronizer::inflate_locked_or_imse(obj(), inflate_cause_notify, CHECK); Declare and initialize on the same line: ObjectMonitor* monitor = LightwightSynchronizer::inflate_locked_or_imse(obj...); src/hotspot/share/runtime/synchronizer.cpp line 557: > 555: > 556: ObjectMonitor* monitor; > 557: monitor = LightweightSynchronizer::inflate_locked_or_imse(obj(), inflate_cause_notify, CHECK); same here with ObjectMonitor* monitor = LIght ... I think we should have another RFE to look at eliminating the middle call. Call these in LIghtweightSynchronizer::notify, notifyAll and waitInterruptably directly and remove these functions. src/hotspot/share/runtime/synchronizer.inline.hpp line 48: > 46: assert(current == Thread::current(), "must be"); > 47: > 48: LightweightSynchronizer::enter(obj, lock, current); In the further RFE, we should remove these dispatch functions too. ------------- PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3177963667 PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2317054927 PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2317063086 PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2317069783 PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2317072241 PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2317077253 PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2317084869 PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2317088830 PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2317095107 From dlong at openjdk.org Tue Sep 2 20:52:32 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 2 Sep 2025 20:52:32 GMT Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3] In-Reply-To: References: Message-ID: <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com> > 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 three additional commits since the last revision: - revert whitespace change - undo debug changes - cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27059/files - new: https://git.openjdk.org/jdk/pull/27059/files/303305ae..eac482a5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=01-02 Stats: 7 lines in 4 files changed: 1 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27059.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27059/head:pull/27059 PR: https://git.openjdk.org/jdk/pull/27059 From iklam at openjdk.org Tue Sep 2 21:02:36 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 2 Sep 2025 21:02:36 GMT Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns InstanceKlass* [v2] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 04:56:50 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Added assert in heapInspection.cpp > > src/hotspot/share/memory/heapInspection.cpp line 405: > >> 403: bool print_subclasses) { >> 404: // Set do_print for all superclasses of this class. >> 405: InstanceKlass* super = InstanceKlass::cast(cie->klass())->super(); > > Pre-existing, but if this cast is safe then `KlassInfoEntry::_klass` should be declared `InstanceKlass`. Otherwise this cast is not safe! Separate RFE for that. I looked at the `KlassHierarchy` code and it looks at only instance klasses. https://github.com/openjdk/jdk/blob/80fb7088a10136080d23ea93b4840f17d738500c/src/hotspot/share/memory/heapInspection.cpp#L318-L319 I added an assert to make this more apparent. The `KlassInfoEntry` is used by other code that could sometimes store a non-instance klass. I'll leave it as is for now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27037#discussion_r2317161232 From iklam at openjdk.org Tue Sep 2 21:02:37 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 2 Sep 2025 21:02:37 GMT Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns InstanceKlass* [v2] In-Reply-To: References: <8XfA1QxtYcE7-4O3qTGtgktxCYg5HpvZtFWrRR0Rt4I=.7468c92f-edf9-4934-94b6-84a0db503781@github.com> Message-ID: <01xQytgY2qniZkDfORqEoOeJ-PzOgU5-QLg-qumdzic=.99d732bb-9872-480e-9d2b-311069275ba3@github.com> On Tue, 2 Sep 2025 11:43:22 GMT, Coleen Phillimore wrote: >> I think the term is "hides" not "shadows". InstanceKlass::cast() is better - one additional check that super is always another InstanceKlass. > > Do we still need java_super ? There are a few places that use it. Maybe we should look at these again in the future. compiler dependencies: ./share/code/dependencies.cpp: for (InstanceKlass* super = k->java_super(); super != nullptr; super = super->java_super()) { ./share/code/dependencies.cpp: _klass = _klass->java_super(); subklass and sibling: ./share/oops/instanceKlass.cpp: _current = _current->java_super(); // backtrack; no more sibling subclasses left ./share/oops/klass.cpp: InstanceKlass* super = java_super(); ./share/oops/klass.cpp: && (super->java_super() == nullptr || !is_interface())), Some general cases where you have a Klass but wants same super as in java.lang.Class::getSuperClass ./share/oops/klassVtable.cpp: InstanceKlass* super = _klass->java_super(); ./share/prims/jni.cpp: // Rules of Class.getSuperClass as implemented by KLass::java_super: ./share/prims/jni.cpp: Klass* super = k->java_super(); ./share/prims/jni.cpp: "java_super computation depends on interface, array, other super"); ./share/services/heapDumper.cpp: InstanceKlass* java_super = k->java_super(); ./share/services/heapDumper.cpp: assert(java_super != nullptr, "checking"); ./share/services/heapDumper.cpp: writer->write_classID(java_super); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27037#discussion_r2317159260 From iklam at openjdk.org Tue Sep 2 21:02:35 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 2 Sep 2025 21:02:35 GMT Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns InstanceKlass* [v2] In-Reply-To: References: Message-ID: > By adding an `InstanceKlass* InstanceKlass::super()` method to shadow `Klass* Klass:super()`, this PR makes it possible to simplify the following code > > > InstanceKlass* ik; > InstanceKlass* s; > s = InstanceKlass::cast(ik->super()); // before JDK-8366024 > s = ik->java_super(); // after JDK-8366024 > > > to > > > s = k->super(); > > > So you no longer need to do casting or need to understand what `java_super()` is. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Added assert in heapInspection.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27037/files - new: https://git.openjdk.org/jdk/pull/27037/files/54236678..e1bac273 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27037&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27037&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27037.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27037/head:pull/27037 PR: https://git.openjdk.org/jdk/pull/27037 From iklam at openjdk.org Tue Sep 2 21:08:25 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 2 Sep 2025 21:08:25 GMT Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns InstanceKlass* [v3] In-Reply-To: References: Message-ID: > By adding an `InstanceKlass* InstanceKlass::super()` method to shadow `Klass* Klass:super()`, this PR makes it possible to simplify the following code > > > InstanceKlass* ik; > InstanceKlass* s; > s = InstanceKlass::cast(ik->super()); // before JDK-8366024 > s = ik->java_super(); // after JDK-8366024 > > > to > > > s = k->super(); > > > So you no longer need to do casting or need to understand what `java_super()` is. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @dholmes-ora and @coleep comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27037/files - new: https://git.openjdk.org/jdk/pull/27037/files/e1bac273..dd0a3c5a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27037&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27037&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27037.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27037/head:pull/27037 PR: https://git.openjdk.org/jdk/pull/27037 From iklam at openjdk.org Tue Sep 2 21:08:25 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 2 Sep 2025 21:08:25 GMT Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns InstanceKlass* [v3] In-Reply-To: <01xQytgY2qniZkDfORqEoOeJ-PzOgU5-QLg-qumdzic=.99d732bb-9872-480e-9d2b-311069275ba3@github.com> References: <8XfA1QxtYcE7-4O3qTGtgktxCYg5HpvZtFWrRR0Rt4I=.7468c92f-edf9-4934-94b6-84a0db503781@github.com> <01xQytgY2qniZkDfORqEoOeJ-PzOgU5-QLg-qumdzic=.99d732bb-9872-480e-9d2b-311069275ba3@github.com> Message-ID: <7fhuHDv6auOGm7Kj_QANCQ_eUB8ky4NRPAOxa-Gcn-M=.426a74ba-a359-4a6d-a796-aec9000001ff@github.com> On Tue, 2 Sep 2025 20:57:26 GMT, Ioi Lam wrote: >> Do we still need java_super ? > > There are a few places that use it. Maybe we should look at these again in the future. > > > compiler dependencies: > > ./share/code/dependencies.cpp: for (InstanceKlass* super = k->java_super(); super != nullptr; super = super->java_super()) { > ./share/code/dependencies.cpp: _klass = _klass->java_super(); > > subklass and sibling: > > ./share/oops/instanceKlass.cpp: _current = _current->java_super(); // backtrack; no more sibling subclasses left > ./share/oops/klass.cpp: InstanceKlass* super = java_super(); > ./share/oops/klass.cpp: && (super->java_super() == nullptr || !is_interface())), > > Some general cases where you have a Klass but wants same super as in java.lang.Class::getSuperClass > > ./share/oops/klassVtable.cpp: InstanceKlass* super = _klass->java_super(); > ./share/prims/jni.cpp: // Rules of Class.getSuperClass as implemented by KLass::java_super: > ./share/prims/jni.cpp: Klass* super = k->java_super(); > ./share/prims/jni.cpp: "java_super computation depends on interface, array, other super"); > ./share/services/heapDumper.cpp: InstanceKlass* java_super = k->java_super(); > ./share/services/heapDumper.cpp: assert(java_super != nullptr, "checking"); > ./share/services/heapDumper.cpp: writer->write_classID(java_super); I changed to `hides`. There are mentions of both `shadows` and `hides` in our comments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27037#discussion_r2317171136 From iklam at openjdk.org Tue Sep 2 21:08:26 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 2 Sep 2025 21:08:26 GMT Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns InstanceKlass* [v3] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 05:31:30 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @dholmes-ora and @coleep comments > > src/hotspot/share/oops/klassVtable.cpp line 1574: > >> 1572: Klass* super = _klass->super(); >> 1573: if (super != nullptr) { >> 1574: InstanceKlass* sk = InstanceKlass::cast(super); // why are we sure this is InstanceKlass?? > > I don't think it is guaranteed to be an IK. But AFAICS we don't actually need an IK here anyway, we should be able to use `super` directly. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27037#discussion_r2317170011 From vlivanov at openjdk.org Tue Sep 2 21:11:46 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 2 Sep 2025 21:11:46 GMT Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3] In-Reply-To: <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com> References: <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com> Message-ID: On Tue, 2 Sep 2025 20:52:32 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 three additional commits since the last revision: > > - revert whitespace change > - undo debug changes > - cleanup Nice cleanup! Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27059#pullrequestreview-3178139499 From iveresov at openjdk.org Tue Sep 2 21:30:52 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 2 Sep 2025 21:30:52 GMT Subject: Integrated: 8365407: Race condition in MethodTrainingData::verify() In-Reply-To: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> References: <0795hrryFZveQb4GgjNhdGJSYwIz98RHoJx3JX8LSDY=.dae4d10e-5a1f-49da-bec7-e77360f8026e@github.com> Message-ID: On Wed, 20 Aug 2025 18:19:25 GMT, Igor Veresov wrote: > This change fixes multiple issue with training data verification. While the current state of things in the mainline will not cause any issues (because of the absence of the call to `TD::verify()` during the shutdown) it does problems in the leyden repo. This change strengthens verification in the mainline (by adding the shutdown verify call), and fixes the problems that prevent it from working reliably. This pull request has now been integrated. Changeset: 991ac9e6 Author: Igor Veresov URL: https://git.openjdk.org/jdk/commit/991ac9e6168b2573f78772e2d7936792a43fe336 Stats: 90 lines in 6 files changed: 32 ins; 17 del; 41 mod 8365407: Race condition in MethodTrainingData::verify() Reviewed-by: kvn, vlivanov, iklam ------------- PR: https://git.openjdk.org/jdk/pull/26866 From eastigeevich at openjdk.org Tue Sep 2 21:45:03 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Tue, 2 Sep 2025 21:45:03 GMT Subject: RFR: 8277444: Data race between JvmtiClassFileReconstituter::copy_bytecodes and class linking [v5] In-Reply-To: References: Message-ID: > There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. > > This PR adds linking a class before the `copy_bytecodes` method is called. > The PR also adds a regression test. > > Tested fastdebug and release builds: Linux x86_64 and arm64 > - The reproducer from JDK-8277444 passed. > - The regression test passed. > - Tier1 - tier3 passed. Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: Switch to macros HAS_PENDING_EXCEPTION, CLEAR_PENDING_EXCEPTION ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26863/files - new: https://git.openjdk.org/jdk/pull/26863/files/f5019d97..05207c6c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26863&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26863&range=03-04 Stats: 9 lines in 2 files changed: 2 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26863.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26863/head:pull/26863 PR: https://git.openjdk.org/jdk/pull/26863 From eastigeevich at openjdk.org Tue Sep 2 21:45:05 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Tue, 2 Sep 2025 21:45:05 GMT Subject: RFR: 8277444: Data race between JvmtiClassFileReconstituter::copy_bytecodes and class linking [v4] In-Reply-To: <1JIJRz2n7-MCQDwQhqWAMC5o1VQ0gYwLZ1jgkjQH8YU=.c06407bf-e13b-4e35-84f9-ab2f4154f754@github.com> References: <1JIJRz2n7-MCQDwQhqWAMC5o1VQ0gYwLZ1jgkjQH8YU=.c06407bf-e13b-4e35-84f9-ab2f4154f754@github.com> Message-ID: On Tue, 2 Sep 2025 12:04:01 GMT, Coleen Phillimore wrote: >> Evgeny Astigeevich 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 five additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8277444 >> - Link classes before copy_bytecodes; Add regression test >> - Symplify comments; Get JavaThread::current in variable >> - Add missing include runtime/synchronizer.hpp >> - 8277444: Race condition on Instrumentation.retransformClasses() and class linking > > src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 35: > >> 33: #include "runtime/handles.inline.hpp" >> 34: #include "runtime/signature.hpp" >> 35: #include "runtime/synchronizer.hpp" > > You don't need this include anymore. Removed. > src/hotspot/share/prims/jvmtiEnv.cpp line 3446: > >> 3444: current_thread->clear_pending_exception(); >> 3445: return JVMTI_ERROR_INVALID_CLASS; >> 3446: } > > Can you use the pattern: > > > JavaThread* THREAD = current_thread; > ... link_class(THREAD); > if (HAS_PENDING_EXCEPTION) > etc. Switched to macros. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2317234764 PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2317235161 From dlong at openjdk.org Tue Sep 2 22:16:44 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 2 Sep 2025 22:16:44 GMT Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3] 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 incrementally with three additional commits since the last revision: >> >> - revert whitespace change >> - undo debug changes >> - cleanup > > Nice cleanup! Looks good. Thanks @iwanowww ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27059#issuecomment-3246957430 From duke at openjdk.org Tue Sep 2 22:34:44 2025 From: duke at openjdk.org (duke) Date: Tue, 2 Sep 2025 22:34:44 GMT Subject: RFR: 8246037: Shenandoah: update man pages to mention -XX:+UseShenandoahGC [v7] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 17:38:24 GMT, Rui Li wrote: >> Add documentation of Shenandoah to java man page >> >> Aside from `-XX:+UseShenandoahGC`, I picked flags from [shenandoah_globals.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp) that are at product level but not experimental / diagnostic to avoid overwhelming info. Two additional flags match: `ShenandoahGCMode` and `ShenandoahGCHeuristics` > > Rui Li has updated the pull request incrementally with one additional commit since the last revision: > > update for threshold wording @rgithubli Your change (at version 1c25fbbb0cd5f8fc882a11fa5089e9492c80085d) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26907#issuecomment-3247007501 From sviswanathan at openjdk.org Tue Sep 2 22:54:42 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 2 Sep 2025 22:54:42 GMT Subject: RFR: 8363858: [perf] OptimizeFill may use wide set of intrinsics In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 23:56:40 GMT, Vladimir Ivanov wrote: > Default mode should use OptimizeFill=true option for the SRF platform. Looks good to me. ------------- Marked as reviewed by sviswanathan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26974#pullrequestreview-3178386830 From sviswanathan at openjdk.org Tue Sep 2 23:00:43 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 2 Sep 2025 23:00:43 GMT Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays [v4] In-Reply-To: References: Message-ID: On Sat, 30 Aug 2025 16:04:00 GMT, Vladimir Ivanov wrote: >> On the SRF platform for runs with intrinsic scores for the ArrayFill test reports ~2x drop for several sizes due to a lot of the 'MEM_UOPS_RETIRED.SPLIT_STORES' events. The 'good' case for the ArraysFill.testCharFill with size=8195 reports numbers like >> MEM_UOPS_RETIRED.SPLIT_LOADS | 22.6711 >> MEM_UOPS_RETIRED.SPLIT_STORES | 4.0859 >> while for 'bad' case these metrics are >> MEM_UOPS_RETIRED.SPLIT_LOADS | 69.1785 >> MEM_UOPS_RETIRED.SPLIT_STORES | 259200.3659 >> >> With alignment on the cache size no score drops due to split_stores but small reduction may be reported due to extra >> SRF 6740E | Size | orig | pathed | pO/orig >> -- | -- | -- | -- | -- >> ArraysFill.testByteFill | 16 | 152031.2 | 157001.2 | 1.03 >> ArraysFill.testByteFill | 31 | 125795.9 | 177399.2 | 1.41 >> ArraysFill.testByteFill | 250 | 57961.69 | 120981.9 | 2.09 >> ArraysFill.testByteFill | 266 | 44900.15 | 147893.8 | 3.29 >> ArraysFill.testByteFill | 511 | 61908.17 | 129830.1 | 2.10 >> ArraysFill.testByteFill | 2047 | 32255.51 | 41986.6 | 1.30 >> ArraysFill.testByteFill | 2048 | 31928.97 | 42154.3 | 1.32 >> ArraysFill.testByteFill | 8195 | 10690.15 | 11036.3 | 1.03 >> ArraysFill.testIntFill | 16 | 145030.7 | 318796.9 | 2.20 >> ArraysFill.testIntFill | 31 | 134138.4 | 212487 | 1.58 >> ArraysFill.testIntFill | 250 | 74179.23 | 79522.66 | 1.07 >> ArraysFill.testIntFill | 266 | 68112.72 | 60116.49 | 0.88 >> ArraysFill.testIntFill | 511 | 39693.28 | 36225.09 | 0.91 >> ArraysFill.testIntFill | 2047 | 11504.14 | 10616.91 | 0.92 >> ArraysFill.testIntFill | 2048 | 11244.71 | 10969.14 | 0.98 >> ArraysFill.testIntFill | 8195 | 2751.289 | 2692.216 | 0.98 >> ArraysFill.testLongFill | 16 | 212532.5 | 212526 | 1.00 >> ArraysFill.testLongFill | 31 | 137432.4 | 137283.3 | 1.00 >> ArraysFill.testLongFill | 250 | 43185 | 43159.78 | 1.00 >> ArraysFill.testLongFill | 266 | 42172.22 | 42170.5 | 1.00 >> ArraysFill.testLongFill | 511 | 23370.15 | 23370.86 | 1.00 >> ArraysFill.testLongFill | 2047 | 6123.008 | 6122.73 | 1.00 >> ArraysFill.testLongFill | 2048 | 5793.722 | 5792.855 | 1.00 >> ArraysFill.testLongFill | 8195 | 616.552 | 616.585 | 1.00 >> ArraysFill.testShortFill | 16 | 152088.6 | 265646.1 | 1.75 >> ArraysFill.testShortFill | 31 | 137369.8 | 185596.4 | 1.35 >> ArraysFill.testShortFill | 250 | 58872.03 | 99621.15 | 1.69 >> ArraysFill.testShortFill | 266 | 91085.31 | 93746.62 | 1.03 >> ArraysFill.testShortFill | 511 | 65331.96 | 78003.83 | 1.19 >> ArraysFill.testShortFill | 2047 | 21716.32 | 21216.81 | 0.98 >> ArraysFill.testShortFill... > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5931: > 5929: addptr(to, 4); > 5930: subptr(count, 1< 5931: jmpb(L_align_64_bytes); This should be a conditional jump. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26747#discussion_r2317357146 From kbarrett at openjdk.org Tue Sep 2 23:33:17 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 2 Sep 2025 23:33:17 GMT Subject: RFR: 8300080: offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant Message-ID: Please review this change to offset_of to just use offsetof as it's implementation. The rationale for this is (1) Despite being UB for some cases that we use (through C++14), none of the compilers we use actually treat it as such, other than some compilers issuing warnings. (Surprisingly, the UB doesn't appear to disable constexpr evaluation?) (2) C++17 changed it to be conditionally defined in those formerly UB cases, and we'll be switching over to C++17 soon (JDK-8314488). Until we make the switch to C++17 we need to suppress warnings from some compilers for such uses. We can remove that warning suppression later. See the JBS issue for more discussion. Testing: mach5 tier1 ------------- Commit messages: - offset_of just uses offsetof Changes: https://git.openjdk.org/jdk/pull/27061/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27061&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300080 Stats: 26 lines in 4 files changed: 5 ins; 20 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27061.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27061/head:pull/27061 PR: https://git.openjdk.org/jdk/pull/27061 From kbarrett at openjdk.org Tue Sep 2 23:33:17 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 2 Sep 2025 23:33:17 GMT Subject: RFR: 8300080: offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 23:25:43 GMT, Kim Barrett wrote: > Please review this change to offset_of to just use offsetof as it's > implementation. The rationale for this is > > (1) Despite being UB for some cases that we use (through C++14), none of the > compilers we use actually treat it as such, other than some compilers issuing > warnings. (Surprisingly, the UB doesn't appear to disable constexpr evaluation?) > > (2) C++17 changed it to be conditionally defined in those formerly UB cases, > and we'll be switching over to C++17 soon (JDK-8314488). > > Until we make the switch to C++17 we need to suppress warnings from some > compilers for such uses. We can remove that warning suppression later. > > See the JBS issue for more discussion. > > Testing: mach5 tier1 Assuming this gets approved, there should be followup issues to (1) remove the unnecessary warning suppression once we're using C++17, and (2) update uses of offset_of to instead use offsetof directly. I'll file those issues once this gets approved. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27061#issuecomment-3247131522 From duke at openjdk.org Tue Sep 2 23:51:47 2025 From: duke at openjdk.org (Rui Li) Date: Tue, 2 Sep 2025 23:51:47 GMT Subject: Integrated: 8246037: Shenandoah: update man pages to mention -XX:+UseShenandoahGC In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 18:36:04 GMT, Rui Li wrote: > Add documentation of Shenandoah to java man page > > Aside from `-XX:+UseShenandoahGC`, I picked flags from [shenandoah_globals.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp) that are at product level but not experimental / diagnostic to avoid overwhelming info. Two additional flags match: `ShenandoahGCMode` and `ShenandoahGCHeuristics` This pull request has now been integrated. Changeset: 5052a7ee Author: Rui Li Committer: Kelvin Nilsen URL: https://git.openjdk.org/jdk/commit/5052a7eee57e9d145950a0ab1ca71edc02bfe0be Stats: 44 lines in 2 files changed: 42 ins; 0 del; 2 mod 8246037: Shenandoah: update man pages to mention -XX:+UseShenandoahGC Reviewed-by: ysr, wkemper, cslucas ------------- PR: https://git.openjdk.org/jdk/pull/26907 From cslucas at openjdk.org Wed Sep 3 00:23:05 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Wed, 3 Sep 2025 00:23:05 GMT Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to conc_instruction_and_data_patch [v2] In-Reply-To: References: Message-ID: > Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64. > > The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%. Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: Change shenandoah nmethod entry barrier fence for RISC-V (cherry picked from commit 495b07fe690ef7e3fe828fd2be27c4259c739c23) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26999/files - new: https://git.openjdk.org/jdk/pull/26999/files/62da55fb..3276b586 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26999&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26999&range=00-01 Stats: 9 lines in 4 files changed: 0 ins; 7 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26999.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26999/head:pull/26999 PR: https://git.openjdk.org/jdk/pull/26999 From cslucas at openjdk.org Wed Sep 3 00:37:59 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Wed, 3 Sep 2025 00:37:59 GMT Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to conc_instruction_and_data_patch [v3] In-Reply-To: References: Message-ID: > Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64. > > The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%. Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: Make PPC backend to also use concurrent code patching. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26999/files - new: https://git.openjdk.org/jdk/pull/26999/files/3276b586..4da31385 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26999&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26999&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26999.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26999/head:pull/26999 PR: https://git.openjdk.org/jdk/pull/26999 From fyang at openjdk.org Wed Sep 3 01:30:44 2025 From: fyang at openjdk.org (Fei Yang) Date: Wed, 3 Sep 2025 01:30:44 GMT Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to conc_instruction_and_data_patch [v3] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 00:37:59 GMT, Cesar Soares Lucas wrote: >> Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64. >> >> The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%. > > Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: > > Make PPC backend to also use concurrent code patching. I just checked the RISC-V part. LGTM. Thanks. ------------- Marked as reviewed by fyang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26999#pullrequestreview-3178669201 From dzhang at openjdk.org Wed Sep 3 02:15:50 2025 From: dzhang at openjdk.org (Dingli Zhang) Date: Wed, 3 Sep 2025 02:15:50 GMT Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to conc_instruction_and_data_patch [v3] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 00:37:59 GMT, Cesar Soares Lucas wrote: >> Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64. >> >> The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%. > > Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: > > Make PPC backend to also use concurrent code patching. LGTM, thanks! ------------- Marked as reviewed by dzhang (Author). PR Review: https://git.openjdk.org/jdk/pull/26999#pullrequestreview-3178728761 From cslucas at openjdk.org Wed Sep 3 04:29:50 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Wed, 3 Sep 2025 04:29:50 GMT Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to conc_instruction_and_data_patch [v3] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 00:37:59 GMT, Cesar Soares Lucas wrote: >> Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64. >> >> The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%. > > Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: > > Make PPC backend to also use concurrent code patching. @TheRealMDoerr - @shipilev mentioned in private that you have access to PPC machines; could you please help testing this patch on PPC? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26999#issuecomment-3247640930 From dholmes at openjdk.org Wed Sep 3 07:06:46 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 3 Sep 2025 07:06:46 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v4] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: <6Cc8PqkykKjVxXlBOyoEpX_MJgiqbqt93ljPtbDpZ2Y=.26f0f6de-ab9f-4e3d-a80c-7ddfa43aabf2@github.com> On Tue, 2 Sep 2025 11:03:33 GMT, Andrew Dinn wrote: >>> We change mode when we're _all but certain_ that we need to. That seems right to me. If the mode doesn't need changing because it's already set, that's OK. Why do you think this might be a problem? >> >> My concern is that if we have code that needs a specific mode, but it is not obvious at that piece of code that this is the case, then things will work fine if somewhere on the path to that code we set the right mode. But if we introduce a new path to that code that might not be the case and so we will introduce a new place where we switch modes. That can lead to redundancy. The whole thing (as it has from day one) seems ad-hoc. >> >> But if the proposed scheme performs better in general, and is not obviously "worse" from the ad-hoc perspective then ... > > @dholmes-ora I accept that this approach is not fully robust in the face of changes to the code base. However, in mitigation of that risk, the approach of targeting the major gateway calls that precede most subsequent code updates (e.g. creating an assembler instance) means that only a relatively small number of code paths which bypass those known gateways currently are, or will ever be, susceptible to such failure. > > Furthermore, weighed against that risk are 1) a mechanism we can use both to catch failures during testing and to avoid any danger when something escapes into production and 2) a significant gain in performance from avoiding (literally) millions of unnecessary transitions. > > I don't normally support pushing changes which are inherently fragile in the face of code updates. However, in this case I think the mechanisms in place to mitigate the risk and limit any damage and the performance gains to be had make it worth adopting. @adinn and @theRealAph in case it was not clear I am okay with this proceeding. I will leave the actual approvals to others who know the specific code locations better. Thanks for the discussion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26562#issuecomment-3247952549 From mhaessig at openjdk.org Wed Sep 3 07:17:44 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Wed, 3 Sep 2025 07:17:44 GMT Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3] In-Reply-To: <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com> References: <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com> Message-ID: On Tue, 2 Sep 2025 20:52:32 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 three additional commits since the last revision: > > - revert whitespace change > - undo debug changes > - cleanup Thank you for cleaning this up, @dean-long. I just have a drive-by comment. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64Frame.java line 372: > 370: // DEBUG_ONLY(verifyDeoptriginalPc(senderNm, raw_unextendedSp)); > 371: } > 372: } `Frame.java adjustUnextendedSP()` do not seem to do anything? Perhaps these could be cleaned up as well? ------------- PR Review: https://git.openjdk.org/jdk/pull/27059#pullrequestreview-3179245014 PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2317990499 From stefank at openjdk.org Wed Sep 3 07:18:48 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 3 Sep 2025 07:18:48 GMT Subject: RFR: 8366434: THP not working properly with G1 after JDK-8345655 In-Reply-To: References: Message-ID: <1z_yWIewPSSx_9qgtQCJM2L7iSXl-dKVYG7MWfsdDes=.034424cf-514f-4c79-96ec-418dc5fefe26@github.com> On Tue, 2 Sep 2025 13:53:13 GMT, Stefan Johansson wrote: > Please review this fix to enable transparent huge pages for G1, > > **Summary** > In [JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655) we refactored the memory reservation code to be more maintainable and easier to follow. When doing this one of the code paths changed to always pass in `os::vm_page_size()` where it previously had used a page size provided by the caller. > > Even if the alignment for `ReservedSpaces` created this way show that they should be aligned to support large pages the page size member for the `ReservedSpace` does not convey that we want large pages for the space. In G1 when using `G1PageBaseVirtualSpace` we use the above mentioned page size as the alignment for the reservation. This leads to reservations (made using the API) not being THP eligible even if `-XX:+UseTransparentHugePages` is specified. > > This is only an issue when the system is configured with the THP mode `madvise`. If the mode is `always`, we will get THP eligible reservations. So a fairly simple workaround for this issue (given you have access to configuring your system) is to configure the THP mode to always. > > The fix is to simply change back to the old behavior and pass in the user provided page size to the `ReservedSpace`. We've also added a test that verifies that we try to back the heap with transparent huge pages when `-XX:+UseTransparentHugePages` is specified on the command-line. > > **Testing** > * Mach5 testing tier1-tier5 > * Manual testing of the new test both locally and on mach5. Making sure it has been executed on system with both `madvise` and `always` configured. Also made sure the test actually failed without the fix. Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27051#pullrequestreview-3179254656 From stefank at openjdk.org Wed Sep 3 07:31:44 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 3 Sep 2025 07:31:44 GMT Subject: RFR: 8300080: offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant In-Reply-To: References: Message-ID: <0T5Bpw4E7qu10pWz981nWwFgNet_sas0vPi4K5v70LU=.17e8d99a-3663-47ef-874b-1349bd919229@github.com> On Tue, 2 Sep 2025 23:25:43 GMT, Kim Barrett wrote: > Please review this change to offset_of to just use offsetof as it's > implementation. The rationale for this is > > (1) Despite being UB for some cases that we use (through C++14), none of the > compilers we use actually treat it as such, other than some compilers issuing > warnings. (Surprisingly, the UB doesn't appear to disable constexpr evaluation?) > > (2) C++17 changed it to be conditionally defined in those formerly UB cases, > and we'll be switching over to C++17 soon (JDK-8314488). > > Until we make the switch to C++17 we need to suppress warnings from some > compilers for such uses. We can remove that warning suppression later. > > See the JBS issue for more discussion. > > Testing: mach5 tier1 Nice. Is it worth pushing this so near the transition to compile with C++17 support? ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27061#pullrequestreview-3179298085 From jwaters at openjdk.org Wed Sep 3 08:23:55 2025 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 3 Sep 2025 08:23:55 GMT Subject: Withdrawn: 8366699: Replace TestNoNULL with a simpler mechanism to forbid using NULL in HotSpot code In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 14:46:09 GMT, Julian Waters wrote: > TestNoNULL was introduced as a way to forbid using the raw NULL macro in HotSpot code. It works well, but a newer way to achieve the same result by poisoning the macro expansion itself would be more accurate given it could properly use the compiler's lexer and parser to detect NULL being introduced. Normally the way typically envisioned to poison macros by redefining them as an unusable sequence of tokens would be too strong and bleed over into third party code, but there is a way to do so in a controllable fashion. This proposes to implement a simple mechanism to replace TestNoNULL within HotSpot's source code itself, and retire TestNoNULL in favour of this new system. > > For Visual C++ this is simple, it contains support for using a pragma to poison a macro name, and poisoning a macro causes warnings when it is used. These warnings can be switched off by pragmas whenever we need them to be, making for a perfect disabling system when NULL is used in third party code. > > For the other 2 big compilers, there exists a similar pragma to disable using a macro, but it is too strong, and unlike Visual C++ is a compile error, meaning there is absolutely no way to turn it off whatsoever. Fortunately there is a simple trick one can leverage: Both compilers have a warning pragma that can be used in this case. All that has to be done is redefining the macro in question to expand into nullptr, but also expand into a pragma that contains this warning message. As for disabling it whenever third party code is around, both compilers conveniently have a push and pop macro pragma that can save and restore macro state, which they implemented for compatibility with Visual C++ and are handy for this purpose. Since redefining Standard header macros is not allowed in C++ we can instead target an implementation detail within the headers: NULL expands to __null, so we can define that as a macro for our purposes instead. > > Currently using GitHub Actions to test the changes, this is not the final state of the Pull Request. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27054 From shade at openjdk.org Wed Sep 3 08:54:43 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 3 Sep 2025 08:54:43 GMT Subject: RFR: 8366434: THP not working properly with G1 after JDK-8345655 In-Reply-To: References: Message-ID: <7omR7oA7xV-EybyZzMUBm1KismDS8zcmAiUz14WQK6g=.b822cecd-f75b-449f-b0ee-4051dd12b504@github.com> On Tue, 2 Sep 2025 13:53:13 GMT, Stefan Johansson wrote: > Please review this fix to enable transparent huge pages for G1, > > **Summary** > In [JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655) we refactored the memory reservation code to be more maintainable and easier to follow. When doing this one of the code paths changed to always pass in `os::vm_page_size()` where it previously had used a page size provided by the caller. > > Even if the alignment for `ReservedSpaces` created this way show that they should be aligned to support large pages the page size member for the `ReservedSpace` does not convey that we want large pages for the space. In G1 when using `G1PageBaseVirtualSpace` we use the above mentioned page size as the alignment for the reservation. This leads to reservations (made using the API) not being THP eligible even if `-XX:+UseTransparentHugePages` is specified. > > This is only an issue when the system is configured with the THP mode `madvise`. If the mode is `always`, we will get THP eligible reservations. So a fairly simple workaround for this issue (given you have access to configuring your system) is to configure the THP mode to always. > > The fix is to simply change back to the old behavior and pass in the user provided page size to the `ReservedSpace`. We've also added a test that verifies that we try to back the heap with transparent huge pages when `-XX:+UseTransparentHugePages` is specified on the command-line. > > **Testing** > * Mach5 testing tier1-tier5 > * Manual testing of the new test both locally and on mach5. Making sure it has been executed on system with both `madvise` and `always` configured. Also made sure the test actually failed without the fix. Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27051#pullrequestreview-3179634396 From jsjolen at openjdk.org Wed Sep 3 09:12:44 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 3 Sep 2025 09:12:44 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v12] In-Reply-To: References: Message-ID: > Hi, > > The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Merge remote-tracking branch 'openjdk/master' into cleanup-membaseline - Rename to _vma_allocations - After a lot of casting - Yup - Some more ugly casts - Aha, _root is typed as an IntrusiveRBNode - Aha, missing include - Wait, the VMATree is wrong? - Rename - It's const - ... and 6 more: https://git.openjdk.org/jdk/compare/6dda2f6f...82df750b ------------- Changes: https://git.openjdk.org/jdk/pull/27003/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=11 Stats: 226 lines in 11 files changed: 161 ins; 44 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/27003.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003 PR: https://git.openjdk.org/jdk/pull/27003 From jsjolen at openjdk.org Wed Sep 3 09:18:51 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 3 Sep 2025 09:18:51 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v12] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 09:12:44 GMT, Johan Sj?len wrote: >> Hi, >> >> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. > > Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge remote-tracking branch 'openjdk/master' into cleanup-membaseline > - Rename to _vma_allocations > - After a lot of casting > - Yup > - Some more ugly casts > - Aha, _root is typed as an IntrusiveRBNode > - Aha, missing include > - Wait, the VMATree is wrong? > - Rename > - It's const > - ... and 6 more: https://git.openjdk.org/jdk/compare/6dda2f6f...82df750b GHA is a bit borked. >Error: Failed to resolve action download info. Error: Failed to resolve action download info. I re-ran the failed tests of the previous GHA run on my local instance and those tests did not fail. Not sure if it was a fluke, or if we have an actual issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27003#issuecomment-3248401792 From duke at openjdk.org Wed Sep 3 09:42:17 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Wed, 3 Sep 2025 09:42:17 GMT Subject: RFR: 8366778: Sort share/asm, share/gc, share/include includes Message-ID: Sort includes in `share/gc`, `share/asm`, `share/include` using `SortIncludes.java`, and remove some unnecessary ones. These are the last missing modules in `hotspot/share`. Passes `tier1`. ------------- Commit messages: - sort Changes: https://git.openjdk.org/jdk/pull/27067/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27067&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366778 Stats: 40 lines in 15 files changed: 6 ins; 33 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27067.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27067/head:pull/27067 PR: https://git.openjdk.org/jdk/pull/27067 From aboldtch at openjdk.org Wed Sep 3 09:51:45 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 3 Sep 2025 09:51:45 GMT Subject: RFR: 8365190: Remove LockingMode related code from share In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> Message-ID: <0CMB0g0_Ru1hF5l2NA194kD1ouNwMXrB1667Uvl9mFQ=.b6834c47-be53-41bb-b726-2e282517d6bc@github.com> On Tue, 2 Sep 2025 08:24:10 GMT, Fredrik Bredberg wrote: > Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR). > > This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself. > > Passes tier1-tier5 with no added problems. Nothing obvious seems to be missing from the removal. And the changes look correct. As @coleenp already mentioned there is even more code now that is effectively unused. Mostly to do with legacy + loom interactions. But I think it is fine to remove that in a follow up RFE. Similarly there are some nomenclature that should be updated, but I know you have expressed wanting to do that in a follow up RFE as well. I think it the main refactoring that are left are cleaning up the Synchronizer APIs, unifying some functions etc. _As for unifying LightweightSynchronizer with the ObjectSynchronizer, there might be an opportunity to let ObjectSynchronizer define the general API used by the rest of the VM to interact with the locking subsystem. And let LightweightSynchronizer contain all of the implementation. This could including moving the locking specific implementation details of relocking, deopting etc. behind an interface, decoupling them, and avoiding leaking implementation._ src/hotspot/share/runtime/basicLock.hpp line 51: > 49: void set_bad_metadata_deopt() { set_metadata(badDispHeaderDeopt); } > 50: > 51: static int displaced_header_offset_in_bytes() { return metadata_offset_in_bytes(); } The `badDispHeaderDeopt` and `badDispHeaderOSR` constants should also be renamed. src/hotspot/share/runtime/synchronizer.cpp line 634: > 632: } > 633: > 634: static intptr_t install_hash_code(Thread* current, oop obj) { A future RFE could potentially simplify and unify this with `FastHashCode` ------------- Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3179315618 PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2318059361 PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2318041555 From shade at openjdk.org Wed Sep 3 10:10:42 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 3 Sep 2025 10:10:42 GMT Subject: RFR: 8366778: Sort share/asm, share/gc, share/include includes In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 09:35:24 GMT, Francesco Andreuzzi wrote: > These are the last missing modules in hotspot/share. ? . Onto `cpu/`, `os/` and `os_cpu/`, I guess? ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27067#pullrequestreview-3179930639 From duke at openjdk.org Wed Sep 3 10:13:44 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Wed, 3 Sep 2025 10:13:44 GMT Subject: RFR: 8366778: Sort share/asm, share/gc, share/include includes In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 10:08:27 GMT, Aleksey Shipilev wrote: > > These are the last missing modules in hotspot/share. > > ? . Onto `cpu/`, `os/` and `os_cpu/`, I guess? ?? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27067#issuecomment-3248602850 From qpzhang at openjdk.org Wed Sep 3 10:15:46 2025 From: qpzhang at openjdk.org (Patrick Zhang) Date: Wed, 3 Sep 2025 10:15:46 GMT Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when UseBlockZeroing is false [v3] In-Reply-To: References: Message-ID: > In AArch64 port, `UseBlockZeroing` is by default set to true and `BlockZeroingLowLimit` is initialized to 256. If `DC ZVA` is supported, `BlockZeroingLowLimit` is later updated to `4 * VM_Version::zva_length()`. When `UseBlockZeroing` is set to false, all related conditional checks should ignore `BlockZeroingLowLimit`. However, the function `MacroAssembler::zero_words(Register base, uint64_t cnt)` still evaluates the lower limit and bases its code generation logic on it, which appears to be an incomplete conditional check. > > This PR, > 1. In `MacroAssembler::zero_words(Register base, uint64_t cnt)`, added the checking of `UseBlockZeroing` to the if-cond `cnt > (uint64_t)BlockZeroingLowLimit / BytesPerWord`, strengthened the condition. > 2. In `MacroAssembler::zero_words(Register ptr, Register cnt)`, check `UseBlockZeroing` before checking the conditions of calling the stub function `zero_blocks`, which wraps the `DC ZVA` related instructions and works as the inner part of `zero_words`. Refined code and comments. > 3. For `generate_zero_blocks()`, removed the `UseBlockZeroing` checking and added an assertion, moved unrolled `STP` code-gen out to the caller side > 4. Added a warning message for if UseBlockZeroing is false and BlockZeroingLowLimit gets manually configured. > 5. Added more testing sizes to test/micro/org/openjdk/bench/vm/gc/RawAllocationRate.java > > These changes improved the if-conds in `zero_words` functions around `BlockZeroingLowLimit`, ignore it if `UseBlockZeroing` is false. Performance tests are done on the bundled JMH `vm.compiler.ClearMemory`, and `vm.gc.RawAllocationRate` including `arrayTest` and `instanceTest`. > > Tests include, > 1. The wall time of `zero_words_reg_imm` got significantly improved under a particularly designed test case: `-XX:-UseBlockZeroing -XX:BlockZeroingLowLimit=8`, `size=32` (`arrayTest` and `instanceTest`), the average wall time per call dropped from 309 ns (baseline) to 65 ns (patched), about -80%. The average call count also decreased from 335 to 202, in a 30s run. For example, `jdk/bin/java -jar images/test/micro/benchmarks.jar RawAllocationRate.arrayTest_C1 -bm thrpt -gc false -wi 0 -w 30 -i 1 -r 30 -t 1 -f 1 -tu s -jvmArgs "-XX:-UseBlockZeroing -XX:BlockZeroingLowLimit=8" -p size=32`. > 2. `JMH RawAllocationRate` shows no obvious regression results. In details, patched vs baseline shows average ~70% positive impact, but ratios are minor around +0.5%, since the generated instruction sequences got almost same as baseline, ... Patrick Zhang has updated the pull request incrementally with one additional commit since the last revision: Reset BlockZeroingLowLimit to 4 * _zva_length Signed-off-by: Patrick Zhang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26917/files - new: https://git.openjdk.org/jdk/pull/26917/files/14c18f7f..22e72f49 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26917&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26917&range=01-02 Stats: 8 lines in 2 files changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26917.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26917/head:pull/26917 PR: https://git.openjdk.org/jdk/pull/26917 From ayang at openjdk.org Wed Sep 3 10:16:44 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 3 Sep 2025 10:16:44 GMT Subject: RFR: 8366778: Sort share/asm, share/gc, share/include includes In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 09:35:24 GMT, Francesco Andreuzzi wrote: > Sort includes in `share/gc`, `share/asm`, `share/include` using `SortIncludes.java`, and remove some unnecessary ones. These are the last missing modules in `hotspot/share`. > > Passes `tier1`. Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27067#pullrequestreview-3179952589 From qpzhang at openjdk.org Wed Sep 3 10:30:42 2025 From: qpzhang at openjdk.org (Patrick Zhang) Date: Wed, 3 Sep 2025 10:30:42 GMT Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when UseBlockZeroing is false [v2] In-Reply-To: References: <79QlFmmh7CAbxtU89RNVbf8sRBE_u8TbDLA90FqWyEM=.4e8b48ac-21b5-4881-9ca0-29bc87bfe032@github.com> Message-ID: On Mon, 1 Sep 2025 10:11:49 GMT, Andrew Haley wrote: > To begin with, please add this short patch, then see if any of this PR provides an advantage. > > ``` > > diff --git a/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp b/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp > index 9321dd0542e..14a584c5106 100644 > --- a/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp > +++ b/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp > @@ -446,6 +446,11 @@ void VM_Version::initialize() { > FLAG_SET_DEFAULT(UseBlockZeroing, false); > } > > + if (!UseBlockZeroing && !FLAG_IS_DEFAULT(BlockZeroingLowLimit)) { > + warning("BlockZeroingLowLimit has been ignored because UseBlockZeroing is disabled"); > + FLAG_SET_DEFAULT(BlockZeroingLowLimit, 4 * VM_Version::zva_length()); > + } > + > if (VM_Version::supports_sve2()) { > if (FLAG_IS_DEFAULT(UseSVE)) { > FLAG_SET_DEFAULT(UseSVE, 2); > ``` Thanks for advice. Updated accordingly (commit 3 vs 2: https://github.com/openjdk/jdk/pull/26917/commits/22e72f49e82cc7febbcd44b01636f8cbdeaa4cca) to keep the shape of the generated code as unchanged as possible. My test case with `-XX:-UseBlockZeroing -XX:BlockZeroingLowLimit=8, size=32` also works as expected. I added some comments to better clarify the purpose of the if-condition inside the `zero_words` function to avoid future confusion upon. Please help review, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26917#issuecomment-3248661050 From mli at openjdk.org Wed Sep 3 10:56:44 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 3 Sep 2025 10:56:44 GMT Subject: RFR: 8360000: RISC-V: implement aot [v5] In-Reply-To: References: <89lrKCDzl1QDpDGEMkE6WsdE9P7O4F6RrqEU02lZ9ZA=.c354663f-0cc0-472e-87ab-4954812c1384@github.com> Message-ID: <4iev5X4kwt8w8pis8dXsv2CcEYYH8_ZP5ajorpnT8Es=.2d2585ec-4701-41a5-9e62-c5a7d84b905f@github.com> On Mon, 14 Jul 2025 11:46:22 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> >> https://openjdk.org/jeps/483 introduced aot (class loading/linking) and subsequent prs introduced more features related to it, like preserve adapters(c2i/i2c) and runtime blobs in AOT code cache. >> >> Riscv should support these features and resolve relative issues. >> >> ## Test >> >> ### jtreg >> >> run tier1/2/3 and hotspot_cds tests, no new failure found compared to master jdk. >> >> ### Performance >> >> perf command to run the simplest Hello world java program: >> * (perf stat -r 100 ${JAVA_HOME}/bin/java -XX:AOTCache=$AOT_CACHE -cp $CLASS_PATH Hello > /dev/null) 2>&1 | grep elapsed >> >> perf data: >> * (with patch): 0.181730 +- 0.000296 seconds time elapsed ( +- 0.16% ) >> * (without patch): 0.196627 +- 0.000227 seconds time elapsed ( +- 0.12% ) >> >> Thanks > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > minor Latest patch based on leyden/premain works well, I'll wait for https://github.com/openjdk/jdk/pull/23573, https://github.com/openjdk/jdk/pull/26944 pushed in. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26101#issuecomment-3248740399 From jsikstro at openjdk.org Wed Sep 3 11:11:48 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 3 Sep 2025 11:11:48 GMT Subject: RFR: 8366778: Sort share/asm, share/gc, share/include includes In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 09:35:24 GMT, Francesco Andreuzzi wrote: > Sort includes in `share/gc`, `share/asm`, `share/include` using `SortIncludes.java`, and remove some unnecessary ones. These are the last missing modules in `hotspot/share`. > > Passes `tier1`. Marked as reviewed by jsikstro (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27067#pullrequestreview-3180144068 From coleenp at openjdk.org Wed Sep 3 11:36:46 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 3 Sep 2025 11:36:46 GMT Subject: RFR: 8277444: Data race between JvmtiClassFileReconstituter::copy_bytecodes and class linking [v5] In-Reply-To: References: Message-ID: <8gZJSnHgfc8RwLlaObVBXJ7ubs9mI1MDq3ZL8ZbuQ9Q=.1f08be90-5896-4620-aed7-f7f81958beae@github.com> On Tue, 2 Sep 2025 21:45:03 GMT, Evgeny Astigeevich wrote: >> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. >> >> This PR adds linking a class before the `copy_bytecodes` method is called. >> The PR also adds a regression test. >> >> Tested fastdebug and release builds: Linux x86_64 and arm64 >> - The reproducer from JDK-8277444 passed. >> - The regression test passed. >> - Tier1 - tier3 passed. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Switch to macros HAS_PENDING_EXCEPTION, CLEAR_PENDING_EXCEPTION This looks good now. Thank you for your patience while we found the right solution. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26863#pullrequestreview-3180219072 From coleenp at openjdk.org Wed Sep 3 11:41:44 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 3 Sep 2025 11:41:44 GMT Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns InstanceKlass* [v3] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 21:08:25 GMT, Ioi Lam wrote: >> By adding an `InstanceKlass* InstanceKlass::super()` method to shadow `Klass* Klass:super()`, this PR makes it possible to simplify the following code >> >> >> InstanceKlass* ik; >> InstanceKlass* s; >> s = InstanceKlass::cast(ik->super()); // before JDK-8366024 >> s = ik->java_super(); // after JDK-8366024 >> >> >> to >> >> >> s = k->super(); >> >> >> So you no longer need to do casting or need to understand what `java_super()` is. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @dholmes-ora and @coleep comments Looks good. This will help with InstanceKlass casting. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27037#pullrequestreview-3180231376 From jsjolen at openjdk.org Wed Sep 3 12:20:41 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 3 Sep 2025 12:20:41 GMT Subject: RFR: 8300080: offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 23:25:43 GMT, Kim Barrett wrote: > Please review this change to offset_of to just use offsetof as it's > implementation. The rationale for this is > > (1) Despite being UB for some cases that we use (through C++14), none of the > compilers we use actually treat it as such, other than some compilers issuing > warnings. (Surprisingly, the UB doesn't appear to disable constexpr evaluation?) > > (2) C++17 changed it to be conditionally defined in those formerly UB cases, > and we'll be switching over to C++17 soon (JDK-8314488). > > Until we make the switch to C++17 we need to suppress warnings from some > compilers for such uses. We can remove that warning suppression later. > > See the JBS issue for more discussion. > > Testing: mach5 tier1 Seems good to me. As Stefan hints at, maybe it's worth waiting until C++17 integration and then simplify the PR to only change the macro? ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27061#pullrequestreview-3180362344 From jsjolen at openjdk.org Wed Sep 3 12:21:46 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 3 Sep 2025 12:21:46 GMT Subject: RFR: 8366238: Improve RBTree API with stricter comparator semantics and pluggable validation/printing hooks. [v4] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 13:40:28 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> The current red-black tree can be made safer, and its inspection capabilities improved. >> >> As briefly discussed in #26904, `COMPARATOR::cmp` could be made clearer and more robust. In particular, its `int` return type invites unsafe `return a ? b` arithmetic, and the boolean validation function also named `cmp` is misleading. >> >> To address this, I?ve introduced the `RBTreeOrdering` enum, inspired by C++20?s `<=>`, which makes incorrect arithmetic impossible. The return type of `COMPARATOR::cmp` is now this enum, forcing users to write an explicit and safe comparison. From the discussion in that PR, I have also renamed the boolean `cmp` to `less`, making its purpose obvious and preventing confusion between the two functions. >> >> Inspection has also been improved, especially for intrusive trees. Previously, `verify_self` only verified core RB-tree properties, yet intrusive nodes often hold additional data with their own separate invariants. Users had to perform those checks in a second traversal, and if an error occurs `print_on` produced little diagnostic value by only printing node addresses. >> >> To solve this, the tree now accepts user-supplied verification and printing callables. This lets users validate their custom node data during the same walk and print richer information when errors occur. >> >> Everything is implemented via template parameters with set defaults, so existing code remains unchanged while new code can opt in to the expanded functionality. >> >> Testing: >> - Oracle tiers 1-3 > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > johan feedback Marked as reviewed by jsjolen (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26981#pullrequestreview-3180371207 From jsjolen at openjdk.org Wed Sep 3 12:23:42 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 3 Sep 2025 12:23:42 GMT Subject: RFR: 8366057: HotSpot Style Guide should permit trailing return types In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 10:07:00 GMT, Kim Barrett wrote: > Please review this change to the HotSpot Style Guide to permit trailing return > types for functions. > > This is a modification of the Style Guide, so rough consensus among the > HotSpot Group members is required to make this change. Only Group members > should vote for approval (via the github PR), though reasoned objections or > comments from anyone will be considered. A decision on this proposal will not > be made before Monday 8-September-2025 at 12h00 UTC. > > Since we're piggybacking on github PRs here, please use the PR review process > to approve (click on Review Changes > Approve), rather than sending a "vote: > yes" email reply that would be normal for a CFV. Marked as reviewed by jsjolen (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26923#pullrequestreview-3180377406 From stuefe at openjdk.org Wed Sep 3 14:02:46 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 3 Sep 2025 14:02:46 GMT Subject: RFR: 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown [v2] In-Reply-To: References: <3TJnBvDoAPUf4p2e8Y0vpckfm3v8e31cKKwfOeyRnnM=.34c016f4-419d-4dd6-9102-b112a7423f7b@github.com> Message-ID: <9MccMrhJLB1DC6NP_9aYvnC9EhwqW_iko5Cxdbfxn_k=.4e1db66e-3ffb-4162-a3de-d17169212159@github.com> On Fri, 29 Aug 2025 01:02:43 GMT, David Holmes wrote: >> `ostream_exit` was deleting the stream underlying the `xtty` prior to nulling the `xtty` global variable, resulting in a use-after-free-error. Due to races during VM shutdown we cannot make use of `xtty` perfectly safe, but we can certainly narrow the window during which use-after-free is possible. >> >> Testing: >> - tiers 1-3 sanity >> >> Thanks > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into 8364735-xtty > - 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown I still am not sure how the OrderAccess helps. A concurrent thread can see xtty != null and start printing while the terminating thread deletes the defaultStream under xtty? Sorry if I am slow. ------------- PR Review: https://git.openjdk.org/jdk/pull/26832#pullrequestreview-3180819270 From vaivanov at openjdk.org Wed Sep 3 15:46:44 2025 From: vaivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 3 Sep 2025 15:46:44 GMT Subject: RFR: 8363858: [perf] OptimizeFill may use wide set of intrinsics In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 23:56:40 GMT, Vladimir Ivanov wrote: > Default mode should use OptimizeFill=true option for the SRF platform. Thanks for your review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26974#issuecomment-3249784805 From duke at openjdk.org Wed Sep 3 15:46:44 2025 From: duke at openjdk.org (duke) Date: Wed, 3 Sep 2025 15:46:44 GMT Subject: RFR: 8363858: [perf] OptimizeFill may use wide set of intrinsics In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 23:56:40 GMT, Vladimir Ivanov wrote: > Default mode should use OptimizeFill=true option for the SRF platform. @IvaVladimir Your change (at version 8fca1903b9669d50c77a9fc895c44d303ddfd95d) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26974#issuecomment-3249787470 From lmesnik at openjdk.org Wed Sep 3 15:49:44 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 3 Sep 2025 15:49:44 GMT Subject: RFR: 8365190: Remove LockingMode related code from share In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> Message-ID: On Tue, 2 Sep 2025 08:24:10 GMT, Fredrik Bredberg wrote: > Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR). > > This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself. > > Passes tier1-tier5 with no added problems. svc part looks good. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3181274100 From duke at openjdk.org Wed Sep 3 15:54:22 2025 From: duke at openjdk.org (pf0n) Date: Wed, 3 Sep 2025 15:54:22 GMT Subject: RFR: 8366122: Shenandoah: Implement efficient support for object count after gc events Message-ID: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com> ### Summary The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work. ### Performance The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen) #### Default workload: ObjectCountAfterGC disabled (master branch): `[807.216s][info][gc,stats ] Pause Init Mark (G) = 0.003 s (a = 264 us)` `[807.216s][info][gc,stats ] Pause Init Mark (N) = 0.001 s (a = 91 us)` `[807.216s][info][gc,stats ] Concurrent Mark Roots = 0.041 s (a = 4099 us)` `[807.216s][info][gc,stats ] Concurrent Marking = 1.660 s (a = 166035 us)` `[807.216s][info][gc,stats ] Pause Final Mark (G) = 0.004 s (a = 446 us) ` `[807.216s][info][gc,stats ] Pause Final Mark (G) = 0.004 s (a = 446 us) ` `[807.216s][info][gc,stats ] Pause Final Mark (N) = 0.004 s (a = 357 us)` ObjectCountAfterGC disabled (feature branch): `[807.104s][info][gc,stats ] Pause Init Mark (G) = 0.003 s (a = 302 us)` `[807.104s][info][gc,stats ] Pause Init Mark (N) = 0.001 s (a = 92 us) ` `[807.104s][info][gc,stats ] Concurrent Mark Roots = 0.048 s (a = 4827 us)` `[807.104s][info][gc,stats ] Concurrent Marking = 1.666 s (a = 166638 us) ` `[807.104s][info][gc,stats ] Pause Final Mark (G) = 0.006 s (a = 603 us)` `[807.104s][info][gc,stats ] Pause Final Mark (N) = 0.005 s (a = 516 us)` ObjectCountAfterGC enabled (feature branch) `[807.299s][info][gc,stats ] Pause Init Mark (G) = 0.002 s (a = 227 us)` `[807.299s][info][gc,stats ] Pause Init Mark (N) = 0.001 s (a = 89 us) ` `[807.299s][info][gc,stats ] Concurrent Mark Roots = 0.053 s (a = 5279 us)` `[807.299s][info][gc,stats ] Concurrent Marking = 1.676 s (a = 167595 us)` `[807.299s][info][gc,stats ] Pause Final Mark (G) = 0.005 s (a = 537 us)` `[807.299s][info][gc,stats ] Pause Final Mark (N) = 0.004 s (a = 430 us)` #### Stress workload: ObjectCountAfterGC disabled (master branch): `[1213.361s][info][gc,stats ] Pause Init Mark (G) = 0.023 s (a = 232 us)` `[1213.361s][info][gc,stats ] Pause Init Mark (N) = 0.009 s (a = 85 us)` `[1213.361s][info][gc,stats ] Concurrent Mark Roots = 0.252 s (a = 2521 us)` `[1213.361s][info][gc,stats ] Concurrent Marking = 17.635 s (a = 176354 us) ` `[1213.361s][info][gc,stats ] Pause Final Mark (G) = 0.065 s (a = 651 us)` `[1213.361s][info][gc,stats ] Pause Final Mark (N) = 0.049 s (a = 493 us)` ObjectCountAfterGC disabled (feature branch): `[1213.626s][info][gc,stats ] Pause Init Mark (G) = 0.023 s (a = 234 us)` `[1213.626s][info][gc,stats ] Pause Init Mark (N) = 0.009 s (a = 86 us)` `[1213.626s][info][gc,stats ] Concurrent Mark Roots = 0.265 s (a = 2645 us)` `[1213.626s][info][gc,stats ] Concurrent Marking = 17.747 s (a = 177468 us)` `[1213.626s][info][gc,stats ] Pause Final Mark (G) = 0.043 s (a = 431 us)` `[1213.626s][info][gc,stats ] Pause Final Mark (N) = 0.036 s (a = 362 us)` ObjectCountAfterGC enabled (feature branch): `[1213.699s][info][gc,stats ] Pause Init Mark (G) = 0.020 s (a = 202 us) ` `[1213.699s][info][gc,stats ] Pause Init Mark (N) = 0.008 s (a = 83 us)` `[1213.699s][info][gc,stats ] Concurrent Mark Roots = 0.340 s (a = 3404 us)` `[1213.699s][info][gc,stats ] Concurrent Marking = 17.929 s (a = 179289 us)` `[1213.699s][info][gc,stats ] Pause Final Mark (G) = 0.049 s (a = 492 us)` `[1213.699s][info][gc,stats ] Pause Final Mark (N) = 0.040 s (a = 405 us)` ### Testing Tested changes with GHA, jtreg tier1 JFR, and hotspot_gc. CodePipeline internal perf and stress test succeeded. ------------- Commit messages: - Changed comment, included another guard - Removing whitespace - Merge master - Merge master - Merge branch 'master' of https://github.com/openjdk/jdk into test/shen-aggregate-closure - Comment on why return value was changed to bool - Deleted objectCountEventSender.inline.hpp - Merging master - Reverting changes back to original state for some files - Merge branch '8366122/shen-object-count-after-gc' into test/shen-aggregate-closure - ... and 121 more: https://git.openjdk.org/jdk/compare/efb81daf...9552c62b Changes: https://git.openjdk.org/jdk/pull/26977/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26977&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366122 Stats: 307 lines in 24 files changed: 252 ins; 28 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/26977.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26977/head:pull/26977 PR: https://git.openjdk.org/jdk/pull/26977 From kdnilsen at openjdk.org Wed Sep 3 15:54:22 2025 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Wed, 3 Sep 2025 15:54:22 GMT Subject: RFR: 8366122: Shenandoah: Implement efficient support for object count after gc events In-Reply-To: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com> References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com> Message-ID: On Thu, 28 Aug 2025 01:30:39 GMT, pf0n wrote: > ### Summary > > The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work. > > ### Performance > The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen) > > #### Default workload: > ObjectCountAfterGC disabled (master branch): > `[807.216s][info][gc,stats ] Pause Init Mark (G) = 0.003 s (a = 264 us)` > `[807.216s][info][gc,stats ] Pause Init Mark (N) = 0.001 s (a = 91 us)` > `[807.216s][info][gc,stats ] Concurrent Mark Roots = 0.041 s (a = 4099 us)` > `[807.216s][info][gc,stats ] Concurrent Marking = 1.660 s (a = 166035 us)` > `[807.216s][info][gc,stats ] Pause Final Mark (G) = 0.004 s (a = 446 us) ` > `[807.216s][info][gc,stats ] Pause Final Mark (G) = 0.004 s (a = 446 us) ` > `[807.216s][info][gc,stats ] Pause Final Mark (N) = 0.004 s (a = 357 us)` > > ObjectCountAfterGC disabled (feature branch): > `[807.104s][info][gc,stats ] Pause Init Mark (G) = 0.003 s (a = 302 us)` > `[807.104s][info][gc,stats ] Pause Init Mark (N) = 0.001 s (a = 92 us) ` > `[807.104s][info][gc,stats ] Concurrent Mark Roots = 0.048 s (a = 4827 us)` > `[807.104s][info][gc,stats ] Concurrent Marking = 1.666 s (a = 166638 us) ` > `[807.104s][info][gc,stats ] Pause Final Mark (G) = 0.006 s (a = 603 us)` > `[807.104s][info][gc,stats ] Pause Final Mark (N) = 0.005 s (a = 516 us)` > > ObjectCountAfterGC enabled (feature branch) > `[807.299s][info][gc,stats ] Pause Init Mark (G) = 0.002 s (a = 227 us)` > `[807.299s][info][gc,stats ] Pause Init Mark (N) = 0.001 s (a = 89 us) ` > `[807.299s][info][gc,stats ] Concurrent Mark Roots = 0.053 s (a = 5279 us)` > `[807.299s][info][gc,st... I concur with comments by Ramki. Also, I wonder if you can add to the summary overview a description of how much additional memory is required to enable concurrent object counting. I believe there is a new thread-local table (how large is this?) for each GC worker thread. I think service threads do not need this table. Can you clarify? The performance numbers quoted in the performance summary above are for Shennadoah satb mode, or for generational mode? Maybe both should be reported. src/hotspot/share/gc/shared/gcTrace.inline.hpp line 12: > 10: > 11: // The ObjectCountEventSenderClosure will determine if only the ObjectCount > 12: // event will be emitted instead of ObjectCountAfterGC. If false, then both If "what" is false? This comment is not clear. Are you speaking of the SeparateEventEmission template parameter? I think the use of future-tense "will" also makes this comment confusing. Can you write this in present tense? ------------- PR Review: https://git.openjdk.org/jdk/pull/26977#pullrequestreview-3166929412 PR Comment: https://git.openjdk.org/jdk/pull/26977#issuecomment-3235270167 PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308805732 From wkemper at openjdk.org Wed Sep 3 15:54:23 2025 From: wkemper at openjdk.org (William Kemper) Date: Wed, 3 Sep 2025 15:54:23 GMT Subject: RFR: 8366122: Shenandoah: Implement efficient support for object count after gc events In-Reply-To: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com> References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com> Message-ID: On Thu, 28 Aug 2025 01:30:39 GMT, pf0n wrote: > ### Summary > > The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work. > > ### Performance > The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen) > > #### Default workload: > ObjectCountAfterGC disabled (master branch): > `[807.216s][info][gc,stats ] Pause Init Mark (G) = 0.003 s (a = 264 us)` > `[807.216s][info][gc,stats ] Pause Init Mark (N) = 0.001 s (a = 91 us)` > `[807.216s][info][gc,stats ] Concurrent Mark Roots = 0.041 s (a = 4099 us)` > `[807.216s][info][gc,stats ] Concurrent Marking = 1.660 s (a = 166035 us)` > `[807.216s][info][gc,stats ] Pause Final Mark (G) = 0.004 s (a = 446 us) ` > `[807.216s][info][gc,stats ] Pause Final Mark (G) = 0.004 s (a = 446 us) ` > `[807.216s][info][gc,stats ] Pause Final Mark (N) = 0.004 s (a = 357 us)` > > ObjectCountAfterGC disabled (feature branch): > `[807.104s][info][gc,stats ] Pause Init Mark (G) = 0.003 s (a = 302 us)` > `[807.104s][info][gc,stats ] Pause Init Mark (N) = 0.001 s (a = 92 us) ` > `[807.104s][info][gc,stats ] Concurrent Mark Roots = 0.048 s (a = 4827 us)` > `[807.104s][info][gc,stats ] Concurrent Marking = 1.666 s (a = 166638 us) ` > `[807.104s][info][gc,stats ] Pause Final Mark (G) = 0.006 s (a = 603 us)` > `[807.104s][info][gc,stats ] Pause Final Mark (N) = 0.005 s (a = 516 us)` > > ObjectCountAfterGC enabled (feature branch) > `[807.299s][info][gc,stats ] Pause Init Mark (G) = 0.002 s (a = 227 us)` > `[807.299s][info][gc,stats ] Pause Init Mark (N) = 0.001 s (a = 89 us) ` > `[807.299s][info][gc,stats ] Concurrent Mark Roots = 0.053 s (a = 5279 us)` > `[807.299s][info][gc,st... Left a few superficial suggestions. My big question is what work remains for this event to also work with the generational mode? src/hotspot/share/gc/shared/gcTrace.hpp line 136: > 134: void report_gc_reference_stats(const ReferenceProcessorStats& rp) const; > 135: void report_object_count_after_gc(BoolObjectClosure* object_filter, WorkerThreads* workers) NOT_SERVICES_RETURN; > 136: // Report object count by not performing a heap inspection. This method will s/by not/without src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 179: > 177: // Use object counting closure if ObjectCount or ObjectCountAfterGC event is enabled. > 178: const bool object_count_enabled = ObjectCountEventSender::should_send_event(); > 179: if (object_count_enabled && !ShenandoahHeap::heap()->mode()->is_generational()) { Can the generational mode support this? It can also perform a _global_ collection. src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 130: > 128: // Create the KlassInfoTable for Shenandoah only if JFR is enabled. > 129: #if INCLUDE_JFR > 130: KlassInfoTable cit(false); Might consider a `CADR` helper class here (Constructor Acquires, Destructor Releases). There are a lot of lines of code between the two `set_cit` calls (and the second one isn't guarded by `INCLUDE_JFR`). src/hotspot/share/memory/heapInspection.hpp line 33: > 31: #include "oops/objArrayOop.hpp" > 32: #include "oops/oop.hpp" > 33: #include "runtime/mutex.hpp" Does this need to be in the header? src/hotspot/share/runtime/mutexLocker.hpp line 90: > 88: extern Monitor* Notify_lock; // a lock used to synchronize the start-up of the vm > 89: extern Mutex* ExceptionCache_lock; // a lock used to synchronize exception cache updates > 90: extern Mutex* TableMerge_lock; // a lock used to synchronize merging a thread-local table into a global table Might call this `ObjectCountMerge_lock` and describe its usage as `merging a thread local object count`. There are many `Tables` in the JVM (SymbolTable, InternedStrings, etc.). test/jdk/jdk/jfr/event/gc/objectcount/TestObjectCountAfterGCEventWithShenandoah.java line 11: > 9: * & vm.opt.ExplicitGCInvokesConcurrent != true > 10: * @library /test/lib /test/jdk > 11: * @run main/othervm -XX:+UnlockExperimentalVMOptions -XX:-UseFastUnorderedTimeStamps -XX:+UseShenandoahGC -XX:MarkSweepDeadRatio=0 -XX:-UseCompressedOops -XX:-UseCompressedClassPointers -XX:+IgnoreUnrecognizedVMOptions jdk.jfr.event.gc.objectcount.TestObjectCountAfterGCEventWithShenandoah Are all of these flags necessary to run this test? Can we pare any unnecessary options? ------------- Changes requested by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26977#pullrequestreview-3178372422 PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317339492 PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317344826 PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317348710 PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317355707 PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317358657 PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317360739 From ysr at openjdk.org Wed Sep 3 15:54:24 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Wed, 3 Sep 2025 15:54:24 GMT Subject: RFR: 8366122: Shenandoah: Implement efficient support for object count after gc events In-Reply-To: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com> References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com> Message-ID: On Thu, 28 Aug 2025 01:30:39 GMT, pf0n wrote: > ### Summary > > The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work. > > ### Performance > The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen) > > #### Default workload: > ObjectCountAfterGC disabled (master branch): > `[807.216s][info][gc,stats ] Pause Init Mark (G) = 0.003 s (a = 264 us)` > `[807.216s][info][gc,stats ] Pause Init Mark (N) = 0.001 s (a = 91 us)` > `[807.216s][info][gc,stats ] Concurrent Mark Roots = 0.041 s (a = 4099 us)` > `[807.216s][info][gc,stats ] Concurrent Marking = 1.660 s (a = 166035 us)` > `[807.216s][info][gc,stats ] Pause Final Mark (G) = 0.004 s (a = 446 us) ` > `[807.216s][info][gc,stats ] Pause Final Mark (G) = 0.004 s (a = 446 us) ` > `[807.216s][info][gc,stats ] Pause Final Mark (N) = 0.004 s (a = 357 us)` > > ObjectCountAfterGC disabled (feature branch): > `[807.104s][info][gc,stats ] Pause Init Mark (G) = 0.003 s (a = 302 us)` > `[807.104s][info][gc,stats ] Pause Init Mark (N) = 0.001 s (a = 92 us) ` > `[807.104s][info][gc,stats ] Concurrent Mark Roots = 0.048 s (a = 4827 us)` > `[807.104s][info][gc,stats ] Concurrent Marking = 1.666 s (a = 166638 us) ` > `[807.104s][info][gc,stats ] Pause Final Mark (G) = 0.006 s (a = 603 us)` > `[807.104s][info][gc,stats ] Pause Final Mark (N) = 0.005 s (a = 516 us)` > > ObjectCountAfterGC enabled (feature branch) > `[807.299s][info][gc,stats ] Pause Init Mark (G) = 0.002 s (a = 227 us)` > `[807.299s][info][gc,stats ] Pause Init Mark (N) = 0.001 s (a = 89 us) ` > `[807.299s][info][gc,stats ] Concurrent Mark Roots = 0.053 s (a = 5279 us)` > `[807.299s][info][gc,st... @pf0n : 1. For the performance numbers, use the final summaries (in the gc log) of quartile and range of time distributions of the pauses and the phases to better reflect the impact on collections throughout the entire run, rather than for specific spot collections. 2. For completeness in the PR description and to help reviewers, please comment upon whether, when the event is enabled, the counting closures are used also for collections other than concurrent ones and where the events are emitted in those cases. Thanks! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 129: > 127: if (gc_requested) { > 128: // Create the KlassInfoTable for Shenandoah only if JFR is enabled. > 129: #if INCLUDE_JFR Here and elsewhere: 1. for single line pre-proc directives, consider the use of `JFR_ONLY()`. 2. For multi-line pre-proc directives, unindent all the way to the zeroth column, in keeping with hotspot style precedent, even though newer pre-processors accept indented directives. src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 232: > 230: volatile size_t _committed; > 231: shenandoah_padding(1); > 232: KlassInfoTable* _cit; Move the comment from line 257 below to before this place. src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 256: > 254: void set_soft_max_capacity(size_t v); > 255: > 256: // Create Shenandoah's KlassInfoTable. Not create, but set? src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 260: > 258: inline void set_cit(KlassInfoTable* cit); > 259: > 260: // Return Shenandoah's KlassInfoTable. Put these together and use one comment like: // Setter & accessor for class histogram src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 653: > 651: inline void ShenandoahHeap::set_cit(KlassInfoTable* cit) { > 652: assert((_cit == nullptr && cit != nullptr) || > 653: (_cit != nullptr && cit == nullptr), "Initialize once & clear once"); The assert message isn't accurate for your current usage. Suggest splitting into two asserts with a suitable message: assert(_cit == nullptr || cit == nullptr, "Overwriting an existing histogram"); assert(_cit != nullptr || cit != nullptr, "Already cleared"); src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 658: > 656: > 657: inline KlassInfoTable* ShenandoahHeap::get_cit() { > 658: assert(_cit != nullptr, "KlassInfoTable for Shenandoah should be initialized"); Change the message to: "KlassInfoTable is null" (suggestion is to avoid "initialized" here, since the value is repeatedly toggled from a pointer to stack allocated klass info table to null and back). Essentially the heap is used as a post-office-box to pass a handle to a stack allocated object to worker threads using the object. src/hotspot/share/gc/shenandoah/shenandoahMark.cpp line 72: > 70: mark_loop_work(&cl, ld, w, t, req); > 71: } else { > 72: #if INCLUDE_JFR unindent (left-justify to 0th column) src/hotspot/share/gc/shenandoah/shenandoahMark.hpp line 60: > 58: public: > 59: template > 60: static inline bool mark_through_ref(T* p, ShenandoahObjToScanQueue* q, ShenandoahObjToScanQueue* old_q, ShenandoahMarkingContext* const mark_context, bool weak); document the semantics of the method's return value here and everywhere where a bool return replaces a previously void return. src/hotspot/share/runtime/mutexLocker.hpp line 90: > 88: extern Monitor* Notify_lock; // a lock used to synchronize the start-up of the vm > 89: extern Mutex* ExceptionCache_lock; // a lock used to synchronize exception cache updates > 90: extern Mutex* TableMerge_lock; // a lock used to synchronize merging of thread-local KlassInfoTables nit: `... merging a thread-local into a global table` ------------- PR Comment: https://git.openjdk.org/jdk/pull/26977#issuecomment-3235400211 PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308906242 PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308907269 PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308907857 PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308910727 PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308919955 PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308923148 PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308926296 PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308929362 PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2308937729 From duke at openjdk.org Wed Sep 3 15:54:24 2025 From: duke at openjdk.org (pf0n) Date: Wed, 3 Sep 2025 15:54:24 GMT Subject: RFR: 8366122: Shenandoah: Implement efficient support for object count after gc events In-Reply-To: References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com> Message-ID: On Thu, 28 Aug 2025 23:49:20 GMT, Kelvin Nilsen wrote: >> ### Summary >> >> The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work. >> >> ### Performance >> The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen) >> >> #### Default workload: >> ObjectCountAfterGC disabled (master branch): >> `[807.216s][info][gc,stats ] Pause Init Mark (G) = 0.003 s (a = 264 us)` >> `[807.216s][info][gc,stats ] Pause Init Mark (N) = 0.001 s (a = 91 us)` >> `[807.216s][info][gc,stats ] Concurrent Mark Roots = 0.041 s (a = 4099 us)` >> `[807.216s][info][gc,stats ] Concurrent Marking = 1.660 s (a = 166035 us)` >> `[807.216s][info][gc,stats ] Pause Final Mark (G) = 0.004 s (a = 446 us) ` >> `[807.216s][info][gc,stats ] Pause Final Mark (G) = 0.004 s (a = 446 us) ` >> `[807.216s][info][gc,stats ] Pause Final Mark (N) = 0.004 s (a = 357 us)` >> >> ObjectCountAfterGC disabled (feature branch): >> `[807.104s][info][gc,stats ] Pause Init Mark (G) = 0.003 s (a = 302 us)` >> `[807.104s][info][gc,stats ] Pause Init Mark (N) = 0.001 s (a = 92 us) ` >> `[807.104s][info][gc,stats ] Concurrent Mark Roots = 0.048 s (a = 4827 us)` >> `[807.104s][info][gc,stats ] Concurrent Marking = 1.666 s (a = 166638 us) ` >> `[807.104s][info][gc,stats ] Pause Final Mark (G) = 0.006 s (a = 603 us)` >> `[807.104s][info][gc,stats ] Pause Final Mark (N) = 0.005 s (a = 516 us)` >> >> ObjectCountAfterGC enabled (feature branch) >> `[807.299s][info][gc,stats ] Pause Init Mark (G) = 0.002 s (a = 227 us)` >> `[807.299s][info][gc,stats ] Pause Init Mark (N) = 0.001 s (a = 89 us) ` >> `[807.299s][info][gc,stats ] Concurrent Mark Roots ... > > src/hotspot/share/gc/shared/gcTrace.inline.hpp line 12: > >> 10: >> 11: // The ObjectCountEventSenderClosure will determine if only the ObjectCount >> 12: // event will be emitted instead of ObjectCountAfterGC. If false, then both > > If "what" is false? This comment is not clear. Are you speaking of the SeparateEventEmission template parameter? > > I think the use of future-tense "will" also makes this comment confusing. Can you write this in present tense? I'll remove this template parameter, since it won't be needed for the ObjectCountAfterGC PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2312857523 From duke at openjdk.org Wed Sep 3 15:54:24 2025 From: duke at openjdk.org (pf0n) Date: Wed, 3 Sep 2025 15:54:24 GMT Subject: RFR: 8366122: Shenandoah: Implement efficient support for object count after gc events In-Reply-To: References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com> Message-ID: On Tue, 2 Sep 2025 22:46:52 GMT, William Kemper wrote: >> ### Summary >> >> The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work. >> >> ### Performance >> The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen) >> >> #### Default workload: >> ObjectCountAfterGC disabled (master branch): >> `[807.216s][info][gc,stats ] Pause Init Mark (G) = 0.003 s (a = 264 us)` >> `[807.216s][info][gc,stats ] Pause Init Mark (N) = 0.001 s (a = 91 us)` >> `[807.216s][info][gc,stats ] Concurrent Mark Roots = 0.041 s (a = 4099 us)` >> `[807.216s][info][gc,stats ] Concurrent Marking = 1.660 s (a = 166035 us)` >> `[807.216s][info][gc,stats ] Pause Final Mark (G) = 0.004 s (a = 446 us) ` >> `[807.216s][info][gc,stats ] Pause Final Mark (G) = 0.004 s (a = 446 us) ` >> `[807.216s][info][gc,stats ] Pause Final Mark (N) = 0.004 s (a = 357 us)` >> >> ObjectCountAfterGC disabled (feature branch): >> `[807.104s][info][gc,stats ] Pause Init Mark (G) = 0.003 s (a = 302 us)` >> `[807.104s][info][gc,stats ] Pause Init Mark (N) = 0.001 s (a = 92 us) ` >> `[807.104s][info][gc,stats ] Concurrent Mark Roots = 0.048 s (a = 4827 us)` >> `[807.104s][info][gc,stats ] Concurrent Marking = 1.666 s (a = 166638 us) ` >> `[807.104s][info][gc,stats ] Pause Final Mark (G) = 0.006 s (a = 603 us)` >> `[807.104s][info][gc,stats ] Pause Final Mark (N) = 0.005 s (a = 516 us)` >> >> ObjectCountAfterGC enabled (feature branch) >> `[807.299s][info][gc,stats ] Pause Init Mark (G) = 0.002 s (a = 227 us)` >> `[807.299s][info][gc,stats ] Pause Init Mark (N) = 0.001 s (a = 89 us) ` >> `[807.299s][info][gc,stats ] Concurrent Mark Roots ... > > src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 179: > >> 177: // Use object counting closure if ObjectCount or ObjectCountAfterGC event is enabled. >> 178: const bool object_count_enabled = ObjectCountEventSender::should_send_event(); >> 179: if (object_count_enabled && !ShenandoahHeap::heap()->mode()->is_generational()) { > > Can the generational mode support this? It can also perform a _global_ collection. It could be possible to extend the object counting closure for GenShen. I would have to look more deep into where the closure can be used. > src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 130: > >> 128: // Create the KlassInfoTable for Shenandoah only if JFR is enabled. >> 129: #if INCLUDE_JFR >> 130: KlassInfoTable cit(false); > > Might consider a `CADR` helper class here (Constructor Acquires, Destructor Releases). There are a lot of lines of code between the two `set_cit` calls (and the second one isn't guarded by `INCLUDE_JFR`). I'll look into that. Thanks for pointing out the unguarded `set_cit`. > src/hotspot/share/memory/heapInspection.hpp line 33: > >> 31: #include "oops/objArrayOop.hpp" >> 32: #include "oops/oop.hpp" >> 33: #include "runtime/mutex.hpp" > > Does this need to be in the header? I had an error in GHA during my early implementation, so I included that header. I'll remove and test to see if it is needed or not. > test/jdk/jdk/jfr/event/gc/objectcount/TestObjectCountAfterGCEventWithShenandoah.java line 11: > >> 9: * & vm.opt.ExplicitGCInvokesConcurrent != true >> 10: * @library /test/lib /test/jdk >> 11: * @run main/othervm -XX:+UnlockExperimentalVMOptions -XX:-UseFastUnorderedTimeStamps -XX:+UseShenandoahGC -XX:MarkSweepDeadRatio=0 -XX:-UseCompressedOops -XX:-UseCompressedClassPointers -XX:+IgnoreUnrecognizedVMOptions jdk.jfr.event.gc.objectcount.TestObjectCountAfterGCEventWithShenandoah > > Are all of these flags necessary to run this test? Can we pare any unnecessary options? All of the collectors that test for the ObjectCountAfterGC event uses these flags. I thought it would be best to keep it consistent for the Shenandoah test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317633120 PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317630478 PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317545276 PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317555401 From duke at openjdk.org Wed Sep 3 15:54:25 2025 From: duke at openjdk.org (pf0n) Date: Wed, 3 Sep 2025 15:54:25 GMT Subject: RFR: 8366122: Shenandoah: Implement efficient support for object count after gc events In-Reply-To: References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com> Message-ID: On Wed, 3 Sep 2025 02:58:42 GMT, pf0n wrote: >> src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 179: >> >>> 177: // Use object counting closure if ObjectCount or ObjectCountAfterGC event is enabled. >>> 178: const bool object_count_enabled = ObjectCountEventSender::should_send_event(); >>> 179: if (object_count_enabled && !ShenandoahHeap::heap()->mode()->is_generational()) { >> >> Can the generational mode support this? It can also perform a _global_ collection. > > It could be possible to extend the object counting closure for GenShen. I would have to look more deep into where the closure can be used. GenShen shares the same marking closure as Shenandoah, but it is templatized differently. At surface level, we would just have to replace the marking closure used for the global collection with the object counting closure, but there might be other work to be done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2317645883 From pchilanomate at openjdk.org Wed Sep 3 15:59:51 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 3 Sep 2025 15:59:51 GMT Subject: RFR: 8365937: post_method_exit might incorrectly set was_popped_by_exception and value in the middle of stack unwinding [v4] In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 19:11:04 GMT, Leonid Mesnik wrote: >> The void `JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame current_frame) `calculates >> `bool exception_exit = state->is_exception_detected() && !state->is_exception_caught();` >> to find if method exit normally or by exception. >> However, JvmtiExport::post_method_exit( method is not called at all in the case of exception. See >> `void JvmtiExport::notice_unwind_due_to_exception(JavaThread *thread, Method* method, address location, oop exception, bool in_handler_frame)` >> where post_method_exit_inner is called directly. >> >> The `exception_exit` is true when exception is processed and the current method is called in the middle of stack unwinding. >> >> >> The fix was a part of >> https://github.com/openjdk/jdk/pull/26713 >> for >> https://bugs.openjdk.org/browse/JDK-8365192 > > Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: > > - Apply suggestions from code review > > Co-authored-by: Patricio Chilano Mateo > - Update test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp > > Co-authored-by: Patricio Chilano Mateo Marked as reviewed by pchilanomate (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26886#pullrequestreview-3181311632 From duke at openjdk.org Wed Sep 3 16:49:03 2025 From: duke at openjdk.org (pf0n) Date: Wed, 3 Sep 2025 16:49:03 GMT Subject: RFR: 8366122: Shenandoah: Implement efficient support for object count after gc events [v2] In-Reply-To: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com> References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com> Message-ID: > ### Summary > > The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work. > > ### Performance > The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen) > > #### Default workload: > ObjectCountAfterGC disabled (master branch): > `[807.216s][info][gc,stats ] Pause Init Mark (G) = 0.003 s (a = 264 us)` > `[807.216s][info][gc,stats ] Pause Init Mark (N) = 0.001 s (a = 91 us)` > `[807.216s][info][gc,stats ] Concurrent Mark Roots = 0.041 s (a = 4099 us)` > `[807.216s][info][gc,stats ] Concurrent Marking = 1.660 s (a = 166035 us)` > `[807.216s][info][gc,stats ] Pause Final Mark (G) = 0.004 s (a = 446 us) ` > `[807.216s][info][gc,stats ] Pause Final Mark (G) = 0.004 s (a = 446 us) ` > `[807.216s][info][gc,stats ] Pause Final Mark (N) = 0.004 s (a = 357 us)` > > ObjectCountAfterGC disabled (feature branch): > `[807.104s][info][gc,stats ] Pause Init Mark (G) = 0.003 s (a = 302 us)` > `[807.104s][info][gc,stats ] Pause Init Mark (N) = 0.001 s (a = 92 us) ` > `[807.104s][info][gc,stats ] Concurrent Mark Roots = 0.048 s (a = 4827 us)` > `[807.104s][info][gc,stats ] Concurrent Marking = 1.666 s (a = 166638 us) ` > `[807.104s][info][gc,stats ] Pause Final Mark (G) = 0.006 s (a = 603 us)` > `[807.104s][info][gc,stats ] Pause Final Mark (N) = 0.005 s (a = 516 us)` > > ObjectCountAfterGC enabled (feature branch) > `[807.299s][info][gc,stats ] Pause Init Mark (G) = 0.002 s (a = 227 us)` > `[807.299s][info][gc,stats ] Pause Init Mark (N) = 0.001 s (a = 89 us) ` > `[807.299s][info][gc,stats ] Concurrent Mark Roots = 0.053 s (a = 5279 us)` > `[807.299s][info][gc,st... pf0n has updated the pull request incrementally with two additional commits since the last revision: - Using JFR_ONLY - Changed comment, included another guard ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26977/files - new: https://git.openjdk.org/jdk/pull/26977/files/9552c62b..6a3c6318 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26977&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26977&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26977.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26977/head:pull/26977 PR: https://git.openjdk.org/jdk/pull/26977 From kbarrett at openjdk.org Wed Sep 3 18:03:45 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 3 Sep 2025 18:03:45 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 [v4] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 23:31:03 GMT, Kim Barrett wrote: >> Please review this change to use C++17 for building C++ parts of the JDK. In >> particular this affects HotSpot. This change also includes an update to the >> HotSpot Style Guide regarding C++17 features and their use in HotSpot code. >> >> Testing: mach5 tier1-8 >> >> This change includes a modification of the Style Guide. Rough consensus among >> the HotSpot Group members is required to make such a change. Only Group >> members should vote for approval (via the github PR), though reasoned >> objections or comments from anyone will be considered. A decision on this >> proposal will not be made before Friday 5-September-2025 at 12h00 UTC. >> >> Since we're piggybacking on github PRs here, please use the PR review process >> to approve (click on Review Changes > Approve), rather than sending a "vote: >> yes" email reply that would be normal for a CFV. > > Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: > > - missing word > - stefank suggestions Any further comments or approvals? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26884#issuecomment-3250230147 From ayang at openjdk.org Wed Sep 3 18:50:48 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 3 Sep 2025 18:50:48 GMT Subject: RFR: 8366155: Serial: Obsolete PretenureSizeThreshold In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 11:44:35 GMT, Albert Mingkun Yang wrote: > Remove obj-size checking before young/old-gen allocation -- an allocation succeeds iff there is enough free space. > > This simplifies the allocation logic: > 1. before attempting gc: `mem_allocate_work` does young-gen allocation then old-gen-no-expansion allocation > 2. after gc (still inside gc safepoint): `satisfy_failed_allocation` does young-gen allocation old-gen-with-expansion allocation > > Test: tier1-3 Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26941#issuecomment-3250368237 From ayang at openjdk.org Wed Sep 3 18:50:49 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 3 Sep 2025 18:50:49 GMT Subject: Integrated: 8366155: Serial: Obsolete PretenureSizeThreshold In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 11:44:35 GMT, Albert Mingkun Yang wrote: > Remove obj-size checking before young/old-gen allocation -- an allocation succeeds iff there is enough free space. > > This simplifies the allocation logic: > 1. before attempting gc: `mem_allocate_work` does young-gen allocation then old-gen-no-expansion allocation > 2. after gc (still inside gc safepoint): `satisfy_failed_allocation` does young-gen allocation old-gen-with-expansion allocation > > Test: tier1-3 This pull request has now been integrated. Changeset: 8d236615 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/8d236615b7db2bd5a2a59002b79e59cf4e6a308a Stats: 86 lines in 7 files changed: 3 ins; 75 del; 8 mod 8366155: Serial: Obsolete PretenureSizeThreshold Reviewed-by: tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/26941 From kbarrett at openjdk.org Wed Sep 3 18:52:42 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 3 Sep 2025 18:52:42 GMT Subject: RFR: 8300080: offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant In-Reply-To: <0T5Bpw4E7qu10pWz981nWwFgNet_sas0vPi4K5v70LU=.17e8d99a-3663-47ef-874b-1349bd919229@github.com> References: <0T5Bpw4E7qu10pWz981nWwFgNet_sas0vPi4K5v70LU=.17e8d99a-3663-47ef-874b-1349bd919229@github.com> Message-ID: On Wed, 3 Sep 2025 07:28:49 GMT, Stefan Karlsson wrote: > Nice. Is it worth pushing this so near the transition to compile with C++17 support? Including the warning suppression gives something that's usefully backportable, which would make it easier to backport changes that happen to include any future `offset_of` to `offsetof` changes. The warning suppression is harmless in C++17 mode, and can be removed at leisure once that mode is engaged. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27061#issuecomment-3250377743 From kvn at openjdk.org Wed Sep 3 18:54:47 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 3 Sep 2025 18:54:47 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 [v4] In-Reply-To: References: Message-ID: <-19Udqn-E9_D82hvJZaOCHz9mc-GK9G_PETnNNqSmxg=.968f5927-87f2-4174-93f3-1c296570ea0d@github.com> On Mon, 25 Aug 2025 23:31:03 GMT, Kim Barrett wrote: >> Please review this change to use C++17 for building C++ parts of the JDK. In >> particular this affects HotSpot. This change also includes an update to the >> HotSpot Style Guide regarding C++17 features and their use in HotSpot code. >> >> Testing: mach5 tier1-8 >> >> This change includes a modification of the Style Guide. Rough consensus among >> the HotSpot Group members is required to make such a change. Only Group >> members should vote for approval (via the github PR), though reasoned >> objections or comments from anyone will be considered. A decision on this >> proposal will not be made before Friday 5-September-2025 at 12h00 UTC. >> >> Since we're piggybacking on github PRs here, please use the PR review process >> to approve (click on Review Changes > Approve), rather than sending a "vote: >> yes" email reply that would be normal for a CFV. > > Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: > > - missing word > - stefank suggestions Approved ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26884#pullrequestreview-3182008369 From vaivanov at openjdk.org Wed Sep 3 19:18:36 2025 From: vaivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 3 Sep 2025 19:18:36 GMT Subject: RFR: 8363858: [perf] OptimizeFill may use wide set of intrinsics [v2] In-Reply-To: References: Message-ID: <5-yAlFxUHtE1TyZPS-EU-o_3QhkFdCVGTE7kY7vRabo=.eea74242-b669-47f4-8f87-cfbba15267f1@github.com> > Default mode should use OptimizeFill=true option for the SRF platform. Vladimir Ivanov has updated the pull request incrementally with 106 additional commits since the last revision: - 8366155: Serial: Obsolete PretenureSizeThreshold Reviewed-by: tschatzl - 8366401: JCK test api/java_text/DecimalFormatSymbols/serial/InputTests.html fails after JDK-8363972 Reviewed-by: naoto - 8366537: Test "java/util/TimeZone/DefaultTimeZoneTest.java" is not updating the zone ID as expected Reviewed-by: naoto, jlu - 8366768: Problemlist jdk/jshell/ToolSimpleTest.java Reviewed-by: jlahoda - 8366298: FDLeakTest sometimes takes minutes to complete on Linux Reviewed-by: lkorinth, rriggs, stuefe - 8363966: GHA: Switch cross-compiling sysroots to Debian trixie Reviewed-by: ayang, fyang, erikj - 8366803: Bump timeout on sun/tools/jhsdb/BasicLauncherTest.java Reviewed-by: stefank - 8366543: Clean up include headers in numberSeq Reviewed-by: tschatzl - 8366660: Sort share/nmt includes Reviewed-by: ayang, shade - 8329077: C2 SuperWord: Add MoveD2L, MoveL2D, MoveF2I, MoveI2F Reviewed-by: epeter, qamai - ... and 96 more: https://git.openjdk.org/jdk/compare/8fca1903...8b16a897 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26974/files - new: https://git.openjdk.org/jdk/pull/26974/files/8fca1903..8b16a897 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26974&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26974&range=00-01 Stats: 16895 lines in 809 files changed: 12117 ins; 2304 del; 2474 mod Patch: https://git.openjdk.org/jdk/pull/26974.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26974/head:pull/26974 PR: https://git.openjdk.org/jdk/pull/26974 From iklam at openjdk.org Wed Sep 3 19:36:51 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 3 Sep 2025 19:36:51 GMT Subject: RFR: 8356548: Avoid using ASM to parse latest class files in tests [v6] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 15:06:46 GMT, Chen Liang wrote: >> For early eval; test by changing the ClassReader max accepted version of test ASM to 24 instead of 25 > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade > - Merge branch 'fix/asm-test-upgrade' of github.com:liachmodded/jdk into fix/asm-test-upgrade > - Update test/hotspot/jtreg/compiler/calls/common/InvokeDynamicPatcher.java > > Co-authored-by: Andrew Haley > - Variable name improvements > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade > - Move other tier 4,5, etc tests to not use ClassReader > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade > - Use classfile api instead of javac setting version > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade > - ... and 1 more: https://git.openjdk.org/jdk/compare/e0d5ae0b...a659f538 I looked at the diff with whitespace off and looked at all change. They seem reasonable to me. The bytecode changes seems to be 1-1 matching with the old code. I just have a few style nits. Since the changes are subtle, I think before integration, you should do a final run up to tier 6 just to be safe. test/hotspot/jtreg/compiler/jvmci/common/CTVMUtilities.java line 80: > 78: throw new Error("TEST BUG: cannot read " + binaryName, e); > 79: } > 80: ClassModel classModel = ClassFile.of().parse(fileBytes); Can you put these in a separate function, like `ClassModel getClassModel(Class class)`? test/hotspot/jtreg/compiler/jvmci/common/CTVMUtilities.java line 93: > 91: for (var methodModel : classModel.methods()) { > 92: if (methodModel.methodName().equalsString(methodName) > 93: && methodModel.methodType().isMethodType(methodType)) { For readability, I think we should put the above in a separate function, and then: var methodModel = findMethodInClass(classModel, m); Then we can potentially use findMethodInClass() in other test cases when we have a need to do so. test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/MissedStackMapFrames/MissedStackMapFrames.java line 64: > 62: var foundStackMapTable = method.code().flatMap(code -> code.findAttribute(Attributes.stackMapTable())); > 63: if (foundStackMapTable.isPresent()) { > 64: count += foundStackMapTable.get().entries().size(); The old logging should be preserved: log(" method " + name + " - " + methodFrames + " frames"); test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineAnnotations.java line 104: > 102: public void atEnd(ClassBuilder builder) { > 103: // Re-add dummy fields > 104: dummyFields.forEach(builder); Comment: `// Re-add dummy fields at the end of the class` ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25124#pullrequestreview-3182050159 PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2319959194 PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2319956360 PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2319921409 PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2319969688 From kbarrett at openjdk.org Wed Sep 3 19:48:42 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 3 Sep 2025 19:48:42 GMT Subject: RFR: 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown [v2] In-Reply-To: <9MccMrhJLB1DC6NP_9aYvnC9EhwqW_iko5Cxdbfxn_k=.4e1db66e-3ffb-4162-a3de-d17169212159@github.com> References: <3TJnBvDoAPUf4p2e8Y0vpckfm3v8e31cKKwfOeyRnnM=.34c016f4-419d-4dd6-9102-b112a7423f7b@github.com> <9MccMrhJLB1DC6NP_9aYvnC9EhwqW_iko5Cxdbfxn_k=.4e1db66e-3ffb-4162-a3de-d17169212159@github.com> Message-ID: On Wed, 3 Sep 2025 14:00:05 GMT, Thomas Stuefe wrote: > I still am not sure how the OrderAccess helps. A concurrent thread can see xtty != null and start printing while the terminating thread deletes the defaultStream under xtty? Sorry if I am slow. I agree with @tstuefe - I'm not seeing how this actually helps. Esp. since the other side of these operations typically (universally?) doesn't have any memory ordering, and where there are null checks they are often of the form `if (global_x != nullptr) { ... use global_x ... }` ------------- PR Comment: https://git.openjdk.org/jdk/pull/26832#issuecomment-3250549019 From vaivanov at openjdk.org Wed Sep 3 22:11:17 2025 From: vaivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 3 Sep 2025 22:11:17 GMT Subject: RFR: 8363858: [perf] OptimizeFill may use wide set of intrinsics [v3] In-Reply-To: References: Message-ID: > Default mode should use OptimizeFill=true option for the SRF platform. Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8363858: [perf] OptimizeFill may use wide set of intrinsics ------------- Changes: https://git.openjdk.org/jdk/pull/26974/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26974&range=02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26974.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26974/head:pull/26974 PR: https://git.openjdk.org/jdk/pull/26974 From sviswanathan at openjdk.org Wed Sep 3 23:46:42 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Wed, 3 Sep 2025 23:46:42 GMT Subject: RFR: 8363858: [perf] OptimizeFill may use wide set of intrinsics [v3] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 22:11:17 GMT, Vladimir Ivanov wrote: >> Default mode should use OptimizeFill=true option for the SRF platform. > > Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8363858: [perf] OptimizeFill may use wide set of intrinsics Looks good to me. ------------- Marked as reviewed by sviswanathan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26974#pullrequestreview-3182905455 From ysr at openjdk.org Thu Sep 4 00:15:49 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 4 Sep 2025 00:15:49 GMT Subject: RFR: 8366122: Shenandoah: Implement efficient support for object count after gc events [v2] In-Reply-To: References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com> Message-ID: <_7YHL1mTJBL7b_EgdhbFJZ2hIFiOD0Tjqy0APNy-h2g=.16b48215-3ac0-4964-9ce2-e8ee475109b3@github.com> On Wed, 3 Sep 2025 01:31:24 GMT, pf0n wrote: >> src/hotspot/share/memory/heapInspection.hpp line 33: >> >>> 31: #include "oops/objArrayOop.hpp" >>> 32: #include "oops/oop.hpp" >>> 33: #include "runtime/mutex.hpp" >> >> Does this need to be in the header? > > I had an error in GHA during my early implementation, so I included that header. I'll remove and test to see if it is needed or not. I believe you need it for this: https://github.com/pf0n/jdk/blob/f43e334bf76f878ec688cbd58a5ab1cb10deb0f9/src/hotspot/share/memory/heapInspection.hpp#L218 It probably happens to work at other places because of preceding includes that happen to satisfy this. Explicitly including it here makes sense for that reason. Not sure why it just started showing up, but likely a new use that didn't otherwise satisfy this include. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2320510893 From duke at openjdk.org Thu Sep 4 00:27:49 2025 From: duke at openjdk.org (pf0n) Date: Thu, 4 Sep 2025 00:27:49 GMT Subject: RFR: 8366122: Shenandoah: Implement efficient support for object count after gc events [v2] In-Reply-To: <_7YHL1mTJBL7b_EgdhbFJZ2hIFiOD0Tjqy0APNy-h2g=.16b48215-3ac0-4964-9ce2-e8ee475109b3@github.com> References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com> <_7YHL1mTJBL7b_EgdhbFJZ2hIFiOD0Tjqy0APNy-h2g=.16b48215-3ac0-4964-9ce2-e8ee475109b3@github.com> Message-ID: On Thu, 4 Sep 2025 00:12:48 GMT, Y. Srinivas Ramakrishna wrote: >> I had an error in GHA during my early implementation, so I included that header. I'll remove and test to see if it is needed or not. > > I believe you need it for this: https://github.com/pf0n/jdk/blob/f43e334bf76f878ec688cbd58a5ab1cb10deb0f9/src/hotspot/share/memory/heapInspection.hpp#L218 > > It probably happens to work at other places because of preceding includes that happen to satisfy this. Explicitly including it here makes sense for that reason. Not sure why it just started showing up, but likely a new use that didn't otherwise satisfy this include. I forgot to circle back on this, but there are files that I created that includes `heapInspection.hpp`. I get an incomplete type for the Mutex class if I don't include `mutex.hpp`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2320521485 From dlong at openjdk.org Thu Sep 4 00:31:42 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 4 Sep 2025 00:31:42 GMT Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3] In-Reply-To: References: <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com> Message-ID: On Wed, 3 Sep 2025 07:12:20 GMT, Manuel H?ssig wrote: >> Dean Long has updated the pull request incrementally with three additional commits since the last revision: >> >> - revert whitespace change >> - undo debug changes >> - cleanup > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64Frame.java line 372: > >> 370: // DEBUG_ONLY(verifyDeoptriginalPc(senderNm, raw_unextendedSp)); >> 371: } >> 372: } > > `Frame.java adjustUnextendedSP()` do not seem to do anything? Perhaps these could be cleaned up as well? Yes, it's tempting to want to clean these up, but I noticed that SA code really tries to mirror the C++ code, so I'm inclined to leave it. Is there a Serviceability expert that would like to see this code cleaned up further? @plummercj , what do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2320526360 From dholmes at openjdk.org Thu Sep 4 00:43:41 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 4 Sep 2025 00:43:41 GMT Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns InstanceKlass* [v3] In-Reply-To: References: Message-ID: <38qyt72puP7IM-UHRTFW8PF17T1V-w3gHMRDkkNF1NY=.40073263-bf18-4726-9101-9710868e20d7@github.com> On Tue, 2 Sep 2025 21:08:25 GMT, Ioi Lam wrote: >> By adding an `InstanceKlass* InstanceKlass::super()` method to shadow `Klass* Klass:super()`, this PR makes it possible to simplify the following code >> >> >> InstanceKlass* ik; >> InstanceKlass* s; >> s = InstanceKlass::cast(ik->super()); // before JDK-8366024 >> s = ik->java_super(); // after JDK-8366024 >> >> >> to >> >> >> s = k->super(); >> >> >> So you no longer need to do casting or need to understand what `java_super()` is. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @dholmes-ora and @coleep comments Updates look good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27037#pullrequestreview-3182970156 From dholmes at openjdk.org Thu Sep 4 00:57:48 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 4 Sep 2025 00:57:48 GMT Subject: RFR: 8277444: Data race between JvmtiClassFileReconstituter::copy_bytecodes and class linking [v5] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 21:45:03 GMT, Evgeny Astigeevich wrote: >> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. >> >> This PR adds linking a class before the `copy_bytecodes` method is called. >> The PR also adds a regression test. >> >> Tested fastdebug and release builds: Linux x86_64 and arm64 >> - The reproducer from JDK-8277444 passed. >> - The regression test passed. >> - Tier1 - tier3 passed. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Switch to macros HAS_PENDING_EXCEPTION, CLEAR_PENDING_EXCEPTION Generally looks good. There are a few minor nits/typos. I'm not sure about the test, in particular the attempt to calculate `MIN_LINK_TIME_MS`. It is very hard to see/know that you will actually induce the desired race. But as the test doesn't actually have any explicit failure conditions, it at least won't generate false reports. Thanks src/hotspot/share/prims/jvmtiEnv.cpp line 454: > 452: if (ik->get_cached_class_file_bytes() == nullptr) { > 453: // Link the class to avoid races with the rewriter. This will call the verifier also > 454: // on the class. Linking is done already below in VM_RedefineClasses below, but we need Suggestion: // on the class. Linking is also done in VM_RedefineClasses below, but we need There are two "below"s test/jdk/java/lang/instrument/RetransformBigClassTest.java line 44: > 42: * in another thread. The test uses Class.forName("BigClass", false, classLoader) > 43: * which does not link the class. When the class is used, the linking process starts. > 44: * In another thread retransforming of the class is happening, Suggestion: * In another thread retransforming of the class is happening. test/jdk/java/lang/instrument/RetransformBigClassTest.java line 45: > 43: * which does not link the class. When the class is used, the linking process starts. > 44: * In another thread retransforming of the class is happening, > 45: * We generate a class with big methods. A number of methods and thier size are Suggestion: * We generate a class with big methods. A number of methods and their size are test/jdk/java/lang/instrument/RetransformBigClassTest.java line 46: > 44: * In another thread retransforming of the class is happening, > 45: * We generate a class with big methods. A number of methods and thier size are > 46: * chosen to make the linking and retransforming processes running concurrently. Suggestion: * chosen to make the linking and retransforming processes run concurrently. test/jdk/java/lang/instrument/RetransformBigClassTest.java line 54: > 52: private static final Object LOCK = new Object(); > 53: private static final int COUNTER_INC_COUNT = 2000; // A number of 'c+=1;' statements in methods of a class. > 54: private static final int MIN_LINK_TIME_MS = 60; // This time is chosen to be big enough the linking and retransforming processes are running in parallel. Suggestion: private static final int MIN_LINK_TIME_MS = 60; // Large enough so linking and retransforming run in parallel. test/jdk/java/lang/instrument/RetransformBigClassTest.java line 108: > 106: } > 107: > 108: // We calculate a number of methods the linking time to exceed MIN_LINK_TIME_MS. I can't quite parse this sentence. ------------- PR Review: https://git.openjdk.org/jdk/pull/26863#pullrequestreview-3182975103 PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2320540581 PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2320542950 PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2320543345 PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2320543595 PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2320544630 PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2320546835 From asmehra at openjdk.org Thu Sep 4 01:50:50 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Thu, 4 Sep 2025 01:50:50 GMT Subject: RFR: 8366475: Rename MetaspaceShared class to AOTMetaspace [v3] In-Reply-To: References: Message-ID: On Sat, 30 Aug 2025 18:17:42 GMT, Ioi Lam wrote: >> This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology): >> >> Rename this class to with a naming convention that's consistent with other new AOT classes such as AOTClassLinker. >> >> All changes are mechanical text replacement. Headers are resorted alphabetically. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > removed unnecessary includes src/hotspot/os/posix/vmError_posix.cpp line 27: > 25: > 26: #include "cds/cdsConfig.hpp" > 27: #include "cds/aotMetaspace.hpp" There are few places, like this, where the header files are no longer in sorted order. Can you please update them. src/hotspot/os/windows/vmError_windows.cpp line 26: > 24: > 25: #include "cds/cdsConfig.hpp" > 26: #include "cds/aotMetaspace.hpp" header files are not sorted src/hotspot/share/prims/jvm.cpp line 3507: > 3505: Handle file_handle(THREAD, JNIHandles::resolve_non_null(listFileName)); > 3506: char* file_name = java_lang_String::as_utf8_string(file_handle()); > 3507: AOTMetaspace::dump_loaded_classes(file_name, THREAD); Shouldn't this file include `aotMetaspace.hpp` directly? src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 26: > 24: > 25: #include "cds/cdsConfig.hpp" > 26: #include "cds/aotMetaspace.hpp" headers are not sorted src/hotspot/share/prims/whitebox.cpp line 30: > 28: #include "cds/filemap.hpp" > 29: #include "cds/heapShared.hpp" > 30: #include "cds/aotMetaspace.hpp" header files are not sorted src/hotspot/share/runtime/java.cpp line 451: > 449: > 450: if (CDSConfig::is_dumping_preimage_static_archive()) { > 451: AOTMetaspace::preload_and_dump(thread); Shouldn't this file include `aotMetaspace.hpp` directly? src/hotspot/share/runtime/threads.cpp line 31: > 29: #include "cds/cdsConfig.hpp" > 30: #include "cds/heapShared.hpp" > 31: #include "cds/aotMetaspace.hpp" header files are not sorted ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320608881 PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320608974 PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320609474 PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320609545 PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320609580 PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320609638 PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320609704 From ysr at openjdk.org Thu Sep 4 01:58:47 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 4 Sep 2025 01:58:47 GMT Subject: RFR: 8366122: Shenandoah: Implement efficient support for object count after gc events [v2] In-Reply-To: References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com> <_7YHL1mTJBL7b_EgdhbFJZ2hIFiOD0Tjqy0APNy-h2g=.16b48215-3ac0-4964-9ce2-e8ee475109b3@github.com> Message-ID: On Thu, 4 Sep 2025 00:24:37 GMT, pf0n wrote: >> I believe you need it for this: https://github.com/pf0n/jdk/blob/f43e334bf76f878ec688cbd58a5ab1cb10deb0f9/src/hotspot/share/memory/heapInspection.hpp#L218 >> >> It probably happens to work at other places because of preceding includes that happen to satisfy this. Explicitly including it here makes sense for that reason. Not sure why it just started showing up, but likely a new use that didn't otherwise satisfy this include. > > I forgot to circle back on this, but there are files that I created that includes `heapInspection.hpp`. I get an incomplete type for the Mutex class if I don't include `mutex.hpp`. Makes sense. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2320618033 From ysr at openjdk.org Thu Sep 4 02:07:52 2025 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 4 Sep 2025 02:07:52 GMT Subject: RFR: 8366122: Shenandoah: Implement efficient support for object count after gc events [v2] In-Reply-To: References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com> Message-ID: On Wed, 3 Sep 2025 01:41:15 GMT, pf0n wrote: >> test/jdk/jdk/jfr/event/gc/objectcount/TestObjectCountAfterGCEventWithShenandoah.java line 11: >> >>> 9: * & vm.opt.ExplicitGCInvokesConcurrent != true >>> 10: * @library /test/lib /test/jdk >>> 11: * @run main/othervm -XX:+UnlockExperimentalVMOptions -XX:-UseFastUnorderedTimeStamps -XX:+UseShenandoahGC -XX:MarkSweepDeadRatio=0 -XX:-UseCompressedOops -XX:-UseCompressedClassPointers -XX:+IgnoreUnrecognizedVMOptions jdk.jfr.event.gc.objectcount.TestObjectCountAfterGCEventWithShenandoah >> >> Are all of these flags necessary to run this test? Can we pare any unnecessary options? > > All of the collectors that test for the ObjectCountAfterGC event uses these flags. I thought it would be best to keep it consistent for the Shenandoah test. Best practice is to remove flags that are no-ops, otherwise we accrue junk here. I'd urge removal of such cruft, in particular: MarkSweepDeadRatio, UseCompressedOops & UseCompressedClassPointers (which you may have added for debugging ease), and IgnoreUnrecognizedVMOptions (which should, I think, not be there in any tests unless there is an explicitly stated reason to include it). I am not sure we even need UseFastUnorderedTimeStamps either since the test does not, to my knowledge, examine the order of timestamped events in the JFR recording. If further constraint checking is added to the tests that requires this, it should be added back at that time. For the other collectors, we can consider a separate ticket to clean any unnecessary flags up (I suspect only MarkSweepDeadRatio may be needed for the cases where one is looking for a collection to necessarily move objects-- which I don't think these tests test for -- so even that flag appears unnecessary at least for these tests.) I vote for unburdening the flag load for the new Shenandoah test at least, as suggested by William. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26977#discussion_r2320627227 From liach at openjdk.org Thu Sep 4 02:19:47 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 4 Sep 2025 02:19:47 GMT Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to MetaspaceObj::in_aot_cache() [v2] In-Reply-To: References: Message-ID: <6zhlR-iAP-D-47ELJS2xd_eHm1De2raHknG1h9JibgY=.d6fc1d4e-8e54-4560-a9f4-70102fc432d3@github.com> On Sat, 30 Aug 2025 17:34:38 GMT, Ioi Lam wrote: >> This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology): >> >> Rename `is_shared()` in `Metaspace` (and various other classes) to `in_aot_cache()` to reflect its true meaning: >> - tests if an object is inside the AOT cache's metaspace region. >> >> Also various forms of "shared metaspace" are updated to "aot metaspace" >> >> Please start your review with allocations.hpp > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Removed MetaspaceShared -> AOTMetaspace changes that are intended for https://github.com/openjdk/jdk/pull/27017 This rename is absolutely clarifying. Did not review the technical aspects of hotspot. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27016#pullrequestreview-3183181361 From iklam at openjdk.org Thu Sep 4 02:33:52 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 4 Sep 2025 02:33:52 GMT Subject: RFR: 8366584: Add an InstanceKlass::super() method that returns InstanceKlass* [v3] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 11:38:49 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @dholmes-ora and @coleep comments > > Looks good. This will help with InstanceKlass casting. Thanks @coleenp @dholmes-ora for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/27037#issuecomment-3251513937 From iklam at openjdk.org Thu Sep 4 02:33:52 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 4 Sep 2025 02:33:52 GMT Subject: Integrated: 8366584: Add an InstanceKlass::super() method that returns InstanceKlass* In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 01:31:59 GMT, Ioi Lam wrote: > By adding an `InstanceKlass* InstanceKlass::super()` method to shadow `Klass* Klass:super()`, this PR makes it possible to simplify the following code > > > InstanceKlass* ik; > InstanceKlass* s; > s = InstanceKlass::cast(ik->super()); // before JDK-8366024 > s = ik->java_super(); // after JDK-8366024 > > > to > > > s = k->super(); > > > So you no longer need to do casting or need to understand what `java_super()` is. This pull request has now been integrated. Changeset: f4d73d2a Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/f4d73d2a3dbeccfd04d49c0cfd690086edd0544f Stats: 93 lines in 28 files changed: 9 ins; 3 del; 81 mod 8366584: Add an InstanceKlass::super() method that returns InstanceKlass* Reviewed-by: dholmes, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/27037 From dholmes at openjdk.org Thu Sep 4 02:35:49 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 4 Sep 2025 02:35:49 GMT Subject: RFR: 8365190: Remove LockingMode related code from share In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> Message-ID: On Tue, 2 Sep 2025 08:24:10 GMT, Fredrik Bredberg wrote: > Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR). > > This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself. > > Passes tier1-tier5 with no added problems. Looks good. Great cleanup! A couple of nits/suggestions. Thanks src/hotspot/share/c1/c1_LIRGenerator.cpp line 638: > 636: LIR_Opr hdr = lock; > 637: lock = new_hdr; > 638: CodeStub* slow_path = new MonitorExitStub(lock, true, monitor_no); It seems all creators for `MonitorExitStub` now pass `true` so that parameter can be removed. src/hotspot/share/runtime/basicLock.hpp line 40: > 38: // Used as a cache of the ObjectMonitor* used when locking. Must either > 39: // be nullptr or the ObjectMonitor* used when locking. > 40: volatile uintptr_t _metadata; So this could now be a properly typed and named field. Future RFE. src/hotspot/share/runtime/basicLock.hpp line 53: > 51: static int displaced_header_offset_in_bytes() { return metadata_offset_in_bytes(); } > 52: > 53: // For lightweight locking If the following are for lightweight locking then what are the two previous for? ------------- PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3179255959 PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2317998409 PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2320634417 PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2320643671 From dholmes at openjdk.org Thu Sep 4 02:35:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 4 Sep 2025 02:35:51 GMT Subject: RFR: 8365190: Remove LockingMode related code from share In-Reply-To: References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> Message-ID: On Tue, 2 Sep 2025 20:15:51 GMT, Coleen Phillimore wrote: >> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR). >> >> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself. >> >> Passes tier1-tier5 with no added problems. > > src/hotspot/share/runtime/basicLock.hpp line 51: > >> 49: void set_bad_metadata_deopt() { set_metadata(badDispHeaderDeopt); } >> 50: >> 51: static int displaced_header_offset_in_bytes() { return metadata_offset_in_bytes(); } > > Also delete line 51 ? Still appears used in LIRAssembler. But the assert in which it is used doesn't really make sense as it just checks the offset == 0. > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 769: > >> 767: >> 768: // LightweightSynchronizer::inflate_locked_or_imse is used to to get an inflated >> 769: // ObjectMonitor* when lightweight locking is used. It is used from contexts > > I guess you don't need the phrase "when lightweight locking is used". Even calling it "lightweight locking" is no longer needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2320640694 PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2320651595 From iklam at openjdk.org Thu Sep 4 03:06:29 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 4 Sep 2025 03:06:29 GMT Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to MetaspaceObj::in_aot_cache() [v3] In-Reply-To: References: Message-ID: > This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology): > > Rename `is_shared()` in `Metaspace` (and various other classes) to `in_aot_cache()` to reflect its true meaning: > - tests if an object is inside the AOT cache's metaspace region. > > Also various forms of "shared metaspace" are updated to "aot metaspace" > > Please start your review with allocations.hpp Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Also renamed ConstantPool::is_shared() because it shadows MetaspaceObj::is_shared() - Merge branch 'master' into 8366474-rename_metaspaceobj_is_shared_to_in_aot_cache - Removed MetaspaceShared -> AOTMetaspace changes that are intended for https://github.com/openjdk/jdk/pull/27017 - 8366474: Rename MetaspaceObj::is_shared() to MetaspaceObj::in_aot_cache() ------------- Changes: https://git.openjdk.org/jdk/pull/27016/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27016&range=02 Stats: 204 lines in 55 files changed: 3 ins; 0 del; 201 mod Patch: https://git.openjdk.org/jdk/pull/27016.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27016/head:pull/27016 PR: https://git.openjdk.org/jdk/pull/27016 From iklam at openjdk.org Thu Sep 4 03:06:29 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 4 Sep 2025 03:06:29 GMT Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to MetaspaceObj::in_aot_cache() [v2] In-Reply-To: References: Message-ID: On Sat, 30 Aug 2025 17:34:38 GMT, Ioi Lam wrote: >> This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology): >> >> Rename `is_shared()` in `Metaspace` (and various other classes) to `in_aot_cache()` to reflect its true meaning: >> - tests if an object is inside the AOT cache's metaspace region. >> >> Also various forms of "shared metaspace" are updated to "aot metaspace" >> >> Please start your review with allocations.hpp > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Removed MetaspaceShared -> AOTMetaspace changes that are intended for https://github.com/openjdk/jdk/pull/27017 I've merged with the mainline to resolve conflicts. I also made one extra fix: `ConstantPool::is_shared()` was shadowing `MetaspaceObj::is_shared()`, so I renamed it to `in_aot_cache()`, so that it will now shadow `MetaspaceObj::in_aot_cache()`. See [17f8c0b](https://github.com/openjdk/jdk/pull/27016/commits/17f8c0bfe302504cd027435fa92cdc58f3362f7c) @vnkozlov @liach could you re-review? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27016#issuecomment-3251598867 From asmehra at openjdk.org Thu Sep 4 03:14:42 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Thu, 4 Sep 2025 03:14:42 GMT Subject: RFR: 8366477: Refactor AOT-related flag bits in klass.hpp [v2] In-Reply-To: References: Message-ID: <_A85cHVnrlEWRJr9wSJ46gnVPYbFUCM1GzxNO-vlFiU=.a394197e-64dc-4dae-9480-c0336bc52ff0@github.com> On Sat, 30 Aug 2025 18:20:15 GMT, Ioi Lam wrote: >> This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology): >> >> 1. Rename from `Klass::_shared_class_flags` to `Klass::_aot_class_flags` >> 2. Move `_has_aot_safe_initializer` and `_is_runtime_setup_required` from `InstanceKlassFlags` (has run out of bits) to here (we still have 7 extra bits left), to accommodate future `@AOTXXX` annotations. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch '8366475-rename-metaspace-shared-to-aot-metaspace' into 8366477-refactor-aot-related-flag-bits-in-klass-hpp > - 8366477: Refactor AOT-related flag bits in klass.hpp src/hotspot/share/oops/klass.hpp line 184: > 182: _verified_at_dump_time = 1 << 3, > 183: _has_archived_enum_objs = 1 << 4, > 184: _is_generated_shared_class = 1 << 5, // This class was not loaded from a classfile in the module image does it make sense to rename `_is_generated_shared_class` to `_is_generated_aot_class`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27018#discussion_r2320699977 From liach at openjdk.org Thu Sep 4 03:30:43 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 4 Sep 2025 03:30:43 GMT Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to MetaspaceObj::in_aot_cache() [v3] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 03:06:29 GMT, Ioi Lam wrote: >> This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology): >> >> Rename `is_shared()` in `Metaspace` (and various other classes) to `in_aot_cache()` to reflect its true meaning: >> - tests if an object is inside the AOT cache's metaspace region. >> >> Also various forms of "shared metaspace" are updated to "aot metaspace" >> >> Please start your review with allocations.hpp > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Also renamed ConstantPool::is_shared() because it shadows MetaspaceObj::is_shared() > - Merge branch 'master' into 8366474-rename_metaspaceobj_is_shared_to_in_aot_cache > - Removed MetaspaceShared -> AOTMetaspace changes that are intended for https://github.com/openjdk/jdk/pull/27017 > - 8366474: Rename MetaspaceObj::is_shared() to MetaspaceObj::in_aot_cache() The subsequent fix looks good. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27016#pullrequestreview-3183291587 From liach at openjdk.org Thu Sep 4 03:31:44 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 4 Sep 2025 03:31:44 GMT Subject: RFR: 8366477: Refactor AOT-related flag bits in klass.hpp [v2] In-Reply-To: <_A85cHVnrlEWRJr9wSJ46gnVPYbFUCM1GzxNO-vlFiU=.a394197e-64dc-4dae-9480-c0336bc52ff0@github.com> References: <_A85cHVnrlEWRJr9wSJ46gnVPYbFUCM1GzxNO-vlFiU=.a394197e-64dc-4dae-9480-c0336bc52ff0@github.com> Message-ID: On Thu, 4 Sep 2025 03:11:49 GMT, Ashutosh Mehra wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch '8366475-rename-metaspace-shared-to-aot-metaspace' into 8366477-refactor-aot-related-flag-bits-in-klass-hpp >> - 8366477: Refactor AOT-related flag bits in klass.hpp > > src/hotspot/share/oops/klass.hpp line 184: > >> 182: _verified_at_dump_time = 1 << 3, >> 183: _has_archived_enum_objs = 1 << 4, >> 184: _is_generated_shared_class = 1 << 5, // This class was not loaded from a classfile in the module image > > does it make sense to rename `_is_generated_shared_class` to `_is_generated_aot_class`? `_is_aot_generated_class` sounds better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27018#discussion_r2320728966 From kbarrett at openjdk.org Thu Sep 4 04:16:41 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 4 Sep 2025 04:16:41 GMT Subject: RFR: 8300080: offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant In-Reply-To: <0T5Bpw4E7qu10pWz981nWwFgNet_sas0vPi4K5v70LU=.17e8d99a-3663-47ef-874b-1349bd919229@github.com> References: <0T5Bpw4E7qu10pWz981nWwFgNet_sas0vPi4K5v70LU=.17e8d99a-3663-47ef-874b-1349bd919229@github.com> Message-ID: <2-sUpiqfS7H0MswkaAYbTBw9Q3AAx-uVYgVx4-wE2i8=.4b7ac42f-1062-4c57-a1ae-d6418faac87e@github.com> On Wed, 3 Sep 2025 07:28:49 GMT, Stefan Karlsson wrote: >> Please review this change to offset_of to just use offsetof as it's >> implementation. The rationale for this is >> >> (1) Despite being UB for some cases that we use (through C++14), none of the >> compilers we use actually treat it as such, other than some compilers issuing >> warnings. (Surprisingly, the UB doesn't appear to disable constexpr evaluation?) >> >> (2) C++17 changed it to be conditionally defined in those formerly UB cases, >> and we'll be switching over to C++17 soon (JDK-8314488). >> >> Until we make the switch to C++17 we need to suppress warnings from some >> compilers for such uses. We can remove that warning suppression later. >> >> See the JBS issue for more discussion. >> >> Testing: mach5 tier1 > > Nice. Is it worth pushing this so near the transition to compile with C++17 support? Thanks for reviews @stefank and @jdksjolen ------------- PR Comment: https://git.openjdk.org/jdk/pull/27061#issuecomment-3251764296 From dholmes at openjdk.org Thu Sep 4 04:46:42 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 4 Sep 2025 04:46:42 GMT Subject: RFR: 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown [v2] In-Reply-To: References: <3TJnBvDoAPUf4p2e8Y0vpckfm3v8e31cKKwfOeyRnnM=.34c016f4-419d-4dd6-9102-b112a7423f7b@github.com> <9MccMrhJLB1DC6NP_9aYvnC9EhwqW_iko5Cxdbfxn_k=.4e1db66e-3ffb-4162-a3de-d17169212159@github.com> Message-ID: <4jaNlfISY0c8AJMnrelSe-4B1AaLMfT3ofZ4crAx6YA=.55ecc532-e3d5-4425-b96b-341e38ef059d@github.com> On Wed, 3 Sep 2025 19:46:18 GMT, Kim Barrett wrote: > > I still am not sure how the OrderAccess helps. A concurrent thread can see xtty != null and start printing while the terminating thread deletes the defaultStream under xtty? Sorry if I am slow. > > I agree with @tstuefe - I'm not seeing how this actually helps. Esp. since the other side of these operations typically (universally?) doesn't have any memory ordering, and where there are null checks they are often of the form `if (global_x != nullptr) { ... use global_x ... }` As I wrote in the description: > Due to races during VM shutdown we cannot make use of xtty perfectly safe, but we can certainly narrow the window during which use-after-free is possible. we have a blatant `free x; x = null` sequence which is wrong. We flip it `x = null; fence; free x;` so that we reduce the chances of accessing `x` after it is null. The `fence` is used to force visibility of the nulling as well as prevent reordering with the freeing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26832#issuecomment-3251825291 From iklam at openjdk.org Thu Sep 4 04:50:47 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 4 Sep 2025 04:50:47 GMT Subject: RFR: 8366474: Rename MetaspaceObj::is_shared() to MetaspaceObj::in_aot_cache() [v2] In-Reply-To: References: Message-ID: On Sat, 30 Aug 2025 19:45:05 GMT, Vladimir Kozlov wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed MetaspaceShared -> AOTMetaspace changes that are intended for https://github.com/openjdk/jdk/pull/27017 > > Update is good. Thanks @vnkozlov @liach for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/27016#issuecomment-3251834527 From iklam at openjdk.org Thu Sep 4 04:50:48 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 4 Sep 2025 04:50:48 GMT Subject: Integrated: 8366474: Rename MetaspaceObj::is_shared() to MetaspaceObj::in_aot_cache() In-Reply-To: References: Message-ID: On Sat, 30 Aug 2025 02:13:20 GMT, Ioi Lam wrote: > This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology): > > Rename `is_shared()` in `Metaspace` (and various other classes) to `in_aot_cache()` to reflect its true meaning: > - tests if an object is inside the AOT cache's metaspace region. > > Also various forms of "shared metaspace" are updated to "aot metaspace" > > Please start your review with allocations.hpp This pull request has now been integrated. Changeset: 90a2db1e Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/90a2db1ecbc3ea25a8e9f15b34a3d8f3941b60d0 Stats: 204 lines in 55 files changed: 3 ins; 0 del; 201 mod 8366474: Rename MetaspaceObj::is_shared() to MetaspaceObj::in_aot_cache() Reviewed-by: liach, kvn ------------- PR: https://git.openjdk.org/jdk/pull/27016 From iklam at openjdk.org Thu Sep 4 05:38:20 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 4 Sep 2025 05:38:20 GMT Subject: RFR: 8366475: Rename MetaspaceShared class to AOTMetaspace [v4] In-Reply-To: References: Message-ID: <-8Bu8-ZieMNwrkkdkjjwqkdSi8Dv9gp3THbl_rRBHS4=.b95bd18e-11ae-46a0-8b0b-2ecb2aa4c34a@github.com> > This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology): > > Rename this class to with a naming convention that's consistent with other new AOT classes such as AOTClassLinker. > > All changes are mechanical text replacement. Headers are resorted alphabetically. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Fixed include order - Merge branch 'master' into 8366475-rename-metaspace-shared-to-aot-metaspace - Merge branch '8366474-rename_metaspaceobj_is_shared_to_in_aot_cache' into 8366475-rename-metaspace-shared-to-aot-metaspace - Also renamed ConstantPool::is_shared() because it shadows MetaspaceObj::is_shared() - Merge branch 'master' into 8366474-rename_metaspaceobj_is_shared_to_in_aot_cache - removed unnecessary includes - Redo changes in comments and tests - Merge branch '8366474-rename_metaspaceobj_is_shared_to_in_aot_cache' into 8366475-rename-metaspace-shared-to-aot-metaspace - Removed MetaspaceShared -> AOTMetaspace changes that are intended for https://github.com/openjdk/jdk/pull/27017 - Rename MetaspaceShared -> AOTMetaspace - ... and 1 more: https://git.openjdk.org/jdk/compare/90a2db1e...63073feb ------------- Changes: https://git.openjdk.org/jdk/pull/27017/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27017&range=03 Stats: 367 lines in 60 files changed: 35 ins; 35 del; 297 mod Patch: https://git.openjdk.org/jdk/pull/27017.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27017/head:pull/27017 PR: https://git.openjdk.org/jdk/pull/27017 From iklam at openjdk.org Thu Sep 4 05:38:21 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 4 Sep 2025 05:38:21 GMT Subject: RFR: 8366475: Rename MetaspaceShared class to AOTMetaspace [v3] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 01:47:23 GMT, Ashutosh Mehra wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> removed unnecessary includes > > src/hotspot/os/posix/vmError_posix.cpp line 27: > >> 25: >> 26: #include "cds/cdsConfig.hpp" >> 27: #include "cds/aotMetaspace.hpp" > > There are few places, like this, where the header files are no longer in sorted order. Can you please update them. Fixed. > src/hotspot/os/windows/vmError_windows.cpp line 26: > >> 24: >> 25: #include "cds/cdsConfig.hpp" >> 26: #include "cds/aotMetaspace.hpp" > > header files are not sorted Fixed. > src/hotspot/share/prims/jvm.cpp line 3507: > >> 3505: Handle file_handle(THREAD, JNIHandles::resolve_non_null(listFileName)); >> 3506: char* file_name = java_lang_String::as_utf8_string(file_handle()); >> 3507: AOTMetaspace::dump_loaded_classes(file_name, THREAD); > > Shouldn't this file include `aotMetaspace.hpp` directly? Fixed. > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 26: > >> 24: >> 25: #include "cds/cdsConfig.hpp" >> 26: #include "cds/aotMetaspace.hpp" > > headers are not sorted Fixed. > src/hotspot/share/prims/whitebox.cpp line 30: > >> 28: #include "cds/filemap.hpp" >> 29: #include "cds/heapShared.hpp" >> 30: #include "cds/aotMetaspace.hpp" > > header files are not sorted Fixed. > src/hotspot/share/runtime/java.cpp line 451: > >> 449: >> 450: if (CDSConfig::is_dumping_preimage_static_archive()) { >> 451: AOTMetaspace::preload_and_dump(thread); > > Shouldn't this file include `aotMetaspace.hpp` directly? Fixed. > src/hotspot/share/runtime/threads.cpp line 31: > >> 29: #include "cds/cdsConfig.hpp" >> 30: #include "cds/heapShared.hpp" >> 31: #include "cds/aotMetaspace.hpp" > > header files are not sorted Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320880870 PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320880937 PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320880998 PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320881088 PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320881141 PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320881190 PR Review Comment: https://git.openjdk.org/jdk/pull/27017#discussion_r2320881262 From kbarrett at openjdk.org Thu Sep 4 05:44:51 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 4 Sep 2025 05:44:51 GMT Subject: Integrated: 8300080: offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant In-Reply-To: References: Message-ID: <76UmBZC8eEs0mB-JJcx7A5czIEMe7KJ66xM8UicPmuA=.4f5d7000-2ce8-4bfe-bc06-126fc01dadea@github.com> On Tue, 2 Sep 2025 23:25:43 GMT, Kim Barrett wrote: > Please review this change to offset_of to just use offsetof as it's > implementation. The rationale for this is > > (1) Despite being UB for some cases that we use (through C++14), none of the > compilers we use actually treat it as such, other than some compilers issuing > warnings. (Surprisingly, the UB doesn't appear to disable constexpr evaluation?) > > (2) C++17 changed it to be conditionally defined in those formerly UB cases, > and we'll be switching over to C++17 soon (JDK-8314488). > > Until we make the switch to C++17 we need to suppress warnings from some > compilers for such uses. We can remove that warning suppression later. > > See the JBS issue for more discussion. > > Testing: mach5 tier1 This pull request has now been integrated. Changeset: 62bc7b7c Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/62bc7b7c4247a62c23ea93cd960c3c0434925c49 Stats: 26 lines in 4 files changed: 5 ins; 20 del; 1 mod 8300080: offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant Reviewed-by: stefank, jsjolen ------------- PR: https://git.openjdk.org/jdk/pull/27061 From iwalulya at openjdk.org Thu Sep 4 06:08:44 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 4 Sep 2025 06:08:44 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 [v4] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 23:31:03 GMT, Kim Barrett wrote: >> Please review this change to use C++17 for building C++ parts of the JDK. In >> particular this affects HotSpot. This change also includes an update to the >> HotSpot Style Guide regarding C++17 features and their use in HotSpot code. >> >> Testing: mach5 tier1-8 >> >> This change includes a modification of the Style Guide. Rough consensus among >> the HotSpot Group members is required to make such a change. Only Group >> members should vote for approval (via the github PR), though reasoned >> objections or comments from anyone will be considered. A decision on this >> proposal will not be made before Friday 5-September-2025 at 12h00 UTC. >> >> Since we're piggybacking on github PRs here, please use the PR review process >> to approve (click on Review Changes > Approve), rather than sending a "vote: >> yes" email reply that would be normal for a CFV. > > Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: > > - missing word > - stefank suggestions Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26884#pullrequestreview-3183573272 From sjohanss at openjdk.org Thu Sep 4 06:36:50 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Thu, 4 Sep 2025 06:36:50 GMT Subject: RFR: 8366434: THP not working properly with G1 after JDK-8345655 In-Reply-To: <7omR7oA7xV-EybyZzMUBm1KismDS8zcmAiUz14WQK6g=.b822cecd-f75b-449f-b0ee-4051dd12b504@github.com> References: <7omR7oA7xV-EybyZzMUBm1KismDS8zcmAiUz14WQK6g=.b822cecd-f75b-449f-b0ee-4051dd12b504@github.com> Message-ID: On Wed, 3 Sep 2025 08:51:38 GMT, Aleksey Shipilev wrote: >> Please review this fix to enable transparent huge pages for G1, >> >> **Summary** >> In [JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655) we refactored the memory reservation code to be more maintainable and easier to follow. When doing this one of the code paths changed to always pass in `os::vm_page_size()` where it previously had used a page size provided by the caller. >> >> Even if the alignment for `ReservedSpaces` created this way show that they should be aligned to support large pages the page size member for the `ReservedSpace` does not convey that we want large pages for the space. In G1 when using `G1PageBaseVirtualSpace` we use the above mentioned page size as the alignment for the reservation. This leads to reservations (made using the API) not being THP eligible even if `-XX:+UseTransparentHugePages` is specified. >> >> This is only an issue when the system is configured with the THP mode `madvise`. If the mode is `always`, we will get THP eligible reservations. So a fairly simple workaround for this issue (given you have access to configuring your system) is to configure the THP mode to always. >> >> The fix is to simply change back to the old behavior and pass in the user provided page size to the `ReservedSpace`. We've also added a test that verifies that we try to back the heap with transparent huge pages when `-XX:+UseTransparentHugePages` is specified on the command-line. >> >> **Testing** >> * Mach5 testing tier1-tier5 >> * Manual testing of the new test both locally and on mach5. Making sure it has been executed on system with both `madvise` and `always` configured. Also made sure the test actually failed without the fix. > > Marked as reviewed by shade (Reviewer). Thanks for the reviews @shipilev and @stefank ------------- PR Comment: https://git.openjdk.org/jdk/pull/27051#issuecomment-3252130640 From sjohanss at openjdk.org Thu Sep 4 06:36:51 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Thu, 4 Sep 2025 06:36:51 GMT Subject: Integrated: 8366434: THP not working properly with G1 after JDK-8345655 In-Reply-To: References: Message-ID: <5abMvmPT4wYiB6VTYxeCft46vG8thD0Rtn9QLbKA19o=.3e8f817d-5289-4ff3-94ba-add2b6e52e6e@github.com> On Tue, 2 Sep 2025 13:53:13 GMT, Stefan Johansson wrote: > Please review this fix to enable transparent huge pages for G1, > > **Summary** > In [JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655) we refactored the memory reservation code to be more maintainable and easier to follow. When doing this one of the code paths changed to always pass in `os::vm_page_size()` where it previously had used a page size provided by the caller. > > Even if the alignment for `ReservedSpaces` created this way show that they should be aligned to support large pages the page size member for the `ReservedSpace` does not convey that we want large pages for the space. In G1 when using `G1PageBaseVirtualSpace` we use the above mentioned page size as the alignment for the reservation. This leads to reservations (made using the API) not being THP eligible even if `-XX:+UseTransparentHugePages` is specified. > > This is only an issue when the system is configured with the THP mode `madvise`. If the mode is `always`, we will get THP eligible reservations. So a fairly simple workaround for this issue (given you have access to configuring your system) is to configure the THP mode to always. > > The fix is to simply change back to the old behavior and pass in the user provided page size to the `ReservedSpace`. We've also added a test that verifies that we try to back the heap with transparent huge pages when `-XX:+UseTransparentHugePages` is specified on the command-line. > > **Testing** > * Mach5 testing tier1-tier5 > * Manual testing of the new test both locally and on mach5. Making sure it has been executed on system with both `madvise` and `always` configured. Also made sure the test actually failed without the fix. This pull request has now been integrated. Changeset: a03302d4 Author: Stefan Johansson URL: https://git.openjdk.org/jdk/commit/a03302d41bb9971736d4d56381ca0cad1eb3e34b Stats: 156 lines in 3 files changed: 154 ins; 0 del; 2 mod 8366434: THP not working properly with G1 after JDK-8345655 Co-authored-by: Stefan Karlsson Co-authored-by: Stefan Johansson Reviewed-by: stefank, shade ------------- PR: https://git.openjdk.org/jdk/pull/27051 From dholmes at openjdk.org Thu Sep 4 06:39:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 4 Sep 2025 06:39:51 GMT Subject: RFR: 8365937: post_method_exit might incorrectly set was_popped_by_exception and value in the middle of stack unwinding [v4] In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 19:11:04 GMT, Leonid Mesnik wrote: >> The void `JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame current_frame) `calculates >> `bool exception_exit = state->is_exception_detected() && !state->is_exception_caught();` >> to find if method exit normally or by exception. >> However, JvmtiExport::post_method_exit( method is not called at all in the case of exception. See >> `void JvmtiExport::notice_unwind_due_to_exception(JavaThread *thread, Method* method, address location, oop exception, bool in_handler_frame)` >> where post_method_exit_inner is called directly. >> >> The `exception_exit` is true when exception is processed and the current method is called in the middle of stack unwinding. >> >> >> The fix was a part of >> https://github.com/openjdk/jdk/pull/26713 >> for >> https://bugs.openjdk.org/browse/JDK-8365192 > > Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: > > - Apply suggestions from code review > > Co-authored-by: Patricio Chilano Mateo > - Update test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp > > Co-authored-by: Patricio Chilano Mateo Okay with me. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26886#pullrequestreview-3183671829 From duke at openjdk.org Thu Sep 4 06:40:45 2025 From: duke at openjdk.org (duke) Date: Thu, 4 Sep 2025 06:40:45 GMT Subject: RFR: 8366778: Sort share/asm, share/gc, share/include includes In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 09:35:24 GMT, Francesco Andreuzzi wrote: > Sort includes in `share/gc`, `share/asm`, `share/include` using `SortIncludes.java`, and remove some unnecessary ones. These are the last missing modules in `hotspot/share`. > > Passes `tier1`. @fandreuz Your change (at version d4eaae2d60da111630642b0b75927c6ad7d55d4f) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27067#issuecomment-3252143814 From dholmes at openjdk.org Thu Sep 4 06:52:49 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 4 Sep 2025 06:52:49 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands [v2] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 10:08:58 GMT, Kerem Kat wrote: >> Prevents segmentation faults during `gdb` sessions. The crashes were caused by the `ResourceMark` constructor being called on a native thread, which is not supported. This happened when invoking debug commands that require a `Thread` or `JavaThread` context from an incorrect thread type. >> >> ### Solution >> >> This change introduces `onThread()` and `onJavaThread()` helper methods to the `Command` class. These methods validate the thread context and ensure `ResourceMark` is only created when on a valid VM thread. All thread-dependent debug commands now use these guards to validate the context, printing a clear error and exiting gracefully upon failure. >> >> ### Testing >> >> Manually verified using `gdb` by calling the modified commands (`ps`, `universe`, `pns`, etc.) from different thread contexts (native, Java, and non-java threads) to ensure they fail gracefully with an error message instead of crashing the debug session. > > Kerem Kat has updated the pull request incrementally with two additional commits since the last revision: > > - add include for global placement new > - remove onJavaThread and check JavaThread::active null where needed This seems okay to me. Note you need two reviews before integrating. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27033#pullrequestreview-3183706872 From stefank at openjdk.org Thu Sep 4 07:11:36 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 4 Sep 2025 07:11:36 GMT Subject: RFR: 8366854: Extend jtreg failure handler with THP info Message-ID: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> I propose that we also dump /proc/meminfo, /proc/vmstat, and /sys/kernel/mm/transparent_hugepage/{enabled, defrag} from the failure handler. This information has been helpful when investigating a failure where there was an unexpected lack of transparent huge pages. ------------- Commit messages: - 8366854: Extend jtreg failure handler with THP info Changes: https://git.openjdk.org/jdk/pull/27086/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27086&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366854 Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27086.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27086/head:pull/27086 PR: https://git.openjdk.org/jdk/pull/27086 From stefank at openjdk.org Thu Sep 4 07:11:36 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 4 Sep 2025 07:11:36 GMT Subject: RFR: 8366854: Extend jtreg failure handler with THP info In-Reply-To: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> References: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> Message-ID: On Thu, 4 Sep 2025 07:03:01 GMT, Stefan Karlsson wrote: > I propose that we also dump /proc/meminfo, /proc/vmstat, and /sys/kernel/mm/transparent_hugepage/{enabled, defrag} from the failure handler. > > This information has been helpful when investigating a failure where there was an unexpected lack of transparent huge pages. The proposed changes give the following output the environment.html file: * [proc_meminfo](file:///Users/stefank/environment.html#linux.memory.proc_meminfo) ---------------------------------------- [2025-09-02 17:03:04] [/usr/bin/bash, -c, cat /proc/meminfo] timeout=20000 in /home/stefank/git/jdk/build/fastdebug/test-support/jtreg_open_test_hotspot_jtreg_gc_g1_TestPLABOutput_java/gc/g1/TestPLABOutput ---------------------------------------- MemTotal: 64203564 kB MemFree: 28834780 kB MemAvailable: 61539920 kB Buffers: 1414464 kB Cached: 29551908 kB SwapCached: 0 kB Active: 4403292 kB Inactive: 27055328 kB Active(anon): 534448 kB Inactive(anon): 0 kB Active(file): 3868844 kB Inactive(file): 27055328 kB Unevictable: 21916 kB Mlocked: 21916 kB SwapTotal: 2097148 kB SwapFree: 2097148 kB Zswap: 0 kB Zswapped: 0 kB Dirty: 228 kB Writeback: 0 kB AnonPages: 514180 kB Mapped: 394392 kB Shmem: 30936 kB KReclaimable: 2503268 kB Slab: 3214280 kB SReclaimable: 2503268 kB SUnreclaim: 711012 kB KernelStack: 11312 kB PageTables: 11148 kB SecPageTables: 7988 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 34198928 kB Committed_AS: 2906292 kB VmallocTotal: 34359738367 kB VmallocUsed: 83464 kB VmallocChunk: 0 kB Percpu: 150336 kB HardwareCorrupted: 0 kB AnonHugePages: 88064 kB ShmemHugePages: 0 kB ShmemPmdMapped: 0 kB FileHugePages: 0 kB FilePmdMapped: 0 kB Unaccepted: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB Hugetlb: 0 kB DirectMap4k: 485000 kB DirectMap2M: 11773952 kB DirectMap1G: 54525952 kB ---------------------------------------- [2025-09-02 17:03:04] exit code: 0 time: 5 ms ---------------------------------------- * [proc_vmstat](file:///Users/stefank/environment.html#linux.memory.proc_vmstat) ---------------------------------------- [2025-09-02 17:03:04] [/usr/bin/bash, -c, cat /proc/vmstat] timeout=20000 in /home/stefank/git/jdk/build/fastdebug/test-support/jtreg_open_test_hotspot_jtreg_gc_g1_TestPLABOutput_java/gc/g1/TestPLABOutput ---------------------------------------- nr_free_pages 7208695 nr_zone_inactive_anon 0 nr_zone_active_anon 133612 nr_zone_inactive_file 6763832 nr_zone_active_file 967211 nr_zone_unevictable 5479 nr_zone_write_pending 57 nr_mlock 5479 nr_bounce 0 nr_zspages 0 nr_free_cma 0 nr_unaccepted 0 numa_hit 466716436 numa_miss 0 numa_foreign 0 numa_interleave 2079 numa_local 466714954 numa_other 0 nr_inactive_anon 0 nr_active_anon 133612 nr_inactive_file 6763832 nr_active_file 967211 nr_unevictable 5479 nr_slab_reclaimable 625817 nr_slab_unreclaimable 177753 nr_isolated_anon 0 nr_isolated_file 0 workingset_nodes 0 workingset_refault_anon 0 workingset_refault_file 0 workingset_activate_anon 0 workingset_activate_file 0 workingset_restore_anon 0 workingset_restore_file 0 workingset_nodereclaim 0 nr_anon_pages 128545 nr_mapped 98598 nr_file_pages 7741593 nr_dirty 57 nr_writeback 0 nr_writeback_temp 0 nr_shmem 7734 nr_shmem_hugepages 0 nr_shmem_pmdmapped 0 nr_file_hugepages 0 nr_file_pmdmapped 0 nr_anon_transparent_hugepages 43 nr_vmscan_write 0 nr_vmscan_immediate_reclaim 0 nr_dirtied 25991300 nr_written 22813677 nr_throttled_written 0 nr_kernel_misc_reclaimable 0 nr_foll_pin_acquired 55140 nr_foll_pin_released 55140 nr_kernel_stack 11312 nr_page_table_pages 2787 nr_sec_page_table_pages 1997 nr_iommu_pages 1997 nr_swapcached 0 pgpromote_success 0 pgpromote_candidate 0 pgdemote_kswapd 0 pgdemote_direct 0 pgdemote_khugepaged 0 nr_dirty_threshold 2964299 nr_dirty_background_threshold 1480339 nr_memmap_pages 32768 nr_memmap_boot_pages 261120 pgpgin 10093202 pgpgout 98915825 pswpin 0 pswpout 0 pgalloc_dma 1024 pgalloc_dma32 1034 pgalloc_normal 478327697 pgalloc_movable 0 pgalloc_device 0 allocstall_dma 0 allocstall_dma32 0 allocstall_normal 0 allocstall_movable 0 allocstall_device 0 pgskip_dma 0 pgskip_dma32 0 pgskip_normal 0 pgskip_movable 0 pgskip_device 0 pgfree 485576492 pgactivate 0 pgdeactivate 50 pglazyfree 52187 pgfault 490762863 pgmajfault 24328 pglazyfreed 0 pgrefill 0 pgreuse 27798266 pgsteal_kswapd 0 pgsteal_direct 0 pgsteal_khugepaged 0 pgscan_kswapd 0 pgscan_direct 0 pgscan_khugepaged 0 pgscan_direct_throttle 0 pgscan_anon 0 pgscan_file 0 pgsteal_anon 0 pgsteal_file 0 zone_reclaim_failed 0 pginodesteal 0 slabs_scanned 0 kswapd_inodesteal 0 kswapd_low_wmark_hit_quickly 0 kswapd_high_wmark_hit_quickly 0 pageoutrun 0 pgrotated 23017 drop_pagecache 0 drop_slab 0 oom_kill 0 numa_pte_updates 0 numa_huge_pte_updates 0 numa_hint_faults 0 numa_hint_faults_local 0 numa_pages_migrated 0 pgmigrate_success 0 pgmigrate_fail 0 thp_migration_success 0 thp_migration_fail 0 thp_migration_split 0 compact_migrate_scanned 0 compact_free_scanned 0 compact_isolated 0 compact_stall 0 compact_fail 0 compact_success 0 compact_daemon_wake 0 compact_daemon_migrate_scanned 0 compact_daemon_free_scanned 0 htlb_buddy_alloc_success 0 htlb_buddy_alloc_fail 0 unevictable_pgs_culled 34000 unevictable_pgs_scanned 4050 unevictable_pgs_rescued 5476 unevictable_pgs_mlocked 6905 unevictable_pgs_munlocked 1426 unevictable_pgs_cleared 0 unevictable_pgs_stranded 0 thp_fault_alloc 12586 thp_fault_fallback 0 thp_fault_fallback_charge 0 thp_collapse_alloc 241 thp_collapse_alloc_failed 0 thp_file_alloc 0 thp_file_fallback 0 thp_file_fallback_charge 0 [thp](file:///Users/stefank/environment.html#linux.memory.thp)_file_mapped 0 thp_split_page 0 thp_split_page_failed 0 thp_deferred_split_page 62 thp_split_pmd 269 thp_scan_exceed_none_pte 0 thp_scan_exceed_swap_pte 0 thp_scan_exceed_share_pte 9 thp_split_pud 0 thp_zero_page_alloc 1 thp_zero_page_alloc_failed 0 thp_swpout 0 thp_swpout_fallback 0 balloon_inflate 0 balloon_deflate 0 balloon_migrate 0 swap_ra 0 swap_ra_hit 0 ksm_swpin_copy 0 cow_ksm 0 zswpin 0 zswpout 0 zswpwb 0 direct_map_level2_splits 224 direct_map_level3_splits 8 nr_unstable 0 ---------------------------------------- [2025-09-02 17:03:04] exit code: 0 time: 4 ms ---------------------------------------- * thp ---------------------------------------- [2025-09-02 17:03:04] [/usr/bin/bash, -c, cat /sys/kernel/mm/transparent_hugepage/{enabled,defrag}] timeout=20000 in /home/stefank/git/jdk/build/fastdebug/test-support/jtreg_open_test_hotspot_jtreg_gc_g1_TestPLABOutput_java/gc/g1/TestPLABOutput ---------------------------------------- always [madvise] never always defer defer+madvise madvise [never] ---------------------------------------- [2025-09-02 17:03:04] exit code: 0 time: 5 ms ------------- PR Comment: https://git.openjdk.org/jdk/pull/27086#issuecomment-3252227582 From duke at openjdk.org Thu Sep 4 07:16:47 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Thu, 4 Sep 2025 07:16:47 GMT Subject: Integrated: 8366778: Sort share/asm, share/gc, share/include includes In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 09:35:24 GMT, Francesco Andreuzzi wrote: > Sort includes in `share/gc`, `share/asm`, `share/include` using `SortIncludes.java`, and remove some unnecessary ones. These are the last missing modules in `hotspot/share`. > > Passes `tier1`. This pull request has now been integrated. Changeset: 1495dd94 Author: Francesco Andreuzzi Committer: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/1495dd94e97fc023dede71f957ce3b166d20d5ac Stats: 40 lines in 15 files changed: 6 ins; 33 del; 1 mod 8366778: Sort share/asm, share/gc, share/include includes Reviewed-by: shade, ayang, jsikstro ------------- PR: https://git.openjdk.org/jdk/pull/27067 From sjohanss at openjdk.org Thu Sep 4 07:33:41 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Thu, 4 Sep 2025 07:33:41 GMT Subject: RFR: 8366854: Extend jtreg failure handler with THP info In-Reply-To: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> References: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> Message-ID: On Thu, 4 Sep 2025 07:03:01 GMT, Stefan Karlsson wrote: > I propose that we also dump /proc/meminfo, /proc/vmstat, and /sys/kernel/mm/transparent_hugepage/{enabled, defrag} from the failure handler. > > This information has been helpful when investigating a failure where there was an unexpected lack of transparent huge pages. Thanks for fixing this @stefank This was really helpful when we debugged a THP issue recently, so good to get it into the mainline. test/failure_handler/src/share/conf/linux.properties line 127: > 125: memory.proc_vmstat.delimiter=\0 > 126: memory.thp.app=bash > 127: memory.thp.args=-c\0cat /sys/kernel/mm/transparent_hugepage/{enabled,defrag} I think we should include `shmem_enabled` and we could use `tail` if we want to see what files have what info. But I don't have a strong feeling about that: $ cat /sys/kernel/mm/transparent_hugepage/{enabled,defrag,shmem_enabled} always [madvise] never always defer defer+madvise [madvise] never always within_size advise [never] deny force Versus: $ tail /sys/kernel/mm/transparent_hugepage/{enabled,defrag,shmem_enabled} ==> /sys/kernel/mm/transparent_hugepage/enabled <== always [madvise] never ==> /sys/kernel/mm/transparent_hugepage/defrag <== always defer defer+madvise [madvise] never ==> /sys/kernel/mm/transparent_hugepage/shmem_enabled <== always within_size advise [never] deny force ------------- Marked as reviewed by sjohanss (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27086#pullrequestreview-3183836877 PR Review Comment: https://git.openjdk.org/jdk/pull/27086#discussion_r2321120030 From stefank at openjdk.org Thu Sep 4 07:49:56 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 4 Sep 2025 07:49:56 GMT Subject: RFR: 8366854: Extend jtreg failure handler with THP info [v2] In-Reply-To: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> References: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> Message-ID: > I propose that we also dump /proc/meminfo, /proc/vmstat, and /sys/kernel/mm/transparent_hugepage/{enabled, defrag} from the failure handler. > > This information has been helpful when investigating a failure where there was an unexpected lack of transparent huge pages. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Add shmem_enabled ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27086/files - new: https://git.openjdk.org/jdk/pull/27086/files/0470c67f..d95e72a1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27086&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27086&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27086.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27086/head:pull/27086 PR: https://git.openjdk.org/jdk/pull/27086 From stefank at openjdk.org Thu Sep 4 07:49:57 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 4 Sep 2025 07:49:57 GMT Subject: RFR: 8366854: Extend jtreg failure handler with THP info [v2] In-Reply-To: References: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> Message-ID: On Thu, 4 Sep 2025 07:30:35 GMT, Stefan Johansson wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Add shmem_enabled > > test/failure_handler/src/share/conf/linux.properties line 127: > >> 125: memory.proc_vmstat.delimiter=\0 >> 126: memory.thp.app=bash >> 127: memory.thp.args=-c\0cat /sys/kernel/mm/transparent_hugepage/{enabled,defrag} > > I think we should include `shmem_enabled` and we could use `tail` if we want to see what files have what info. But I don't have a strong feeling about that: > > $ cat /sys/kernel/mm/transparent_hugepage/{enabled,defrag,shmem_enabled} > always [madvise] never > always defer defer+madvise [madvise] never > always within_size advise [never] deny force > > Versus: > > $ tail /sys/kernel/mm/transparent_hugepage/{enabled,defrag,shmem_enabled} > ==> /sys/kernel/mm/transparent_hugepage/enabled <== > always [madvise] never > > ==> /sys/kernel/mm/transparent_hugepage/defrag <== > always defer defer+madvise [madvise] never > > ==> /sys/kernel/mm/transparent_hugepage/shmem_enabled <== > always within_size advise [never] deny force I added shmem_enabled but kept cat for now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27086#discussion_r2321156814 From stuefe at openjdk.org Thu Sep 4 08:50:44 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 4 Sep 2025 08:50:44 GMT Subject: RFR: 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown [v2] In-Reply-To: References: <3TJnBvDoAPUf4p2e8Y0vpckfm3v8e31cKKwfOeyRnnM=.34c016f4-419d-4dd6-9102-b112a7423f7b@github.com> Message-ID: On Fri, 29 Aug 2025 01:02:43 GMT, David Holmes wrote: >> `ostream_exit` was deleting the stream underlying the `xtty` prior to nulling the `xtty` global variable, resulting in a use-after-free-error. Due to races during VM shutdown we cannot make use of `xtty` perfectly safe, but we can certainly narrow the window during which use-after-free is possible. >> >> Testing: >> - tiers 1-3 sanity >> >> Thanks > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into 8364735-xtty > - 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown Okay. I would like it more if these objects were immortal. Side note, I would love some concept of immortal objects at some point; a way to clearly indicate (and assert) that we intend to keep an object around forever. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26832#pullrequestreview-3184094811 From fbredberg at openjdk.org Thu Sep 4 09:32:44 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Thu, 4 Sep 2025 09:32:44 GMT Subject: RFR: 8365190: Remove LockingMode related code from share In-Reply-To: References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> Message-ID: On Tue, 2 Sep 2025 20:11:15 GMT, Coleen Phillimore wrote: >> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR). >> >> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself. >> >> Passes tier1-tier5 with no added problems. > > src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 344: > >> 342: volatile_nonstatic_field(ObjectMonitor, _entry_list, ObjectWaiter*) \ >> 343: volatile_nonstatic_field(ObjectMonitor, _succ, int64_t) \ >> 344: volatile_nonstatic_field(ObjectMonitor, _stack_locker, BasicLock*) \ > > There are some jvmci tests that check that the java side of jvmci matches, ie: > > make test TEST=compiler/jvmci Tried that and got: `TEST SUCCESS` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321428734 From azafari at openjdk.org Thu Sep 4 09:34:04 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 4 Sep 2025 09:34:04 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v2] In-Reply-To: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: <54aw-ITOpenp_g9jFUvd1T0FCmh_2gA8d6s-npYNbD8=.60e7920d-2cc4-4281-97bb-afed33ce89e6@github.com> > The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. > The acceptable value is changed to 64K. > > Tests: > linux-x64 tier1 Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: first round of fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26955/files - new: https://git.openjdk.org/jdk/pull/26955/files/2c2a2b94..239df39b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=00-01 Stats: 24 lines in 3 files changed: 10 ins; 2 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/26955.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26955/head:pull/26955 PR: https://git.openjdk.org/jdk/pull/26955 From azafari at openjdk.org Thu Sep 4 09:38:41 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 4 Sep 2025 09:38:41 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v2] In-Reply-To: <54aw-ITOpenp_g9jFUvd1T0FCmh_2gA8d6s-npYNbD8=.60e7920d-2cc4-4281-97bb-afed33ce89e6@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> <54aw-ITOpenp_g9jFUvd1T0FCmh_2gA8d6s-npYNbD8=.60e7920d-2cc4-4281-97bb-afed33ce89e6@github.com> Message-ID: On Thu, 4 Sep 2025 09:34:04 GMT, Afshin Zafari wrote: >> The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. >> The acceptable value is changed to 64K. >> >> Tests: >> linux-x64 tier1 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > first round of fixes I preferred to do the refactoring here in this PR. With the fixes, the assertion `lowest_start < highest_start` raises(fails) in 3 jtreg tests in tier1: runtime/os/TestTracePageSizes_explicit-large-page-size.java runtime/CompressedOops/CompressedClassPointers.java gc/g1/Test2GbHeap.java In all 3 cases, lowest is the same as the highest start which is a corner case. Are they bugs? Fixed here or file a separate issue? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3252815844 From aph at openjdk.org Thu Sep 4 09:39:43 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 4 Sep 2025 09:39:43 GMT Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when UseBlockZeroing is false [v2] In-Reply-To: References: <79QlFmmh7CAbxtU89RNVbf8sRBE_u8TbDLA90FqWyEM=.4e8b48ac-21b5-4881-9ca0-29bc87bfe032@github.com> Message-ID: On Wed, 3 Sep 2025 10:28:26 GMT, Patrick Zhang wrote: > Please help review, thanks. OK, but please edit the claims at the top of this PR to respect the new reality. In particular, please state the test cases which are improved. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26917#issuecomment-3252821524 From fbredberg at openjdk.org Thu Sep 4 09:48:45 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Thu, 4 Sep 2025 09:48:45 GMT Subject: RFR: 8365190: Remove LockingMode related code from share In-Reply-To: References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> Message-ID: On Thu, 4 Sep 2025 02:16:46 GMT, David Holmes wrote: >> src/hotspot/share/runtime/basicLock.hpp line 51: >> >>> 49: void set_bad_metadata_deopt() { set_metadata(badDispHeaderDeopt); } >>> 50: >>> 51: static int displaced_header_offset_in_bytes() { return metadata_offset_in_bytes(); } >> >> Also delete line 51 ? > > Still appears used in LIRAssembler. But the assert in which it is used doesn't really make sense as it just checks the offset == 0. This is unfortunately still used by some of the platform files. Since I want to keep this PR clean of platform changes, I have added this to the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321466475 From cnorrbin at openjdk.org Thu Sep 4 09:50:52 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 4 Sep 2025 09:50:52 GMT Subject: RFR: 8366238: Improve RBTree API with stricter comparator semantics and pluggable validation/printing hooks [v4] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 13:40:28 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> The current red-black tree can be made safer, and its inspection capabilities improved. >> >> As briefly discussed in #26904, `COMPARATOR::cmp` could be made clearer and more robust. In particular, its `int` return type invites unsafe `return a ? b` arithmetic, and the boolean validation function also named `cmp` is misleading. >> >> To address this, I?ve introduced the `RBTreeOrdering` enum, inspired by C++20?s `<=>`, which makes incorrect arithmetic impossible. The return type of `COMPARATOR::cmp` is now this enum, forcing users to write an explicit and safe comparison. From the discussion in that PR, I have also renamed the boolean `cmp` to `less`, making its purpose obvious and preventing confusion between the two functions. >> >> Inspection has also been improved, especially for intrusive trees. Previously, `verify_self` only verified core RB-tree properties, yet intrusive nodes often hold additional data with their own separate invariants. Users had to perform those checks in a second traversal, and if an error occurs `print_on` produced little diagnostic value by only printing node addresses. >> >> To solve this, the tree now accepts user-supplied verification and printing callables. This lets users validate their custom node data during the same walk and print richer information when errors occur. >> >> Everything is implemented via template parameters with set defaults, so existing code remains unchanged while new code can opt in to the expanded functionality. >> >> Testing: >> - Oracle tiers 1-3 > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > johan feedback Thank you everyone for reviewing! Let's push this! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26981#issuecomment-3252856275 From cnorrbin at openjdk.org Thu Sep 4 09:50:53 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 4 Sep 2025 09:50:53 GMT Subject: Integrated: 8366238: Improve RBTree API with stricter comparator semantics and pluggable validation/printing hooks In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 09:06:26 GMT, Casper Norrbin wrote: > Hi everyone, > > The current red-black tree can be made safer, and its inspection capabilities improved. > > As briefly discussed in #26904, `COMPARATOR::cmp` could be made clearer and more robust. In particular, its `int` return type invites unsafe `return a ? b` arithmetic, and the boolean validation function also named `cmp` is misleading. > > To address this, I?ve introduced the `RBTreeOrdering` enum, inspired by C++20?s `<=>`, which makes incorrect arithmetic impossible. The return type of `COMPARATOR::cmp` is now this enum, forcing users to write an explicit and safe comparison. From the discussion in that PR, I have also renamed the boolean `cmp` to `less`, making its purpose obvious and preventing confusion between the two functions. > > Inspection has also been improved, especially for intrusive trees. Previously, `verify_self` only verified core RB-tree properties, yet intrusive nodes often hold additional data with their own separate invariants. Users had to perform those checks in a second traversal, and if an error occurs `print_on` produced little diagnostic value by only printing node addresses. > > To solve this, the tree now accepts user-supplied verification and printing callables. This lets users validate their custom node data during the same walk and print richer information when errors occur. > > Everything is implemented via template parameters with set defaults, so existing code remains unchanged while new code can opt in to the expanded functionality. > > Testing: > - Oracle tiers 1-3 This pull request has now been integrated. Changeset: 53d4e928 Author: Casper Norrbin URL: https://git.openjdk.org/jdk/commit/53d4e928ef2851f3e16d1d200b5c3fb036e15e00 Stats: 267 lines in 7 files changed: 167 ins; 9 del; 91 mod 8366238: Improve RBTree API with stricter comparator semantics and pluggable validation/printing hooks Reviewed-by: jsjolen, ayang ------------- PR: https://git.openjdk.org/jdk/pull/26981 From azafari at openjdk.org Thu Sep 4 09:57:48 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 4 Sep 2025 09:57:48 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v12] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 09:12:44 GMT, Johan Sj?len wrote: >> Hi, >> >> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. > > Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge remote-tracking branch 'openjdk/master' into cleanup-membaseline > - Rename to _vma_allocations > - After a lot of casting > - Yup > - Some more ugly casts > - Aha, _root is typed as an IntrusiveRBNode > - Aha, missing include > - Wait, the VMATree is wrong? > - Rename > - It's const > - ... and 6 more: https://git.openjdk.org/jdk/compare/6dda2f6f...82df750b All good! Thanks! ------------- Marked as reviewed by azafari (Committer). PR Review: https://git.openjdk.org/jdk/pull/27003#pullrequestreview-3184365123 From cnorrbin at openjdk.org Thu Sep 4 09:57:49 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 4 Sep 2025 09:57:49 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v12] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 09:12:44 GMT, Johan Sj?len wrote: >> Hi, >> >> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. > > Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge remote-tracking branch 'openjdk/master' into cleanup-membaseline > - Rename to _vma_allocations > - After a lot of casting > - Yup > - Some more ugly casts > - Aha, _root is typed as an IntrusiveRBNode > - Aha, missing include > - Wait, the VMATree is wrong? > - Rename > - It's const > - ... and 6 more: https://git.openjdk.org/jdk/compare/6dda2f6f...82df750b src/hotspot/share/utilities/rbTree.hpp line 457: > 455: ~RBTree() { remove_all(); } > 456: > 457: bool copy_into(RBTree& other) const { Could you move this function into `rbTree.inline.hpp` instead? It's a bit too big to fit here ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27003#discussion_r2321477007 From jsjolen at openjdk.org Thu Sep 4 09:57:48 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 4 Sep 2025 09:57:48 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v12] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 09:12:44 GMT, Johan Sj?len wrote: >> Hi, >> >> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. > > Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge remote-tracking branch 'openjdk/master' into cleanup-membaseline > - Rename to _vma_allocations > - After a lot of casting > - Yup > - Some more ugly casts > - Aha, _root is typed as an IntrusiveRBNode > - Aha, missing include > - Wait, the VMATree is wrong? > - Rename > - It's const > - ... and 6 more: https://git.openjdk.org/jdk/compare/6dda2f6f...82df750b Mach5 passes tier1 and tier2. @caspernorrbin , @afshin-zafari , @Arraying , could you review this again? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27003#issuecomment-3252209567 From fbredberg at openjdk.org Thu Sep 4 10:00:45 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Thu, 4 Sep 2025 10:00:45 GMT Subject: RFR: 8365190: Remove LockingMode related code from share In-Reply-To: <0CMB0g0_Ru1hF5l2NA194kD1ouNwMXrB1667Uvl9mFQ=.b6834c47-be53-41bb-b726-2e282517d6bc@github.com> References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> <0CMB0g0_Ru1hF5l2NA194kD1ouNwMXrB1667Uvl9mFQ=.b6834c47-be53-41bb-b726-2e282517d6bc@github.com> Message-ID: On Wed, 3 Sep 2025 07:37:34 GMT, Axel Boldt-Christmas wrote: >> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR). >> >> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself. >> >> Passes tier1-tier5 with no added problems. > > src/hotspot/share/runtime/basicLock.hpp line 51: > >> 49: void set_bad_metadata_deopt() { set_metadata(badDispHeaderDeopt); } >> 50: >> 51: static int displaced_header_offset_in_bytes() { return metadata_offset_in_bytes(); } > > The `badDispHeaderDeopt` and `badDispHeaderOSR` constants should also be renamed. Added this to o the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191). > src/hotspot/share/runtime/synchronizer.cpp line 634: > >> 632: } >> 633: >> 634: static intptr_t install_hash_code(Thread* current, oop obj) { > > A future RFE could potentially simplify and unify this with `FastHashCode` Added this to o the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321495256 PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321493463 From fbredberg at openjdk.org Thu Sep 4 10:00:47 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Thu, 4 Sep 2025 10:00:47 GMT Subject: RFR: 8365190: Remove LockingMode related code from share In-Reply-To: References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> Message-ID: On Tue, 2 Sep 2025 20:19:06 GMT, Coleen Phillimore wrote: >> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR). >> >> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself. >> >> Passes tier1-tier5 with no added problems. > > src/hotspot/share/runtime/javaThread.cpp line 2007: > >> 2005: #ifdef SUPPORT_MONITOR_COUNT >> 2006: // Nothing to do. Just do some sanity check. >> 2007: assert(_held_monitor_count == 0, "counter should not be used"); > > In further cleanup, can we now remove _held_monitor_count next? I think so, but I'm not sure. Anyhow I've added this to o the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191). > src/hotspot/share/runtime/synchronizer.inline.hpp line 48: > >> 46: assert(current == Thread::current(), "must be"); >> 47: >> 48: LightweightSynchronizer::enter(obj, lock, current); > > In the further RFE, we should remove these dispatch functions too. Added this to o the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321483375 PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321488805 From jsjolen at openjdk.org Thu Sep 4 10:06:44 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 4 Sep 2025 10:06:44 GMT Subject: RFR: 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown [v2] In-Reply-To: References: <3TJnBvDoAPUf4p2e8Y0vpckfm3v8e31cKKwfOeyRnnM=.34c016f4-419d-4dd6-9102-b112a7423f7b@github.com> Message-ID: On Thu, 4 Sep 2025 08:47:57 GMT, Thomas Stuefe wrote: >> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' into 8364735-xtty >> - 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown > > Okay. I would like it more if these objects were immortal. > > Side note, I would love some concept of immortal objects at some point; a way to clearly indicate (and assert) that we intend to keep an object around forever. @tstuefe > Side note, I would love some concept of immortal objects at some point; a way to clearly indicate (and assert) that we intend to keep an object around forever. // The purpose of this class is to provide control over the initialization // time for an object of type T with static storage duration. An instance of // this class provides storage for an object, sized and aligned for T. The // object must be explicitly initialized before use. This avoids problems // resulting from the unspecified initialization time and ordering between // different objects that comes from using undeferred objects (the so-called // "Static Initialization Order Fiasco). // // Once initialized, the object is never destroyed. This avoids similar issues // with the timing and ordering of destruction on normal program exit. // // T must not be a reference type. T may be cv-qualified; accessors will // return a correspondingly cv-qualified reference to the object. template class DeferredStatic { > // Once initialized, the object is never destroyed. This avoids similar issues > // with the timing and ordering of destruction on normal program exit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26832#issuecomment-3252913500 From fbredberg at openjdk.org Thu Sep 4 10:13:43 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Thu, 4 Sep 2025 10:13:43 GMT Subject: RFR: 8365190: Remove LockingMode related code from share In-Reply-To: References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> Message-ID: <_Ola7zEQaOGFemDMFTFkjmAouaLRxSJwarKbWnEKbDk=.4469db17-0021-450b-968e-b28267c626d4@github.com> On Wed, 3 Sep 2025 07:16:06 GMT, David Holmes wrote: >> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR). >> >> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself. >> >> Passes tier1-tier5 with no added problems. > > src/hotspot/share/c1/c1_LIRGenerator.cpp line 638: > >> 636: LIR_Opr hdr = lock; >> 637: lock = new_hdr; >> 638: CodeStub* slow_path = new MonitorExitStub(lock, true, monitor_no); > > It seems all creators for `MonitorExitStub` now pass `true` so that parameter can be removed. Good find! But this affects platform files, and since I want to keep this PR clean of platform changes, I have added this to the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191). > src/hotspot/share/runtime/basicLock.hpp line 40: > >> 38: // Used as a cache of the ObjectMonitor* used when locking. Must either >> 39: // be nullptr or the ObjectMonitor* used when locking. >> 40: volatile uintptr_t _metadata; > > So this could now be a properly typed and named field. Future RFE. I have added this to the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321521296 PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321526089 From fbredberg at openjdk.org Thu Sep 4 10:20:44 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Thu, 4 Sep 2025 10:20:44 GMT Subject: RFR: 8365190: Remove LockingMode related code from share In-Reply-To: References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> Message-ID: <-yO5kJRg9ghIK9ZHi8auSW22u__Ixsva-A4mvgadZic=.4f31754d-c0a9-4646-a3b7-40aade9678a4@github.com> On Thu, 4 Sep 2025 02:18:38 GMT, David Holmes wrote: >> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR). >> >> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself. >> >> Passes tier1-tier5 with no added problems. > > src/hotspot/share/runtime/basicLock.hpp line 53: > >> 51: static int displaced_header_offset_in_bytes() { return metadata_offset_in_bytes(); } >> 52: >> 53: // For lightweight locking > > If the following are for lightweight locking then what are the two previous for? For something old and soon forgotten. :) After I had integrated some platforms I realized that this was no longer needed, but since I want to keep this PR clean of platform changes, I have added this to the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321540639 From cnorrbin at openjdk.org Thu Sep 4 10:31:15 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 4 Sep 2025 10:31:15 GMT Subject: RFR: 8366872: Wrong number of template arguments in test in test_rbtree.cpp Message-ID: After merging #26981, it did not consider the changes made in #27011, making the templates no longer match. ------------- Commit messages: - template fix Changes: https://git.openjdk.org/jdk/pull/27089/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27089&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366872 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27089.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27089/head:pull/27089 PR: https://git.openjdk.org/jdk/pull/27089 From ayang at openjdk.org Thu Sep 4 10:51:49 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 4 Sep 2025 10:51:49 GMT Subject: RFR: 8366872: Wrong number of template arguments in test in test_rbtree.cpp In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 10:26:02 GMT, Casper Norrbin wrote: > After merging #26981, it did not consider the changes made in #27011, making the templates no longer match. Marked as reviewed by ayang (Reviewer). Trivial. ------------- PR Review: https://git.openjdk.org/jdk/pull/27089#pullrequestreview-3184537334 PR Comment: https://git.openjdk.org/jdk/pull/27089#issuecomment-3253079390 From syan at openjdk.org Thu Sep 4 10:51:50 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 4 Sep 2025 10:51:50 GMT Subject: RFR: 8366872: Wrong number of template arguments in test in test_rbtree.cpp In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 10:26:02 GMT, Casper Norrbin wrote: > After merging #26981, it did not consider the changes made in #27011, making the templates no longer match. The patch works for me on linux-x64 with gcc10. ------------- Marked as reviewed by syan (Committer). PR Review: https://git.openjdk.org/jdk/pull/27089#pullrequestreview-3184541999 From cnorrbin at openjdk.org Thu Sep 4 10:51:50 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 4 Sep 2025 10:51:50 GMT Subject: RFR: 8366872: Wrong number of template arguments in test in test_rbtree.cpp In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 10:26:02 GMT, Casper Norrbin wrote: > After merging #26981, it did not consider the changes made in #27011, making the templates no longer match. Thank you for the quick reviews. Trival? Then we can get it fixed right away. Thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27089#issuecomment-3253077334 PR Comment: https://git.openjdk.org/jdk/pull/27089#issuecomment-3253081140 From cnorrbin at openjdk.org Thu Sep 4 10:51:51 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 4 Sep 2025 10:51:51 GMT Subject: Integrated: 8366872: Wrong number of template arguments in test in test_rbtree.cpp In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 10:26:02 GMT, Casper Norrbin wrote: > After merging #26981, it did not consider the changes made in #27011, making the templates no longer match. This pull request has now been integrated. Changeset: 8c50bed8 Author: Casper Norrbin URL: https://git.openjdk.org/jdk/commit/8c50bed86709a45615743dd7953b8c6861f1da0c Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8366872: Wrong number of template arguments in test in test_rbtree.cpp Reviewed-by: ayang, syan ------------- PR: https://git.openjdk.org/jdk/pull/27089 From coleenp at openjdk.org Thu Sep 4 11:21:52 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 4 Sep 2025 11:21:52 GMT Subject: RFR: 8365190: Remove LockingMode related code from share In-Reply-To: <-yO5kJRg9ghIK9ZHi8auSW22u__Ixsva-A4mvgadZic=.4f31754d-c0a9-4646-a3b7-40aade9678a4@github.com> References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> <-yO5kJRg9ghIK9ZHi8auSW22u__Ixsva-A4mvgadZic=.4f31754d-c0a9-4646-a3b7-40aade9678a4@github.com> Message-ID: On Thu, 4 Sep 2025 10:18:27 GMT, Fredrik Bredberg wrote: >> src/hotspot/share/runtime/basicLock.hpp line 53: >> >>> 51: static int displaced_header_offset_in_bytes() { return metadata_offset_in_bytes(); } >>> 52: >>> 53: // For lightweight locking >> >> If the following are for lightweight locking then what are the two previous for? > > For something old and soon forgotten. :) > After I had integrated some platforms I realized that this was no longer needed, but since I want to keep this PR clean of platform changes, I have added this to the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191). This makes sense to change the displaced header names in BasicLock with the changes to various disp_hdr and other register names in the next cleanup. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321704905 From coleenp at openjdk.org Thu Sep 4 11:21:55 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 4 Sep 2025 11:21:55 GMT Subject: RFR: 8365190: Remove LockingMode related code from share In-Reply-To: References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> Message-ID: On Thu, 4 Sep 2025 02:26:26 GMT, David Holmes wrote: >> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 769: >> >>> 767: >>> 768: // LightweightSynchronizer::inflate_locked_or_imse is used to to get an inflated >>> 769: // ObjectMonitor* when lightweight locking is used. It is used from contexts >> >> I guess you don't need the phrase "when lightweight locking is used". > > Even calling it "lightweight locking" is no longer needed. I think the name "lightweight locking" is used for the file name and class name, so the name is okay. It does help if you're trying to understand the history of the locking algorithm. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321711418 From coleenp at openjdk.org Thu Sep 4 11:25:53 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 4 Sep 2025 11:25:53 GMT Subject: RFR: 8365190: Remove LockingMode related code from share In-Reply-To: References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> Message-ID: On Thu, 4 Sep 2025 09:55:23 GMT, Fredrik Bredberg wrote: >> src/hotspot/share/runtime/synchronizer.inline.hpp line 48: >> >>> 46: assert(current == Thread::current(), "must be"); >>> 47: >>> 48: LightweightSynchronizer::enter(obj, lock, current); >> >> In the further RFE, we should remove these dispatch functions too. > > Added this to o the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191). So to be clear, we should probably have 2+ RFEs that follow this. One to remove the cpu specific names like displaced header, one to remove the loom interactions and held_monitor_count, and another to remove the dispatches to LightweightSynchronizer and make ObjectSynchronizer's role in object locking clear. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2321723438 From ayang at openjdk.org Thu Sep 4 11:32:49 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 4 Sep 2025 11:32:49 GMT Subject: RFR: 8366854: Extend jtreg failure handler with THP info [v2] In-Reply-To: References: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> Message-ID: <8bginA83--2TrOIMPDkbET4WT1QrMUgzn_r6IrUkDaA=.0a95c192-750b-4a3e-8fd7-05e6fb856d9c@github.com> On Thu, 4 Sep 2025 07:49:56 GMT, Stefan Karlsson wrote: >> I propose that we also dump /proc/meminfo, /proc/vmstat, and /sys/kernel/mm/transparent_hugepage/{enabled, defrag} from the failure handler. >> >> This information has been helpful when investigating a failure where there was an unexpected lack of transparent huge pages. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Add shmem_enabled Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27086#pullrequestreview-3184726590 From ysuenaga at openjdk.org Thu Sep 4 11:34:54 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 4 Sep 2025 11:34:54 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU Message-ID: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`. $ jfr print --events jdk.CPUInformation test.jfr jdk.CPUInformation { startTime = 10:49:27.692 (2025-09-04) cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64" description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel Family: (0x6), Model: (0xb5), Stepping: 0x0 Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650 Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800 Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instructi on, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC" sockets = 1 cores = 7 hwThreads = 14 } Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`. We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least. This patch sets `0` to `cores` and "Hybrid Architecture" is added to `description` as following if `jdk.CPUInformation` is generated on hybrid CPU. I want to set `-1` to `cores` TBH, but I didn't because `cores` is declared as `uint` - `-1` is equivalent with `UINT_MAX`, it looks like strange at here. jdk.CPUInformation { startTime = 10:48:12.420 (2025-09-04) cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64" description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel Family: (0x6), Model: (0xb5), Stepping: 0x0 Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650 Features: ebx: 0x42800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800 Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instructi on, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC, Hybrid Architecture" sockets = 1 cores = 0 hwThreads = 14 } This change affects showing information only, would not change the behavior like active processor count. ------------- Commit messages: - Revert "Update condition" - Update condition - Add fallback code if logical_cpus == 0 - 8365633: JFR reports incorrect number of cores on hybrid CPU Changes: https://git.openjdk.org/jdk/pull/27080/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27080&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366847 Stats: 13 lines in 1 file changed: 10 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27080.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27080/head:pull/27080 PR: https://git.openjdk.org/jdk/pull/27080 From ysuenaga at openjdk.org Thu Sep 4 11:34:54 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Thu, 4 Sep 2025 11:34:54 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU In-Reply-To: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> Message-ID: On Thu, 4 Sep 2025 02:15:01 GMT, Yasumasa Suenaga wrote: > On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`. > > > $ jfr print --events jdk.CPUInformation test.jfr > jdk.CPUInformation { > startTime = 10:49:27.692 (2025-09-04) > cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64" > description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel > Family: (0x6), Model: (0xb5), Stepping: 0x0 > Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650 > Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff > Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800 > Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instruc tion, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC" > sockets = 1 > cores = 7 > hwThreads = 14 > } > > > Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`. > > We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least. > > This patch sets `0` to `cores` and "Hybrid Architecture" ... src/hotspot/cpu/x86/vm_version_x86.cpp line 2581: > 2579: // CPUID 0Bh (ECX = 1) might return 0 on older AMD processor (EPYC 7763 at least) > 2580: threads_per_package = threads_per_core() * cores_per_cpu(); > 2581: } Check `thread_per_package` from `CPUID` to avoid SIGFPE (div by zero). `CPUID` leaf 0Bh with ECX (subleaf) = 1 seems to return `0` as number of logical processors in spite of leaf 08h is supported in some older processors. It's strange, but I saw it on AMD EPYC 7763 on GitHub Actions runner. The problem appears as following. I haven't faced this problem on AMD Ryzen 3 3300X. # # A fatal error has been detected by the Java Runtime Environment: # # SIGFPE (0x8) at pc=0x00007f19e11ffeed, pid=11344, tid=11345 # # JRE version: OpenJDK Runtime Environment (26.0) (build 26-internal-YaSuenag-ebf4aec23fa95c8d54d1196c7be85e99f0846420) # Java VM: OpenJDK 64-Bit Server VM (26-internal-YaSuenag-ebf4aec23fa95c8d54d1196c7be85e99f0846420, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x11ffeed] VM_Version::initialize_cpu_information()+0x2d # # CreateCoredumpOnCrash turned off, no core file dumped # # JFR recording file will be written. Location: /home/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part3/scratch/1/hs_err_pid11344.jfr # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # --------------- S U M M A R Y ------------ Command Line: -Xmx768m -XX:MaxRAMPercentage=12.5 -Dtest.boot.jdk=/home/runner/work/jdk/jdk/bootjdk/jdk -Djava.io.tmpdir=/home/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part3/tmp -ea -esa -XX:-CreateCoredumpOnCrash -Xlog:jfr=trace -XX:StartFlightRecording:filename=./dumped.jfr,dumponexit=true,settings=profile jdk.jfr.startupargs.TestDumpOnExit$TestMain Host: AMD EPYC 7763 64-Core Processor, 4 cores, 15G, Ubuntu 22.04.5 LTS Time: Thu Sep 4 07:17:02 2025 UTC elapsed time: 0.570221 seconds (0d 0h 0m 0s) --------------- T H R E A D --------------- Current thread (0x00007f19d802ad20): JavaThread "main" [_thread_in_vm, id=11345, stack(0x00007f19dff00000,0x00007f19e0000000) (1024K)] Stack: [0x00007f19dff00000,0x00007f19e0000000], sp=0x00007f19dfffbd40, free space=1007k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x11ffeed] VM_Version::initialize_cpu_information()+0x2d (vm_version_x86.cpp:2581) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2321741255 From fbredberg at openjdk.org Thu Sep 4 11:36:02 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Thu, 4 Sep 2025 11:36:02 GMT Subject: RFR: 8365190: Remove LockingMode related code from share [v2] In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> Message-ID: > Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR). > > This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself. > > Passes tier1-tier5 with no added problems. 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/27041/files - new: https://git.openjdk.org/jdk/pull/27041/files/71038b71..3c1b56c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27041&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27041&range=00-01 Stats: 17 lines in 4 files changed: 1 ins; 4 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/27041.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27041/head:pull/27041 PR: https://git.openjdk.org/jdk/pull/27041 From jsjolen at openjdk.org Thu Sep 4 11:43:24 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 4 Sep 2025 11:43:24 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v13] In-Reply-To: References: Message-ID: > Hi, > > The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Move into rbTree.inline.hpp file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27003/files - new: https://git.openjdk.org/jdk/pull/27003/files/82df750b..615598e6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=11-12 Stats: 96 lines in 2 files changed: 49 ins; 46 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27003.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003 PR: https://git.openjdk.org/jdk/pull/27003 From jsjolen at openjdk.org Thu Sep 4 11:46:26 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 4 Sep 2025 11:46:26 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v14] In-Reply-To: References: Message-ID: > Hi, > > The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Missed const-ness ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27003/files - new: https://git.openjdk.org/jdk/pull/27003/files/615598e6..3bfe8593 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27003&range=12-13 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27003.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27003/head:pull/27003 PR: https://git.openjdk.org/jdk/pull/27003 From fbredberg at openjdk.org Thu Sep 4 12:10:01 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Thu, 4 Sep 2025 12:10:01 GMT Subject: RFR: 8365190: Remove LockingMode related code from share [v3] In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> Message-ID: <44Gctjipr64z9PfAvwdEgRo4pq8sFtmpZOE4JehO4rc=.c6532986-972f-466c-b7c6-75e063613fa9@github.com> > Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR). > > This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself. > > Passes tier1-tier5 with no added problems. Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: New version for Coleen ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27041/files - new: https://git.openjdk.org/jdk/pull/27041/files/3c1b56c5..f2fc9a5f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27041&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27041&range=01-02 Stats: 9 lines in 1 file changed: 0 ins; 2 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27041.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27041/head:pull/27041 PR: https://git.openjdk.org/jdk/pull/27041 From coleenp at openjdk.org Thu Sep 4 12:10:01 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 4 Sep 2025 12:10:01 GMT Subject: RFR: 8365190: Remove LockingMode related code from share [v3] In-Reply-To: <44Gctjipr64z9PfAvwdEgRo4pq8sFtmpZOE4JehO4rc=.c6532986-972f-466c-b7c6-75e063613fa9@github.com> References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> <44Gctjipr64z9PfAvwdEgRo4pq8sFtmpZOE4JehO4rc=.c6532986-972f-466c-b7c6-75e063613fa9@github.com> Message-ID: On Thu, 4 Sep 2025 12:07:43 GMT, Fredrik Bredberg wrote: >> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR). >> >> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself. >> >> Passes tier1-tier5 with no added problems. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > New version for Coleen Looks great!! ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3184882023 From ayang at openjdk.org Thu Sep 4 12:21:16 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 4 Sep 2025 12:21:16 GMT Subject: RFR: 8366881: Parallel: Obsolete HeapMaximumCompactionInterval Message-ID: Remove a produce flag that controls maximum-compaction during a full-gc. The existing criteria, such as heap usage, old-gen density, are enough for deciding maximum-compaction. Test: tier1-3 ------------- Commit messages: - pgc-max-compaction-obsolete Changes: https://git.openjdk.org/jdk/pull/27091/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27091&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366881 Stats: 55 lines in 5 files changed: 8 ins; 27 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/27091.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27091/head:pull/27091 PR: https://git.openjdk.org/jdk/pull/27091 From cnorrbin at openjdk.org Thu Sep 4 13:03:48 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 4 Sep 2025 13:03:48 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v14] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 11:46:26 GMT, Johan Sj?len wrote: >> Hi, >> >> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Missed const-ness Looks good! ------------- Marked as reviewed by cnorrbin (Committer). PR Review: https://git.openjdk.org/jdk/pull/27003#pullrequestreview-3185157530 From fbredberg at openjdk.org Thu Sep 4 13:03:50 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Thu, 4 Sep 2025 13:03:50 GMT Subject: RFR: 8365190: Remove LockingMode related code from share [v3] In-Reply-To: References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> Message-ID: On Tue, 2 Sep 2025 13:46:11 GMT, Roberto Casta?eda Lozano wrote: >> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: >> >> New version for Coleen > > src/hotspot/share/opto/phaseX.cpp line 1672: > >> 1670: // Found (linux x64 only?) with: >> 1671: // serviceability/sa/ClhsdbThreadContext.java >> 1672: // -XX:+UnlockExperimentalVMOptions -XX:LockingMode=1 -XX:+IgnoreUnrecognizedVMOptions -XX:VerifyIterativeGVN=1110 > > For traceability, I suggest leaving this line untouched and adding a comment in the next line clarifying that `-XX:LockingMode` is not available anymore. Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2322046338 From fbredberg at openjdk.org Thu Sep 4 13:03:51 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Thu, 4 Sep 2025 13:03:51 GMT Subject: RFR: 8365190: Remove LockingMode related code from share [v3] In-Reply-To: References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> Message-ID: On Thu, 4 Sep 2025 11:19:14 GMT, Coleen Phillimore wrote: >> Even calling it "lightweight locking" is no longer needed. > > I think the name "lightweight locking" is used for the file name and class name, so the name is okay. It does help if you're trying to understand the history of the locking algorithm. Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2322050243 From fbredberg at openjdk.org Thu Sep 4 13:03:53 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Thu, 4 Sep 2025 13:03:53 GMT Subject: RFR: 8365190: Remove LockingMode related code from share [v3] In-Reply-To: References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> Message-ID: On Tue, 2 Sep 2025 20:22:45 GMT, Coleen Phillimore wrote: >> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: >> >> New version for Coleen > > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 823: > >> 821: ObjectMonitor* LightweightSynchronizer::inflate_into_object_header(oop object, ObjectSynchronizer::InflateCause cause, JavaThread* locking_thread, Thread* current) { >> 822: >> 823: // The JavaThread* locking_thread parameter is only used by lightweight locking and > > Same here. suggestion: > > > // The JavaThread* locking parameter requires that the locking_thread == JavaThread::current, or is suspended > // throughout the call by some other mechanism. Fixed > src/hotspot/share/runtime/synchronizer.cpp line 542: > >> 540: } >> 541: ObjectMonitor* monitor; >> 542: monitor = LightweightSynchronizer::inflate_locked_or_imse(obj(), inflate_cause_notify, CHECK); > > Declare and initialize on the same line: > > ObjectMonitor* monitor = LightwightSynchronizer::inflate_locked_or_imse(obj...); Fixed > src/hotspot/share/runtime/synchronizer.cpp line 557: > >> 555: >> 556: ObjectMonitor* monitor; >> 557: monitor = LightweightSynchronizer::inflate_locked_or_imse(obj(), inflate_cause_notify, CHECK); > > same here with > ObjectMonitor* monitor = LIght ... > > I think we should have another RFE to look at eliminating the middle call. Call these in LIghtweightSynchronizer::notify, notifyAll and waitInterruptably directly and remove these functions. Added this to o the [next cleanup](https://bugs.openjdk.org/browse/JDK-8365191). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2322051302 PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2322052236 PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2322057900 From shade at openjdk.org Thu Sep 4 13:20:50 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 4 Sep 2025 13:20:50 GMT Subject: RFR: 8366854: Extend jtreg failure handler with THP info [v2] In-Reply-To: References: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> Message-ID: On Thu, 4 Sep 2025 07:49:56 GMT, Stefan Karlsson wrote: >> I propose that we also dump /proc/meminfo, /proc/vmstat, and /sys/kernel/mm/transparent_hugepage/{enabled, defrag} from the failure handler. >> >> This information has been helpful when investigating a failure where there was an unexpected lack of transparent huge pages. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Add shmem_enabled Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27086#pullrequestreview-3185246018 From rcastanedalo at openjdk.org Thu Sep 4 13:34:52 2025 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 4 Sep 2025 13:34:52 GMT Subject: RFR: 8365190: Remove LockingMode related code from share [v3] In-Reply-To: <44Gctjipr64z9PfAvwdEgRo4pq8sFtmpZOE4JehO4rc=.c6532986-972f-466c-b7c6-75e063613fa9@github.com> References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> <44Gctjipr64z9PfAvwdEgRo4pq8sFtmpZOE4JehO4rc=.c6532986-972f-466c-b7c6-75e063613fa9@github.com> Message-ID: On Thu, 4 Sep 2025 12:10:01 GMT, Fredrik Bredberg wrote: >> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR). >> >> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself. >> >> Passes tier1-tier5 with no added problems. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > New version for Coleen Compiler changes look good, thanks! ------------- Marked as reviewed by rcastanedalo (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3185331487 From asmehra at openjdk.org Thu Sep 4 14:01:51 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Thu, 4 Sep 2025 14:01:51 GMT Subject: RFR: 8366475: Rename MetaspaceShared class to AOTMetaspace [v4] In-Reply-To: <-8Bu8-ZieMNwrkkdkjjwqkdSi8Dv9gp3THbl_rRBHS4=.b95bd18e-11ae-46a0-8b0b-2ecb2aa4c34a@github.com> References: <-8Bu8-ZieMNwrkkdkjjwqkdSi8Dv9gp3THbl_rRBHS4=.b95bd18e-11ae-46a0-8b0b-2ecb2aa4c34a@github.com> Message-ID: On Thu, 4 Sep 2025 05:38:20 GMT, Ioi Lam wrote: >> This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology): >> >> Rename this class to with a naming convention that's consistent with other new AOT classes such as AOTClassLinker. >> >> All changes are mechanical text replacement. Headers are resorted alphabetically. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Fixed include order > - Merge branch 'master' into 8366475-rename-metaspace-shared-to-aot-metaspace > - Merge branch '8366474-rename_metaspaceobj_is_shared_to_in_aot_cache' into 8366475-rename-metaspace-shared-to-aot-metaspace > - Also renamed ConstantPool::is_shared() because it shadows MetaspaceObj::is_shared() > - Merge branch 'master' into 8366474-rename_metaspaceobj_is_shared_to_in_aot_cache > - removed unnecessary includes > - Redo changes in comments and tests > - Merge branch '8366474-rename_metaspaceobj_is_shared_to_in_aot_cache' into 8366475-rename-metaspace-shared-to-aot-metaspace > - Removed MetaspaceShared -> AOTMetaspace changes that are intended for https://github.com/openjdk/jdk/pull/27017 > - Rename MetaspaceShared -> AOTMetaspace > - ... and 1 more: https://git.openjdk.org/jdk/compare/90a2db1e...63073feb lgtm @iklam thanks for addressing the comments. ------------- Marked as reviewed by asmehra (Committer). PR Review: https://git.openjdk.org/jdk/pull/27017#pullrequestreview-3185475117 PR Comment: https://git.openjdk.org/jdk/pull/27017#issuecomment-3253872538 From cnorrbin at openjdk.org Thu Sep 4 14:10:55 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 4 Sep 2025 14:10:55 GMT Subject: RFR: 8366897: RBTreeTest.IntrusiveTest and RBTreeTest.CustomVerify tests fail on non-debug builds Message-ID: #26981 introduced the possibility to supply the red-black tree with a custom verifier, however the call to this verifier was inside an assert, meaning it wasn't called for all builds. This results in two gtests failing. This fix moves the call outside the assert, and then checks the result instead. ------------- Commit messages: - fix Changes: https://git.openjdk.org/jdk/pull/27097/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27097&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366897 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27097.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27097/head:pull/27097 PR: https://git.openjdk.org/jdk/pull/27097 From egahlin at openjdk.org Thu Sep 4 15:08:46 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 4 Sep 2025 15:08:46 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU In-Reply-To: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> Message-ID: On Thu, 4 Sep 2025 02:15:01 GMT, Yasumasa Suenaga wrote: > On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`. > > > $ jfr print --events jdk.CPUInformation test.jfr > jdk.CPUInformation { > startTime = 10:49:27.692 (2025-09-04) > cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64" > description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel > Family: (0x6), Model: (0xb5), Stepping: 0x0 > Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650 > Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff > Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800 > Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instruc tion, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC" > sockets = 1 > cores = 7 > hwThreads = 14 > } > > > Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`. > > We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least. > > This patch sets `0` to `cores` and "Hybrid Architecture" ... If a value is missing, emit jmc_undefined_long in event.set_cores(...), so it will show up as N/A in both JMC and the JFR tool. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3254159055 From tschatzl at openjdk.org Thu Sep 4 15:08:53 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 4 Sep 2025 15:08:53 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v53] In-Reply-To: References: Message-ID: <-6I6w_xqk0J13gqMX8ZQel4elME1K0ZYs55Li2lmgd8=.fdd1d6fb-eaae-4d93-a2ac-74b03d3f4212@github.com> > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 71 commits: - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * improve logging for refinement, making it similar to marking logging - * commit merge changes - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * fix merge error - * forgot to actually save the files - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - ... and 61 more: https://git.openjdk.org/jdk/compare/e1903557...2a614a2c ------------- Changes: https://git.openjdk.org/jdk/pull/23739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=52 Stats: 7117 lines in 112 files changed: 2592 ins; 3585 del; 940 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From kvn at openjdk.org Thu Sep 4 16:26:56 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 4 Sep 2025 16:26:56 GMT Subject: RFR: 8366475: Rename MetaspaceShared class to AOTMetaspace [v4] In-Reply-To: <-8Bu8-ZieMNwrkkdkjjwqkdSi8Dv9gp3THbl_rRBHS4=.b95bd18e-11ae-46a0-8b0b-2ecb2aa4c34a@github.com> References: <-8Bu8-ZieMNwrkkdkjjwqkdSi8Dv9gp3THbl_rRBHS4=.b95bd18e-11ae-46a0-8b0b-2ecb2aa4c34a@github.com> Message-ID: On Thu, 4 Sep 2025 05:38:20 GMT, Ioi Lam wrote: >> This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology): >> >> Rename this class to with a naming convention that's consistent with other new AOT classes such as AOTClassLinker. >> >> All changes are mechanical text replacement. Headers are resorted alphabetically. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Fixed include order > - Merge branch 'master' into 8366475-rename-metaspace-shared-to-aot-metaspace > - Merge branch '8366474-rename_metaspaceobj_is_shared_to_in_aot_cache' into 8366475-rename-metaspace-shared-to-aot-metaspace > - Also renamed ConstantPool::is_shared() because it shadows MetaspaceObj::is_shared() > - Merge branch 'master' into 8366474-rename_metaspaceobj_is_shared_to_in_aot_cache > - removed unnecessary includes > - Redo changes in comments and tests > - Merge branch '8366474-rename_metaspaceobj_is_shared_to_in_aot_cache' into 8366475-rename-metaspace-shared-to-aot-metaspace > - Removed MetaspaceShared -> AOTMetaspace changes that are intended for https://github.com/openjdk/jdk/pull/27017 > - Rename MetaspaceShared -> AOTMetaspace > - ... and 1 more: https://git.openjdk.org/jdk/compare/90a2db1e...63073feb Re-approved ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27017#pullrequestreview-3186112530 From iklam at openjdk.org Thu Sep 4 16:26:57 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 4 Sep 2025 16:26:57 GMT Subject: Integrated: 8366475: Rename MetaspaceShared class to AOTMetaspace In-Reply-To: References: Message-ID: <_S6QuzRauRjjk57Zs3Xg5aRue8ve7utVf_x1QtQJcHo=.97c23d7f-48d1-43ec-a51c-248a8dff0d74@github.com> On Sat, 30 Aug 2025 02:21:32 GMT, Ioi Lam wrote: > This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology): > > Rename this class to with a naming convention that's consistent with other new AOT classes such as AOTClassLinker. > > All changes are mechanical text replacement. Headers are resorted alphabetically. This pull request has now been integrated. Changeset: f90d5203 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/f90d520308d5fa72497dc59bee7258931c2a3d95 Stats: 367 lines in 60 files changed: 35 ins; 35 del; 297 mod 8366475: Rename MetaspaceShared class to AOTMetaspace Reviewed-by: kvn, asmehra ------------- PR: https://git.openjdk.org/jdk/pull/27017 From iklam at openjdk.org Thu Sep 4 16:26:56 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 4 Sep 2025 16:26:56 GMT Subject: RFR: 8366475: Rename MetaspaceShared class to AOTMetaspace In-Reply-To: <8G20SIHg7RUA6APWLzqUwGzfRp5QkGYn6-6JdSiQ614=.7107d0de-be8f-4449-9438-021a13dcddf4@github.com> References: <8G20SIHg7RUA6APWLzqUwGzfRp5QkGYn6-6JdSiQ614=.7107d0de-be8f-4449-9438-021a13dcddf4@github.com> Message-ID: On Sat, 30 Aug 2025 14:15:09 GMT, Vladimir Kozlov wrote: >> This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology): >> >> Rename this class to with a naming convention that's consistent with other new AOT classes such as AOTClassLinker. >> >> All changes are mechanical text replacement. Headers are resorted alphabetically. > > @stefank also asked about `INCLUDE_CDS` to replace it with `INCLUDE_AOT`. Should we do this? Thanks @vnkozlov @ashu-mehra for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/27017#issuecomment-3254504004 From vaivanov at openjdk.org Thu Sep 4 16:56:49 2025 From: vaivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 4 Sep 2025 16:56:49 GMT Subject: RFR: 8363858: [perf] OptimizeFill may use wide set of intrinsics [v3] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 22:11:17 GMT, Vladimir Ivanov wrote: >> Default mode should use OptimizeFill=true option for the SRF platform. > > Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8363858: [perf] OptimizeFill may use wide set of intrinsics Thanks for your review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26974#issuecomment-3254590784 From duke at openjdk.org Thu Sep 4 16:56:49 2025 From: duke at openjdk.org (duke) Date: Thu, 4 Sep 2025 16:56:49 GMT Subject: RFR: 8363858: [perf] OptimizeFill may use wide set of intrinsics [v3] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 22:11:17 GMT, Vladimir Ivanov wrote: >> Default mode should use OptimizeFill=true option for the SRF platform. > > Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8363858: [perf] OptimizeFill may use wide set of intrinsics @IvaVladimir Your change (at version c0360ac9639f0829b088267919f4ddec4703c599) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26974#issuecomment-3254594907 From vaivanov at openjdk.org Thu Sep 4 17:00:50 2025 From: vaivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 4 Sep 2025 17:00:50 GMT Subject: Integrated: 8363858: [perf] OptimizeFill may use wide set of intrinsics In-Reply-To: References: Message-ID: On Wed, 27 Aug 2025 23:56:40 GMT, Vladimir Ivanov wrote: > Default mode should use OptimizeFill=true option for the SRF platform. This pull request has now been integrated. Changeset: 1dc1d56f Author: Vladimir Ivanov Committer: Sandhya Viswanathan URL: https://git.openjdk.org/jdk/commit/1dc1d56f79e10c9b4c5c8b42a80a191f7b14c738 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8363858: [perf] OptimizeFill may use wide set of intrinsics Reviewed-by: roland, sviswanathan ------------- PR: https://git.openjdk.org/jdk/pull/26974 From cslucas at openjdk.org Thu Sep 4 17:50:46 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Thu, 4 Sep 2025 17:50:46 GMT Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to conc_instruction_and_data_patch [v3] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 00:37:59 GMT, Cesar Soares Lucas wrote: >> Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64. >> >> The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%. > > Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: > > Make PPC backend to also use concurrent code patching. @TheRealMDoerr - gentle nudge. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26999#issuecomment-3254845065 From ayang at openjdk.org Thu Sep 4 17:51:42 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 4 Sep 2025 17:51:42 GMT Subject: RFR: 8366897: RBTreeTest.IntrusiveCustomVerifyTest and RBTreeTest.CustomVerify tests fail on non-debug builds In-Reply-To: References: Message-ID: <4Q9basn6SqntiFje8eCjzGhdhz3YBfKELVAzze3CiVM=.06ff2e5b-bdca-4544-8a0b-52e4a0f98ab6@github.com> On Thu, 4 Sep 2025 14:04:39 GMT, Casper Norrbin wrote: > #26981 introduced the possibility to supply the red-black tree with a custom verifier, however the call to this verifier was inside an assert, meaning it wasn't called for all builds. This results in two gtests failing. > > This fix moves the call outside the assert, and then checks the result instead. > > Testing: > - Local gtest testing > - Oracle tier 1 Since `extra_verifier` may have side-effect, it must be invoked outside the `assert` macro. How about `assert(verifier(...` a few below? Does that require similar fixup? ------------- Marked as reviewed by ayang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27097#pullrequestreview-3186433683 From cnorrbin at openjdk.org Thu Sep 4 18:03:45 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 4 Sep 2025 18:03:45 GMT Subject: RFR: 8366897: RBTreeTest.IntrusiveCustomVerifyTest and RBTreeTest.CustomVerify tests fail on non-debug builds In-Reply-To: <4Q9basn6SqntiFje8eCjzGhdhz3YBfKELVAzze3CiVM=.06ff2e5b-bdca-4544-8a0b-52e4a0f98ab6@github.com> References: <4Q9basn6SqntiFje8eCjzGhdhz3YBfKELVAzze3CiVM=.06ff2e5b-bdca-4544-8a0b-52e4a0f98ab6@github.com> Message-ID: <8JYHeuODfe5hncNqJ0umyVKAZInbAbhtLcDtjaFx_Ok=.e41aa81d-fc29-4307-b7ce-10f32ca765f4@github.com> On Thu, 4 Sep 2025 17:48:56 GMT, Albert Mingkun Yang wrote: > How about `assert(verifier(...` a few below? Does that require similar fixup? That is the internal self-defined verifier that compares nodes, defined in `verify_self`. It has no side effect, and is strictly used for node comparisons. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27097#issuecomment-3254899269 From coleenp at openjdk.org Thu Sep 4 18:28:43 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 4 Sep 2025 18:28:43 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v5] In-Reply-To: <1WzJLDW8mkbrCvucRTvQCTHNzqcs_43-ay8XWS2PiC0=.da2d6fa8-c8da-41ec-98b3-8317ee0cec39@github.com> References: <92PKx4jRrCfYgf-jdR3WG6Npmo6Sao4mtt2tAQdrv5U=.aeef13b1-2ab5-4fd7-af0d-6c9eab9a204d@github.com> <1WzJLDW8mkbrCvucRTvQCTHNzqcs_43-ay8XWS2PiC0=.da2d6fa8-c8da-41ec-98b3-8317ee0cec39@github.com> Message-ID: <4XCkBAdni13z3l_nch7WTJlxjcYyv2r6Q8iGg1AYu5w=.933a0b6b-204f-4936-8834-36ac1e86f6fb@github.com> On Mon, 1 Sep 2025 00:57:29 GMT, Ioi Lam wrote: >> src/hotspot/share/classfile/systemDictionaryShared.cpp line 469: >> >>> 467: >>> 468: // Returns true if the DumpTimeClassInfo::is_excluded() is true for at least one of k's exclusion dependencies. >>> 469: bool SystemDictionaryShared::check_dependencies_exclusion(InstanceKlass* k, DumpTimeClassInfo* info) { >> >> So this checks one level of InstanceKlass* k's dependencies, and the table above collects one level of k or k's subclass's dependencies and calls this for those. >> >> class K : extends B implements I, J verifies C {} - the above hashtable has B, I and J and C. >> >> This function takes B - so checks B class. >> >> class B : extends A implements intf verifies C again, why not {} >> >> So it'd check A and intf and C again. But when do we check A's super? >> >> It seems like the hashtable should be created for all levels of the hierarchy, so only one bit of code should walk the hierarchy, not two. > > The ExclusionCheckCandidates table contains all (recursive) supertypes -- E.g., its `add_candidate(k)` method calls `add_candidate(k->java_super())`. But what about k->java_super()->java_super() ? Where is that added? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2323086990 From iklam at openjdk.org Thu Sep 4 18:31:47 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 4 Sep 2025 18:31:47 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v4] In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 16:36:09 GMT, Matias Saavedra Silva wrote: >> Ioi Lam 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 five additional commits since the last revision: >> >> - Merge branch 'master' into 8317269-store-old-classes-in-linked-state-in-aot-cache >> - @coleenp comments >> - More bug fixes from JCK testing >> - Fixed bugs found in JCK testing >> - 8317269: Store old classes in linked state in AOT cache > > src/hotspot/share/cds/cdsConfig.cpp line 939: > >> 937: // of the production run. This means that if a class was successfully verified >> 938: // in the assembly phase, all of the verifier's assignability checks will remain >> 939: // valid in the production run, so we don't need to verify aot-lined classes again. > > Type: aot-lined -> aot-linked Fixed > src/hotspot/share/cds/dumpTimeClassInfo.cpp line 94: > >> 92: if (log_is_enabled(Trace, aot, verification)) { >> 93: ResourceMark rm; >> 94: log_trace(aot, verification)("add old verification dependency: %s: %s must be also be archived", > > Should this comment be "added old..."? Fixed > src/hotspot/share/classfile/systemDictionaryShared.cpp line 241: > >> 239: } >> 240: >> 241: // This is a table of classes that need to be check for exclusion. > > Typo: check -> checked Fixed. > src/hotspot/share/classfile/systemDictionaryShared.cpp line 312: > >> 310: ResourceMark rm; >> 311: >> 312: // This will recursive find ik and all of its exclusion dependencies that have not yet been checked. > > Typo: recursively Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2323096950 PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2323097082 PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2323097206 PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2323097323 From iklam at openjdk.org Thu Sep 4 18:35:47 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 4 Sep 2025 18:35:47 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v5] In-Reply-To: <4XCkBAdni13z3l_nch7WTJlxjcYyv2r6Q8iGg1AYu5w=.933a0b6b-204f-4936-8834-36ac1e86f6fb@github.com> References: <92PKx4jRrCfYgf-jdR3WG6Npmo6Sao4mtt2tAQdrv5U=.aeef13b1-2ab5-4fd7-af0d-6c9eab9a204d@github.com> <1WzJLDW8mkbrCvucRTvQCTHNzqcs_43-ay8XWS2PiC0=.da2d6fa8-c8da-41ec-98b3-8317ee0cec39@github.com> <4XCkBAdni13z3l_nch7WTJlxjcYyv2r6Q8iGg1AYu5w=.933a0b6b-204f-4936-8834-36ac1e86f6fb@github.com> Message-ID: <9XPayJVNS5BLMLGJOqltwBL5pp7cMEoyVudVcQNE4wQ=.aeb39545-c6cc-4fb1-b039-3a524577e322@github.com> On Thu, 4 Sep 2025 18:25:39 GMT, Coleen Phillimore wrote: >> The ExclusionCheckCandidates table contains all (recursive) supertypes -- E.g., its `add_candidate(k)` method calls `add_candidate(k->java_super())`. > > But what about k->java_super()->java_super() ? Where is that added? `ExclusionCheckCandidates::add_candidate()` is a recursive function so it eventually adds all java_supers up to Object. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2323108439 From ayang at openjdk.org Thu Sep 4 18:36:44 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 4 Sep 2025 18:36:44 GMT Subject: RFR: 8366897: RBTreeTest.IntrusiveCustomVerifyTest and RBTreeTest.CustomVerify tests fail on non-debug builds In-Reply-To: <8JYHeuODfe5hncNqJ0umyVKAZInbAbhtLcDtjaFx_Ok=.e41aa81d-fc29-4307-b7ce-10f32ca765f4@github.com> References: <4Q9basn6SqntiFje8eCjzGhdhz3YBfKELVAzze3CiVM=.06ff2e5b-bdca-4544-8a0b-52e4a0f98ab6@github.com> <8JYHeuODfe5hncNqJ0umyVKAZInbAbhtLcDtjaFx_Ok=.e41aa81d-fc29-4307-b7ce-10f32ca765f4@github.com> Message-ID: On Thu, 4 Sep 2025 18:01:08 GMT, Casper Norrbin wrote: > It has no side effect, and is strictly used for node comparisons. I see; seems a bit fragile though -- it's not obvious that this closure must be side-effect free. Anyway, this fix is trivial enough; feel free to merge to reduce CI noise. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27097#issuecomment-3255049280 From cnorrbin at openjdk.org Thu Sep 4 19:03:48 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 4 Sep 2025 19:03:48 GMT Subject: Integrated: 8366897: RBTreeTest.IntrusiveCustomVerifyTest and RBTreeTest.CustomVerify tests fail on non-debug builds In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 14:04:39 GMT, Casper Norrbin wrote: > #26981 introduced the possibility to supply the red-black tree with a custom verifier, however the call to this verifier was inside an assert, meaning it wasn't called for all builds. This results in two gtests failing. > > This fix moves the call outside the assert, and then checks the result instead. > > Testing: > - Local gtest testing > - Oracle tier 1 This pull request has now been integrated. Changeset: 945aaf89 Author: Casper Norrbin URL: https://git.openjdk.org/jdk/commit/945aaf893219f9ead94fd8aae4994f7b520f64bf Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8366897: RBTreeTest.IntrusiveCustomVerifyTest and RBTreeTest.CustomVerify tests fail on non-debug builds Reviewed-by: ayang ------------- PR: https://git.openjdk.org/jdk/pull/27097 From cnorrbin at openjdk.org Thu Sep 4 19:03:47 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 4 Sep 2025 19:03:47 GMT Subject: RFR: 8366897: RBTreeTest.IntrusiveCustomVerifyTest and RBTreeTest.CustomVerify tests fail on non-debug builds In-Reply-To: References: <4Q9basn6SqntiFje8eCjzGhdhz3YBfKELVAzze3CiVM=.06ff2e5b-bdca-4544-8a0b-52e4a0f98ab6@github.com> <8JYHeuODfe5hncNqJ0umyVKAZInbAbhtLcDtjaFx_Ok=.e41aa81d-fc29-4307-b7ce-10f32ca765f4@github.com> Message-ID: On Thu, 4 Sep 2025 18:34:20 GMT, Albert Mingkun Yang wrote: > I see; seems a bit fragile though -- it's not obvious that this closure must be side-effect free. I can understand that. But seeing as it's a one-line lambda in the function calling `verify`, I think it's mostly fine. Thanks for reviewing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27097#issuecomment-3255159238 From coleenp at openjdk.org Thu Sep 4 19:15:44 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 4 Sep 2025 19:15:44 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v7] In-Reply-To: References: Message-ID: <6ixL4xaZ_K4ZH4yCSdNeuThvw6_StFir9RFPx5ZIhn0=.a7047e72-6789-4833-986c-4bc3210a4608@github.com> On Mon, 1 Sep 2025 01:27:24 GMT, Ioi Lam wrote: >> During the assembly phase of the AOT cache, we link and verify all classes that were loaded during the training run. When verifying a class like this: >> >> >> class X { >> A getA() { return new B(); } // Verifier requires B to be a subtype of A. >> } >> >> >> We remember `A` and `B` as the "verification dependencies" of `X`. A class will be excluded from the AOT cache if any of its verification dependencies are excluded. For example, `X` will be excluded if >> >> - `A` fails verification >> - `B` is a signed class, which is always excluded from the AOT cache >> >> Conversely, if both `A` and `B` are included in the AOT cache, in the production run, they will be unconditionally loaded during VM bootstrap. Therefore, we can guarantee that the verification result computed for `X` will remain valid during the production run. >> >> Notes for reviewers: >> >> - The checks for verification dependencies are done inside `SystemDictionaryShared::check_exclusion_for_self_and_dependencies()`. These checks are done for both old and new classes. Since the dependencies can form a cyclic graph, the checks cannot be implemented with a simple recursion. See "Algorithm notes" in this function for details. >> - The verification dependencies for "new" classes are already stored in `DumpTimeClassInfo::_verifier_constraints`. >> - This PR adds code to record the verification dependencies for "old" classes into `DumpTimeClassInfo::_old_verifier_dependencies`, by intercepting `JVM_FindClassFromCaller()`. >> - This new functionality (store old classes in linked state) is available only when using the AOT cache. For simplicity, this functionality is not available with the old CDS workflows. See comments in `CDSConfig::is_preserving_verification_dependencies()`. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Added assert that SystemDictionaryShared::should_be_excluded() can only be called within CDS safepoint Another pass at reviewing. test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/BadNewClass2.jasm line 4: > 2: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. > 3: * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. > 4: */ This has the wrong copyright. test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/BadOldClass.jasm line 4: > 2: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. > 3: * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. > 4: */ Same here - wrong copyright. ------------- PR Review: https://git.openjdk.org/jdk/pull/26754#pullrequestreview-3186623704 PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2323186633 PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2323187801 From coleenp at openjdk.org Thu Sep 4 19:15:47 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 4 Sep 2025 19:15:47 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v4] In-Reply-To: <1y0xCycdMMkto_A7zYSbGYKJY_2AjnMv_uwyFya0kAg=.016425b2-06e3-48af-834d-0768d377121b@github.com> References: <1y0xCycdMMkto_A7zYSbGYKJY_2AjnMv_uwyFya0kAg=.016425b2-06e3-48af-834d-0768d377121b@github.com> Message-ID: On Mon, 1 Sep 2025 00:57:54 GMT, Ioi Lam wrote: >> src/hotspot/share/cds/runTimeClassInfo.hpp line 204: >> >>> 202: u4* old_verifier_dependencies() { >>> 203: assert(_num_old_verifier_dependencies > 0, "sanity"); >>> 204: return (u4*)(address(this) + old_verifier_dependencies_offset()); >> >> This seems like it should have a checked_cast<> around it rather than a plain cast. > > `checked_cast<>` only checks size difference of the source and target types, but here both are pointer types so they have the same size. I see. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2323112795 From coleenp at openjdk.org Thu Sep 4 19:15:46 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 4 Sep 2025 19:15:46 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v2] In-Reply-To: References: <5PF9YneXIfGjkmxmIY51Zr28yk9fA23dMPAEXcD-9Cc=.86bee7bf-ee81-4196-83e5-cd2b2b4c1ad6@github.com> Message-ID: On Thu, 4 Sep 2025 18:30:00 GMT, Coleen Phillimore wrote: >> I am not sure why there are two versions. They seem to be used at similar frequency (about 300 calls each). > > So there's add_verification_constraint for the new verifier and add_old_verification_dependency but are these the same sort of thing? Maybe the new name should be add_old_verification_constraint. Why is one a dependency and one's a constraint? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2323101578 From coleenp at openjdk.org Thu Sep 4 19:15:48 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 4 Sep 2025 19:15:48 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v5] In-Reply-To: <9XPayJVNS5BLMLGJOqltwBL5pp7cMEoyVudVcQNE4wQ=.aeb39545-c6cc-4fb1-b039-3a524577e322@github.com> References: <92PKx4jRrCfYgf-jdR3WG6Npmo6Sao4mtt2tAQdrv5U=.aeef13b1-2ab5-4fd7-af0d-6c9eab9a204d@github.com> <1WzJLDW8mkbrCvucRTvQCTHNzqcs_43-ay8XWS2PiC0=.da2d6fa8-c8da-41ec-98b3-8317ee0cec39@github.com> <4XCkBAdni13z3l_nch7WTJlxjcYyv2r6Q8iGg1AYu5w=.933a0b6b-204f-4936-8834-36ac1e86f6fb@github.com> <9XPayJVNS5BLMLGJOqltwBL5pp7cMEoyVudVcQNE4wQ=.aeb39545-c6cc-4fb1-b039-3a524577e322@github.com> Message-ID: On Thu, 4 Sep 2025 18:32:37 GMT, Ioi Lam wrote: >> But what about k->java_super()->java_super() ? Where is that added? > > `ExclusionCheckCandidates::add_candidate()` is a recursive function so it eventually adds all java_supers up to Object. Okay, I see add_candidate is recursive so should add everything in the hierarchy for the first 'k'. That makes a lot of sense. Now why does this check_dependency_exclusion have to check super and interfaces, if you already have all the super and interfaces in the list of candidates to check? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2323130295 From coleenp at openjdk.org Thu Sep 4 19:15:49 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 4 Sep 2025 19:15:49 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v5] In-Reply-To: <1WzJLDW8mkbrCvucRTvQCTHNzqcs_43-ay8XWS2PiC0=.da2d6fa8-c8da-41ec-98b3-8317ee0cec39@github.com> References: <92PKx4jRrCfYgf-jdR3WG6Npmo6Sao4mtt2tAQdrv5U=.aeef13b1-2ab5-4fd7-af0d-6c9eab9a204d@github.com> <1WzJLDW8mkbrCvucRTvQCTHNzqcs_43-ay8XWS2PiC0=.da2d6fa8-c8da-41ec-98b3-8317ee0cec39@github.com> Message-ID: On Mon, 1 Sep 2025 00:57:33 GMT, Ioi Lam wrote: >> src/hotspot/share/classfile/systemDictionaryShared.cpp line 542: >> >>> 540: } >>> 541: >>> 542: Klass* SystemDictionaryShared::find_verification_dependency_bottom_class(InstanceKlass* k, Symbol* dependency_class_name) { >> >> Why don't you have this return InstanceKlasss so that the callers don't have to check the same thing. What you want is the bottom InstanceKlass so for [Lfoo; - you want foo. Since class foo is the thing you care about. Maybe the comment about why you return nullptr from check_verification_dependency_exclusion() could be here instead. >> >> These names are a bit repetative, can you just call this find_bottom_instance_klass() and maybe it could be used for other things too. > > The problem is if `k` is the ObjArrayKlass of `[[I`, then `k->bottom_klass()` is `[I`, which is not an InstanceKlass. If we change the return type to `InstanceKlass*`, then we would have to return `nullptr`. However, that would make it more difficult to explain the following case (I've updated the comments): > > > bool SystemDictionaryShared::check_verification_dependency_exclusion(InstanceKlass* k, Symbol* dependency_class_name) { > Klass* dependency_bottom_class = find_verification_dependency_bottom_class(k, dependency_class_name); > if (dependency_bottom_class == nullptr) { > // Dependency_class_name has not yet been loaded. This happens when the new verifier was checking > // if dependency_class_name is assignable to an interface, and found the answer without resolving > // dependency_class_name. > // > // Since this class is not even loaded, it surely cannot be excluded. > return false; > } This doesn't seem bad. You could say "Not loaded or bottom class is not an instanceKlass." Do you need to say what the verifier was doing here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2323224309 From coleenp at openjdk.org Thu Sep 4 19:15:46 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 4 Sep 2025 19:15:46 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v2] In-Reply-To: <5PF9YneXIfGjkmxmIY51Zr28yk9fA23dMPAEXcD-9Cc=.86bee7bf-ee81-4196-83e5-cd2b2b4c1ad6@github.com> References: <5PF9YneXIfGjkmxmIY51Zr28yk9fA23dMPAEXcD-9Cc=.86bee7bf-ee81-4196-83e5-cd2b2b4c1ad6@github.com> Message-ID: On Tue, 19 Aug 2025 23:31:19 GMT, Ioi Lam wrote: >> src/hotspot/share/cds/dumpTimeClassInfo.cpp line 90: >> >>> 88: _old_verifier_dependencies = new (mtClass) GrowableArray(4, mtClass); >>> 89: } >>> 90: _old_verifier_dependencies->append(name); >> >> I wonder why there's append and push that do the same thing in GrowableArray. I'm used to seeing push(). > > I am not sure why there are two versions. They seem to be used at similar frequency (about 300 calls each). So there's add_verification_constraint for the new verifier and add_old_verification_dependency but are these the same sort of thing? Maybe the new name should be add_old_verification_constraint. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2323100409 From coleenp at openjdk.org Thu Sep 4 19:15:50 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 4 Sep 2025 19:15:50 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v5] In-Reply-To: References: <92PKx4jRrCfYgf-jdR3WG6Npmo6Sao4mtt2tAQdrv5U=.aeef13b1-2ab5-4fd7-af0d-6c9eab9a204d@github.com> Message-ID: On Mon, 1 Sep 2025 00:57:36 GMT, Ioi Lam wrote: >> I would kind of prefer old_verifier_dependency rather than old_verification - the latter seems to say that we had some verification that is no longer valid. old_verifier makes it clearer it's for old classfiles and the old verifier. Also 'verification' is used for the regular verifier so it's less of a same name. > >> The caller just did this, didn't it? > > There is a different caller (SystemDictionaryShared::copy_verification_info_from_preimage) which has only the class name. > >> I would kind of prefer old_verifier_dependency > > The current code is kind of messy. For example, we have _verifier_constraints in DumpTimeClassInfo, but other places use "verification_constraints". > > Maybe I should rename all old and new cases of verification_xxx to verifier_xxx? That's why I'm confused, there's one in DumpTimeInfo and another one in SystemDictionaryShared. Shouldn't this call find_{verification_dependency}_bottom_klass? Looks like the same code. I feel like you want to generalize this case where you try to find the underlying InstanceKlass. And pass the class_loader rather than getting if from 'k'. And define it in SystemDictionary under the find_instance_or_array_klass. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2323151811 From coleenp at openjdk.org Thu Sep 4 19:15:50 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 4 Sep 2025 19:15:50 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v5] In-Reply-To: References: <92PKx4jRrCfYgf-jdR3WG6Npmo6Sao4mtt2tAQdrv5U=.aeef13b1-2ab5-4fd7-af0d-6c9eab9a204d@github.com> Message-ID: <_8IYdc2zRT9o2O2nK2zQxHoWVbWmq-SfN3jU1ddWXA4=.45abc719-7bb9-4023-ae6f-b8bcd1a6cd0d@github.com> On Thu, 4 Sep 2025 18:46:56 GMT, Coleen Phillimore wrote: >>> The caller just did this, didn't it? >> >> There is a different caller (SystemDictionaryShared::copy_verification_info_from_preimage) which has only the class name. >> >>> I would kind of prefer old_verifier_dependency >> >> The current code is kind of messy. For example, we have _verifier_constraints in DumpTimeClassInfo, but other places use "verification_constraints". >> >> Maybe I should rename all old and new cases of verification_xxx to verifier_xxx? > > That's why I'm confused, there's one in DumpTimeInfo and another one in SystemDictionaryShared. > > Shouldn't this call find_{verification_dependency}_bottom_klass? Looks like the same code. I feel like you want to generalize this case where you try to find the underlying InstanceKlass. And pass the class_loader rather than getting if from 'k'. And define it in SystemDictionary under the find_instance_or_array_klass. I think changing them to verifier rather than verification makes sense since it means the verifier not verification in general. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2323159170 From phh at openjdk.org Thu Sep 4 19:38:43 2025 From: phh at openjdk.org (Paul Hohensee) Date: Thu, 4 Sep 2025 19:38:43 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands [v2] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 21:54:13 GMT, David Holmes wrote: >> Kerem Kat has updated the pull request incrementally with two additional commits since the last revision: >> >> - add include for global placement new >> - remove onJavaThread and check JavaThread::active null where needed > > src/hotspot/share/utilities/debug.cpp line 341: > >> 339: } >> 340: return true; >> 341: } > > I don't think we need this. The commands that require a JavaThread should be checking that directly themselves. Typically we assume/expect the person debugging to know what they are dealing with and use the appropriate commands. @dholmes-ora, are you sure you want this level of code duplication? As is it, the latest version duplicates the following 3 times if (!c.onThread()) return; JavaThread* p = JavaThread::active(); if (p == nullptr) { tty->print_cr("Failed: JavaThread::active is null"); return; } tty->print(" for thread: "); p->print(); tty->cr(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27033#discussion_r2323292717 From iklam at openjdk.org Thu Sep 4 21:20:19 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 4 Sep 2025 21:20:19 GMT Subject: RFR: 8366477: Refactor AOT-related flag bits in klass.hpp [v2] In-Reply-To: References: <_A85cHVnrlEWRJr9wSJ46gnVPYbFUCM1GzxNO-vlFiU=.a394197e-64dc-4dae-9480-c0336bc52ff0@github.com> Message-ID: On Thu, 4 Sep 2025 03:28:39 GMT, Chen Liang wrote: >> src/hotspot/share/oops/klass.hpp line 184: >> >>> 182: _verified_at_dump_time = 1 << 3, >>> 183: _has_archived_enum_objs = 1 << 4, >>> 184: _is_generated_shared_class = 1 << 5, // This class was not loaded from a classfile in the module image >> >> does it make sense to rename `_is_generated_shared_class` to `_is_generated_aot_class`? > > `_is_aot_generated_class` sounds better. I changed it to `_is_aot_generated_class` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27018#discussion_r2323553734 From dlong at openjdk.org Thu Sep 4 21:22:59 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 4 Sep 2025 21:22:59 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v2] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Mon, 1 Sep 2025 09:51:38 GMT, Andrew Dinn wrote: > I don't believe we will ever traverse the stack while it is in that state because it only happens transiently when we are returning into the deopt handler. Actually, I think that is actually the more common case, with the return PC being patched but the callee hasn't returned to it yet. However, we could probably make the "entry point" be at the end of stub, and emit a `goto` to the beginning. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3251419068 From iklam at openjdk.org Thu Sep 4 22:01:51 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 4 Sep 2025 22:01:51 GMT Subject: RFR: 8366477: Refactor AOT-related flag bits in klass.hpp [v3] In-Reply-To: References: Message-ID: <-FWCU8wOAOj3jKZmKMbezP7WzU3RCX0NW_zkg_Vlq7w=.173d7912-89f0-474a-8e19-f8d3fd3fecd9@github.com> > This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology): > > 1. Rename from `Klass::_shared_class_flags` to `Klass::_aot_class_flags` > 2. Move `_has_aot_safe_initializer` and `_is_runtime_setup_required` from `InstanceKlassFlags` (has run out of bits) to here (we still have 7 extra bits left), to accommodate future `@AOTXXX` annotations. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - @liach and @ashu-mehra comment: Renamed Klass::_is_generated_shared_class -> _is_aot_generated_class - Merge branch 'master' into 8366477-refactor-aot-related-flag-bits-in-klass-hpp.saved - Merge branch '8366475-rename-metaspace-shared-to-aot-metaspace' into 8366477-refactor-aot-related-flag-bits-in-klass-hpp - removed unnecessary includes - Redo changes in comments and tests - Merge branch '8366474-rename_metaspaceobj_is_shared_to_in_aot_cache' into 8366475-rename-metaspace-shared-to-aot-metaspace - Removed MetaspaceShared -> AOTMetaspace changes that are intended for https://github.com/openjdk/jdk/pull/27017 - 8366477: Refactor AOT-related flag bits in klass.hpp - Rename MetaspaceShared -> AOTMetaspace - 8366474: Rename MetaspaceObj::is_shared() to MetaspaceObj::in_aot_cache() ------------- Changes: https://git.openjdk.org/jdk/pull/27018/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27018&range=02 Stats: 60 lines in 7 files changed: 20 ins; 10 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/27018.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27018/head:pull/27018 PR: https://git.openjdk.org/jdk/pull/27018 From cstein at openjdk.org Thu Sep 4 22:01:57 2025 From: cstein at openjdk.org (Christian Stein) Date: Thu, 4 Sep 2025 22:01:57 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v4] In-Reply-To: References: Message-ID: <6p7ncBylItu9HEeCINmqu_JFoL6zNXwJuSQaZoQ0J2I=.451526e1-d918-4fee-b1a7-e8193da61545@github.com> > Please review the change to update to using jtreg 8. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. Christian Stein 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 five additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 - Update to use correct library directories See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files - 8361950: Set required version to 8+2 - 8361950: Update to use jtreg 8 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26261/files - new: https://git.openjdk.org/jdk/pull/26261/files/56006240..12b0d0f5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26261&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26261&range=02-03 Stats: 20940 lines in 1016 files changed: 14715 ins; 2669 del; 3556 mod Patch: https://git.openjdk.org/jdk/pull/26261.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26261/head:pull/26261 PR: https://git.openjdk.org/jdk/pull/26261 From lmesnik at openjdk.org Thu Sep 4 22:41:59 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 4 Sep 2025 22:41:59 GMT Subject: RFR: 8365937: post_method_exit might incorrectly set was_popped_by_exception and value in the middle of stack unwinding [v4] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 15:56:36 GMT, Patricio Chilano Mateo wrote: >> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: >> >> - Apply suggestions from code review >> >> Co-authored-by: Patricio Chilano Mateo >> - Update test/hotspot/jtreg/serviceability/jvmti/events/MethodExit/PendingException/libTestMethodExitWithPendingException.cpp >> >> Co-authored-by: Patricio Chilano Mateo > > Marked as reviewed by pchilanomate (Reviewer). @pchilano, @dholmes-ora, Thank you for review and feedback! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26886#issuecomment-3256019766 From lmesnik at openjdk.org Thu Sep 4 22:55:28 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 4 Sep 2025 22:55:28 GMT Subject: Integrated: 8365937: post_method_exit might incorrectly set was_popped_by_exception and value in the middle of stack unwinding In-Reply-To: References: Message-ID: <9SuZtN8NJg0ACV05O56wHVaPIUgRgdiZtD4oPKuY1EM=.394f09ed-1b1d-4e93-b91e-96f488470b43@github.com> On Thu, 21 Aug 2025 15:43:50 GMT, Leonid Mesnik wrote: > The void `JvmtiExport::post_method_exit(JavaThread* thread, Method* method, frame current_frame) `calculates > `bool exception_exit = state->is_exception_detected() && !state->is_exception_caught();` > to find if method exit normally or by exception. > However, JvmtiExport::post_method_exit( method is not called at all in the case of exception. See > `void JvmtiExport::notice_unwind_due_to_exception(JavaThread *thread, Method* method, address location, oop exception, bool in_handler_frame)` > where post_method_exit_inner is called directly. > > The `exception_exit` is true when exception is processed and the current method is called in the middle of stack unwinding. > > > The fix was a part of > https://github.com/openjdk/jdk/pull/26713 > for > https://bugs.openjdk.org/browse/JDK-8365192 This pull request has now been integrated. Changeset: b7b64bb6 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56 Stats: 338 lines in 5 files changed: 320 ins; 7 del; 11 mod 8365937: post_method_exit might incorrectly set was_popped_by_exception and value in the middle of stack unwinding Reviewed-by: dholmes, pchilanomate ------------- PR: https://git.openjdk.org/jdk/pull/26886 From dholmes at openjdk.org Fri Sep 5 00:17:08 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 5 Sep 2025 00:17:08 GMT Subject: RFR: 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown [v2] In-Reply-To: References: <3TJnBvDoAPUf4p2e8Y0vpckfm3v8e31cKKwfOeyRnnM=.34c016f4-419d-4dd6-9102-b112a7423f7b@github.com> Message-ID: <0MgFaYfqd6yOPibxkeP8KTbEn7Xpy7JGu7R_yGLN8uk=.31dc1407-0954-4e6a-b3df-9b2dc23f684c@github.com> On Thu, 4 Sep 2025 08:47:57 GMT, Thomas Stuefe wrote: >> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' into 8364735-xtty >> - 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown > > Okay. I would like it more if these objects were immortal. > > Side note, I would love some concept of immortal objects at some point; a way to clearly indicate (and assert) that we intend to keep an object around forever. Thanks for the review @tstuefe . In this case it not just dealing with immortality but also the necessary cleanup at shutdown. @jdksjolen thanks for the remind about `DeferredStatic` - I have some global Semaphores that need protecting. :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26832#issuecomment-3256559189 From dholmes at openjdk.org Fri Sep 5 00:30:22 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 5 Sep 2025 00:30:22 GMT Subject: Integrated: 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown In-Reply-To: <3TJnBvDoAPUf4p2e8Y0vpckfm3v8e31cKKwfOeyRnnM=.34c016f4-419d-4dd6-9102-b112a7423f7b@github.com> References: <3TJnBvDoAPUf4p2e8Y0vpckfm3v8e31cKKwfOeyRnnM=.34c016f4-419d-4dd6-9102-b112a7423f7b@github.com> Message-ID: On Tue, 19 Aug 2025 00:11:38 GMT, David Holmes wrote: > `ostream_exit` was deleting the stream underlying the `xtty` prior to nulling the `xtty` global variable, resulting in a use-after-free-error. Due to races during VM shutdown we cannot make use of `xtty` perfectly safe, but we can certainly narrow the window during which use-after-free is possible. > > Testing: > - tiers 1-3 sanity > > Thanks This pull request has now been integrated. Changeset: 40a60252 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/40a602520ba1a4682213b74e6f2a6f5a6e35d839 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod 8364735: [asan] heap-use-after-free error detected in defaultStream::writer during VM shutdown Reviewed-by: jsjolen, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/26832 From ysuenaga at openjdk.org Fri Sep 5 01:26:25 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Fri, 5 Sep 2025 01:26:25 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU In-Reply-To: References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> Message-ID: On Thu, 4 Sep 2025 15:06:08 GMT, Erik Gahlin wrote: > If a value is missing, emit jmc_undefined_long in event.set_cores(...), so it will show up as N/A in both JMC and the JFR tool. It couldn't for now because `cores` is declared as `uint`. I checked generated code from `metadata.xml`, the field as declared as `uint` (32 bit), so we cannot store `jmc_undefined_long` as `long`. class EventCPUInformation : public JfrEvent { private: const char* _cpu; const char* _description; unsigned _sockets; unsigned _cores; unsigned _hwThreads; But I agree with @egahlin to show up "N/A" in this case. I think it is the most simple way to change data type to `long` for number of CPU cores in `metadata.xml`. Can we do that? I concern the impact for JFR recording data format. As an another option, we can update `EventPrintWriter::getUnsigned` to handle `unsigned int` - it might be reasonable to fix this problem. Which solution is better? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3256751516 From lmesnik at openjdk.org Fri Sep 5 01:56:21 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 5 Sep 2025 01:56:21 GMT Subject: Withdrawn: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state In-Reply-To: References: Message-ID: <9-gVitzg7qJYfQq3IdXBC3nrlF8Jj9SRrdJN12Y9JXg=.30ff87e7-ae2c-4ba4-9c3b-e6a581705a41@github.com> On Sat, 9 Aug 2025 20:30:14 GMT, Leonid Mesnik wrote: > The method > get_jvmti_thread_state() > should be called only while thread is in vm state. > > The post_method_exit is doing some preparation before switching to vm state. This cause issues if thread is needed to initialize jvmti thread state. > > The fix was found using jvmti stress agent and thus no additional regression test is required. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/26713 From asmehra at openjdk.org Fri Sep 5 02:10:23 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 5 Sep 2025 02:10:23 GMT Subject: RFR: 8366477: Refactor AOT-related flag bits in klass.hpp [v3] In-Reply-To: <-FWCU8wOAOj3jKZmKMbezP7WzU3RCX0NW_zkg_Vlq7w=.173d7912-89f0-474a-8e19-f8d3fd3fecd9@github.com> References: <-FWCU8wOAOj3jKZmKMbezP7WzU3RCX0NW_zkg_Vlq7w=.173d7912-89f0-474a-8e19-f8d3fd3fecd9@github.com> Message-ID: <_WLk_1RdefXU-IFSEQYOQ4bD-gOVX5pFcNFfRbnA8OU=.22f7797e-fcb3-47f0-a230-7a0d63564789@github.com> On Thu, 4 Sep 2025 22:01:51 GMT, Ioi Lam wrote: >> This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology): >> >> 1. Rename from `Klass::_shared_class_flags` to `Klass::_aot_class_flags` >> 2. Move `_has_aot_safe_initializer` and `_is_runtime_setup_required` from `InstanceKlassFlags` (has run out of bits) to here (we still have 7 extra bits left), to accommodate future `@AOTXXX` annotations. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - @liach and @ashu-mehra comment: Renamed Klass::_is_generated_shared_class -> _is_aot_generated_class > - Merge branch 'master' into 8366477-refactor-aot-related-flag-bits-in-klass-hpp.saved > - Merge branch '8366475-rename-metaspace-shared-to-aot-metaspace' into 8366477-refactor-aot-related-flag-bits-in-klass-hpp > - removed unnecessary includes > - Redo changes in comments and tests > - Merge branch '8366474-rename_metaspaceobj_is_shared_to_in_aot_cache' into 8366475-rename-metaspace-shared-to-aot-metaspace > - Removed MetaspaceShared -> AOTMetaspace changes that are intended for https://github.com/openjdk/jdk/pull/27017 > - 8366477: Refactor AOT-related flag bits in klass.hpp > - Rename MetaspaceShared -> AOTMetaspace > - 8366474: Rename MetaspaceObj::is_shared() to MetaspaceObj::in_aot_cache() lgtm ------------- Marked as reviewed by asmehra (Committer). PR Review: https://git.openjdk.org/jdk/pull/27018#pullrequestreview-3187789942 From iklam at openjdk.org Fri Sep 5 04:15:38 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 5 Sep 2025 04:15:38 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v8] In-Reply-To: References: Message-ID: > During the assembly phase of the AOT cache, we link and verify all classes that were loaded during the training run. When verifying a class like this: > > > class X { > A getA() { return new B(); } // Verifier requires B to be a subtype of A. > } > > > We remember `A` and `B` as the "verification dependencies" of `X`. A class will be excluded from the AOT cache if any of its verification dependencies are excluded. For example, `X` will be excluded if > > - `A` fails verification > - `B` is a signed class, which is always excluded from the AOT cache > > Conversely, if both `A` and `B` are included in the AOT cache, in the production run, they will be unconditionally loaded during VM bootstrap. Therefore, we can guarantee that the verification result computed for `X` will remain valid during the production run. > > Notes for reviewers: > > - The checks for verification dependencies are done inside `SystemDictionaryShared::check_exclusion_for_self_and_dependencies()`. These checks are done for both old and new classes. Since the dependencies can form a cyclic graph, the checks cannot be implemented with a simple recursion. See "Algorithm notes" in this function for details. > - The verification dependencies for "new" classes are already stored in `DumpTimeClassInfo::_verifier_constraints`. > - This PR adds code to record the verification dependencies for "old" classes into `DumpTimeClassInfo::_old_verifier_dependencies`, by intercepting `JVM_FindClassFromCaller()`. > - This new functionality (store old classes in linked state) is available only when using the AOT cache. For simplicity, this functionality is not available with the old CDS workflows. See comments in `CDSConfig::is_preserving_verification_dependencies()`. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - Simplified SystemDictionaryShared::add_old_verification_constraint; added more test cases - Fixed copyright - Simplified code -- (1) store old verification constraints in the same array as for the new verifier; (2) renamed "verification dependencies" -> "verification constraints"; (3) avoid using "cds" in new method names - Merge branch 'master' into 8317269-store-old-classes-in-linked-state-in-aot-cache - Added assert that SystemDictionaryShared::should_be_excluded() can only be called within CDS safepoint - updated comments - Merge branch 'master' into 8317269-store-old-classes-in-linked-state-in-aot-cache - @matias9927 comments: fixed typos - clean up; removed unrelated change - Cleaned up iterate_verification_dependency_names so a return value of false from means early termination (similar to HashTable::iterate()) - ... and 5 more: https://git.openjdk.org/jdk/compare/945aaf89...526a0925 ------------- Changes: https://git.openjdk.org/jdk/pull/26754/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26754&range=07 Stats: 1404 lines in 35 files changed: 1310 ins; 22 del; 72 mod Patch: https://git.openjdk.org/jdk/pull/26754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26754/head:pull/26754 PR: https://git.openjdk.org/jdk/pull/26754 From iklam at openjdk.org Fri Sep 5 04:38:10 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 5 Sep 2025 04:38:10 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v5] In-Reply-To: References: <92PKx4jRrCfYgf-jdR3WG6Npmo6Sao4mtt2tAQdrv5U=.aeef13b1-2ab5-4fd7-af0d-6c9eab9a204d@github.com> <1WzJLDW8mkbrCvucRTvQCTHNzqcs_43-ay8XWS2PiC0=.da2d6fa8-c8da-41ec-98b3-8317ee0cec39@github.com> <4XCkBAdni13z3l_nch7WTJlxjcYyv2r6Q8iGg1AYu5w=.933a0b6b-204f-4936-8834-36ac1e86f6fb@github.com> <9XPayJVNS5BLMLGJOqltwBL5pp7cMEoyVudVcQNE4wQ=.aeb39545-c6cc-4fb1-b039-3a524577e322@github.com> Message-ID: On Thu, 4 Sep 2025 18:39:22 GMT, Coleen Phillimore wrote: >> `ExclusionCheckCandidates::add_candidate()` is a recursive function so it eventually adds all java_supers up to Object. > > Okay, I see add_candidate is recursive so should add everything in the hierarchy for the first 'k'. That makes a lot of sense. Now why does this check_dependency_exclusion have to check super and interfaces, if you already have all the super and interfaces in the list of candidates to check? Imaging we have only 3 candidates, Child, Parent and GrandParent. Initially only GrandParent is excluded when we enter the the `while` loop inside `check_exclusion_for_self_and_dependencies`. In the loop iteration, Parent is marked excluded (it's super has been excluded). We found a new exclusion. So we run the loop again. In the second iteration, we mark Child as excluded. We run the loop again. In the third iteration, we found no new exclusion, so we exit the loop. > if you already have all the super and interfaces in the list of candidates The list of candidate form a directed graph. Exclusion is propagated through the edges of this graph. `k->super()` is one of such edges. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2324069415 From iklam at openjdk.org Fri Sep 5 04:38:11 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 5 Sep 2025 04:38:11 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v5] In-Reply-To: References: <92PKx4jRrCfYgf-jdR3WG6Npmo6Sao4mtt2tAQdrv5U=.aeef13b1-2ab5-4fd7-af0d-6c9eab9a204d@github.com> <1WzJLDW8mkbrCvucRTvQCTHNzqcs_43-ay8XWS2PiC0=.da2d6fa8-c8da-41ec-98b3-8317ee0cec39@github.com> Message-ID: On Thu, 4 Sep 2025 19:12:08 GMT, Coleen Phillimore wrote: >> The problem is if `k` is the ObjArrayKlass of `[[I`, then `k->bottom_klass()` is `[I`, which is not an InstanceKlass. If we change the return type to `InstanceKlass*`, then we would have to return `nullptr`. However, that would make it more difficult to explain the following case (I've updated the comments): >> >> >> bool SystemDictionaryShared::check_verification_dependency_exclusion(InstanceKlass* k, Symbol* dependency_class_name) { >> Klass* dependency_bottom_class = find_verification_dependency_bottom_class(k, dependency_class_name); >> if (dependency_bottom_class == nullptr) { >> // Dependency_class_name has not yet been loaded. This happens when the new verifier was checking >> // if dependency_class_name is assignable to an interface, and found the answer without resolving >> // dependency_class_name. >> // >> // Since this class is not even loaded, it surely cannot be excluded. >> return false; >> } > > This doesn't seem bad. You could say "Not loaded or bottom class is not an instanceKlass." Do you need to say what the verifier was doing here? Usually not finding the constraint should lead to a rejection. However, this code does the opposite (it accepts a class if its constraint is not loaded), so a detailed explanation is needed. (I've updated the comments again). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2324069523 From iklam at openjdk.org Fri Sep 5 04:38:12 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 5 Sep 2025 04:38:12 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v5] In-Reply-To: <_8IYdc2zRT9o2O2nK2zQxHoWVbWmq-SfN3jU1ddWXA4=.45abc719-7bb9-4023-ae6f-b8bcd1a6cd0d@github.com> References: <92PKx4jRrCfYgf-jdR3WG6Npmo6Sao4mtt2tAQdrv5U=.aeef13b1-2ab5-4fd7-af0d-6c9eab9a204d@github.com> <_8IYdc2zRT9o2O2nK2zQxHoWVbWmq-SfN3jU1ddWXA4=.45abc719-7bb9-4023-ae6f-b8bcd1a6cd0d@github.com> Message-ID: On Thu, 4 Sep 2025 18:49:12 GMT, Coleen Phillimore wrote: >> That's why I'm confused, there's one in DumpTimeInfo and another one in SystemDictionaryShared. >> >> Shouldn't this call find_{verification_dependency}_bottom_klass? Looks like the same code. I feel like you want to generalize this case where you try to find the underlying InstanceKlass. And pass the class_loader rather than getting if from 'k'. And define it in SystemDictionary under the find_instance_or_array_klass. > > I think changing them to verifier rather than verification makes sense since it means the verifier not verification in general. For simplification, I've updated the code to the same storage for both old and new verification constraints. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26754#discussion_r2324069587 From iklam at openjdk.org Fri Sep 5 04:43:46 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 5 Sep 2025 04:43:46 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v9] In-Reply-To: References: Message-ID: > During the assembly phase of the AOT cache, we link and verify all classes that were loaded during the training run. When verifying a class like this: > > > class X { > A getA() { return new B(); } // Verifier requires B to be a subtype of A. > } > > > We remember `A` and `B` as the "verification dependencies" of `X`. A class will be excluded from the AOT cache if any of its verification dependencies are excluded. For example, `X` will be excluded if > > - `A` fails verification > - `B` is a signed class, which is always excluded from the AOT cache > > Conversely, if both `A` and `B` are included in the AOT cache, in the production run, they will be unconditionally loaded during VM bootstrap. Therefore, we can guarantee that the verification result computed for `X` will remain valid during the production run. > > Notes for reviewers: > > - The checks for verification dependencies are done inside `SystemDictionaryShared::check_exclusion_for_self_and_dependencies()`. These checks are done for both old and new classes. Since the dependencies can form a cyclic graph, the checks cannot be implemented with a simple recursion. See "Algorithm notes" in this function for details. > - The verification dependencies for "new" classes are already stored in `DumpTimeClassInfo::_verifier_constraints`. > - This PR adds code to record the verification dependencies for "old" classes into `DumpTimeClassInfo::_old_verifier_dependencies`, by intercepting `JVM_FindClassFromCaller()`. > - This new functionality (store old classes in linked state) is available only when using the AOT cache. For simplicity, this functionality is not available with the old CDS workflows. See comments in `CDSConfig::is_preserving_verification_dependencies()`. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: updated comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26754/files - new: https://git.openjdk.org/jdk/pull/26754/files/526a0925..2c888c5c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26754&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26754&range=07-08 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26754.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26754/head:pull/26754 PR: https://git.openjdk.org/jdk/pull/26754 From lmesnik at openjdk.org Fri Sep 5 06:29:32 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 5 Sep 2025 06:29:32 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state Message-ID: This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result. The related fix here: https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56 Hope fix became clarere now. There 2 problems in this post_meth_exit: 1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode. 2) The method `get_jvmti_thread_state` should be called when thread is in vm state only. The fix adds `post_method_exit_transition` to have single exit point with oop restoration. ------------- Commit messages: - comment is fixed. - fix Changes: https://git.openjdk.org/jdk/pull/27112/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27112&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365192 Stats: 65 lines in 2 files changed: 30 ins; 22 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/27112.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27112/head:pull/27112 PR: https://git.openjdk.org/jdk/pull/27112 From lmesnik at openjdk.org Fri Sep 5 06:40:31 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 5 Sep 2025 06:40:31 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v2] In-Reply-To: References: Message-ID: > This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result. > The related fix here: > https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56 > Hope fix became clarere now. > > There 2 problems in this post_meth_exit: > 1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode. > 2) The method `get_jvmti_thread_state` should be called when thread is in vm state only. > > The fix adds `post_method_exit_transition` to have single exit point with oop restoration. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27112/files - new: https://git.openjdk.org/jdk/pull/27112/files/c1de44f6..77c9c7a3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27112&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27112&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27112.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27112/head:pull/27112 PR: https://git.openjdk.org/jdk/pull/27112 From qpzhang at openjdk.org Fri Sep 5 07:37:58 2025 From: qpzhang at openjdk.org (Patrick Zhang) Date: Fri, 5 Sep 2025 07:37:58 GMT Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when UseBlockZeroing is false [v4] In-Reply-To: References: Message-ID: > Issue: > In AArch64 port, `UseBlockZeroing` is by default set to true and `BlockZeroingLowLimit` is initialized to 256. If `DC ZVA` is supported, `BlockZeroingLowLimit` is later updated to `4 * VM_Version::zva_length()`. When `UseBlockZeroing` is set to false, all related conditional checks should ignore `BlockZeroingLowLimit`. However, the function `MacroAssembler::zero_words(Register base, uint64_t cnt)` still evaluates the lower limit and bases its code generation logic on it, which seems to be an incomplete conditional check. > > This PR: > 1. Reset `BlockZeroingLowLimit` to `4 * VM_Version::zva_length()` or 256 with a warning message if it was manually configured from the default while `UseBlockZeroing` is disabled. > 2. Added necessary comments in `MacroAssembler::zero_words(Register base, uint64_t cnt)` and `MacroAssembler::zero_words(Register ptr, Register cnt)` to explain why we do not check `UseBlockZeroing` in the outer part of these functions. Instead, the decision is delegated to the stub function `zero_blocks`, which encapsulates the DC ZVA instructions and serves as the inner implementation of `zero_words`. This approach helps better control the increase in code cache size during array or object instance initialization. > 3. Added more testing sizes to `test/micro/org/openjdk/bench/vm/gc/RawAllocationRate.java` to better cover scenarios involving smaller arrays and objects.. > > Tests: > 1. Performance tests on the bundled JMH `vm.compiler.ClearMemory`, and `vm.gc.RawAllocationRate` (including `arrayTest` and `instanceTest`) showed no obvious regression. Negative tests with `jdk/bin/java -jar images/test/micro/benchmarks.jar RawAllocationRate.arrayTest_C1 -bm thrpt -gc false -wi 0 -w 30 -i 1 -r 30 -t 1 -f 1 -tu s -jvmArgs "-XX:-UseBlockZeroing -XX:BlockZeroingLowLimit=8" -p size=32` demonstrated good wall times on `zero_words_reg_imm` calls, as expected. > 2. Jtreg ter1 test on Ampere Altra, AmpereOne, Graviton2 and 3, tier2 on Altra. No new issues found. Passed tests of GHA Sanity Checks. Patrick Zhang has updated the pull request incrementally with one additional commit since the last revision: Check is_zva_enabled when resetting BlockZeroingLowLimit Signed-off-by: Patrick Zhang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26917/files - new: https://git.openjdk.org/jdk/pull/26917/files/22e72f49..f23abb94 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26917&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26917&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26917.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26917/head:pull/26917 PR: https://git.openjdk.org/jdk/pull/26917 From qpzhang at openjdk.org Fri Sep 5 07:41:10 2025 From: qpzhang at openjdk.org (Patrick Zhang) Date: Fri, 5 Sep 2025 07:41:10 GMT Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when UseBlockZeroing is false [v2] In-Reply-To: References: <79QlFmmh7CAbxtU89RNVbf8sRBE_u8TbDLA90FqWyEM=.4e8b48ac-21b5-4881-9ca0-29bc87bfe032@github.com> Message-ID: On Thu, 4 Sep 2025 09:37:21 GMT, Andrew Haley wrote: > OK, but please edit the claims at the top of this PR to respect the new reality. In particular, please state the test cases which are improved. Updated. Had a new change (https://github.com/openjdk/jdk/pull/26917/commits/f23abb9439398fa571da3c3b4ae17573c7f8ddd9) to set `BlockZeroingLowLimit` to **256** if `is_zva_enabled()` returns false, otherwise we would have 0 from `_zva_length`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26917#issuecomment-3257382267 From tschatzl at openjdk.org Fri Sep 5 08:39:11 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 5 Sep 2025 08:39:11 GMT Subject: RFR: 8366854: Extend jtreg failure handler with THP info [v2] In-Reply-To: References: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> Message-ID: On Thu, 4 Sep 2025 07:49:56 GMT, Stefan Karlsson wrote: >> I propose that we also dump /proc/meminfo, /proc/vmstat, and /sys/kernel/mm/transparent_hugepage/{enabled, defrag} from the failure handler. >> >> This information has been helpful when investigating a failure where there was an unexpected lack of transparent huge pages. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Add shmem_enabled Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27086#pullrequestreview-3188490620 From iwalulya at openjdk.org Fri Sep 5 09:30:52 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 5 Sep 2025 09:30:52 GMT Subject: RFR: 8366881: Parallel: Obsolete HeapMaximumCompactionInterval [v2] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 09:30:45 GMT, Albert Mingkun Yang wrote: >> Remove a produce flag that controls maximum-compaction during a full-gc. The existing criteria, such as heap usage, old-gen density, are enough for deciding maximum-compaction. >> >> Test: tier1-3 > > Albert Mingkun Yang 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 three additional commits since the last revision: > > - review > - Merge branch 'master' into pgc-max-compaction-obsolete > - pgc-max-compaction-obsolete Looks good! ------------- Marked as reviewed by iwalulya (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27091#pullrequestreview-3188643316 From ayang at openjdk.org Fri Sep 5 09:30:45 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 5 Sep 2025 09:30:45 GMT Subject: RFR: 8366881: Parallel: Obsolete HeapMaximumCompactionInterval [v2] In-Reply-To: References: Message-ID: > Remove a produce flag that controls maximum-compaction during a full-gc. The existing criteria, such as heap usage, old-gen density, are enough for deciding maximum-compaction. > > Test: tier1-3 Albert Mingkun Yang 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 three additional commits since the last revision: - review - Merge branch 'master' into pgc-max-compaction-obsolete - pgc-max-compaction-obsolete ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27091/files - new: https://git.openjdk.org/jdk/pull/27091/files/d764377f..5f7fed4c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27091&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27091&range=00-01 Stats: 1996 lines in 93 files changed: 1199 ins; 205 del; 592 mod Patch: https://git.openjdk.org/jdk/pull/27091.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27091/head:pull/27091 PR: https://git.openjdk.org/jdk/pull/27091 From epeter at openjdk.org Fri Sep 5 09:31:17 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Fri, 5 Sep 2025 09:31:17 GMT Subject: RFR: 8363858: [perf] OptimizeFill may use wide set of intrinsics [v3] In-Reply-To: References: Message-ID: <8wvhGrQVCQ9FYFImv0_5p2ykY8fMi-xwOwPy22KJTPw=.58d19694-799a-446e-bec7-0be81c7f3e4e@github.com> On Thu, 4 Sep 2025 16:50:58 GMT, Vladimir Ivanov wrote: >> Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: >> >> 8363858: [perf] OptimizeFill may use wide set of intrinsics > > Thanks for your review! @IvaVladimir I'm sorry I missed this. Are there any performance benchmark numbers you can share for this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26974#issuecomment-3257697411 From azafari at openjdk.org Fri Sep 5 11:02:32 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 5 Sep 2025 11:02:32 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v3] In-Reply-To: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: <-eWIUjA4RqIgcpvFSyFxuiuganZpBqkMIdKSOVhnuMo=.79db2c26-5547-42fa-84d9-9bf5746728cf@github.com> > The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. > The acceptable value is changed to 64K. > > Tests: > linux-x64 tier1 Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: lowest can be equal to highest ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26955/files - new: https://git.openjdk.org/jdk/pull/26955/files/239df39b..76cf950e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26955.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26955/head:pull/26955 PR: https://git.openjdk.org/jdk/pull/26955 From aph at openjdk.org Fri Sep 5 11:25:10 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 5 Sep 2025 11:25:10 GMT Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when UseBlockZeroing is false [v4] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 07:37:58 GMT, Patrick Zhang wrote: >> Issue: >> In AArch64 port, `UseBlockZeroing` is by default set to true and `BlockZeroingLowLimit` is initialized to 256. If `DC ZVA` is supported, `BlockZeroingLowLimit` is later updated to `4 * VM_Version::zva_length()`. When `UseBlockZeroing` is set to false, all related conditional checks should ignore `BlockZeroingLowLimit`. However, the function `MacroAssembler::zero_words(Register base, uint64_t cnt)` still evaluates the lower limit and bases its code generation logic on it, which seems to be an incomplete conditional check. >> >> This PR: >> 1. Reset `BlockZeroingLowLimit` to `4 * VM_Version::zva_length()` or 256 with a warning message if it was manually configured from the default while `UseBlockZeroing` is disabled. >> 2. Added necessary comments in `MacroAssembler::zero_words(Register base, uint64_t cnt)` and `MacroAssembler::zero_words(Register ptr, Register cnt)` to explain why we do not check `UseBlockZeroing` in the outer part of these functions. Instead, the decision is delegated to the stub function `zero_blocks`, which encapsulates the DC ZVA instructions and serves as the inner implementation of `zero_words`. This approach helps better control the increase in code cache size during array or object instance initialization. >> 3. Added more testing sizes to `test/micro/org/openjdk/bench/vm/gc/RawAllocationRate.java` to better cover scenarios involving smaller arrays and objects.. >> >> Tests: >> 1. Performance tests on the bundled JMH `vm.compiler.ClearMemory`, and `vm.gc.RawAllocationRate` (including `arrayTest` and `instanceTest`) showed no obvious regression. Negative tests with `jdk/bin/java -jar images/test/micro/benchmarks.jar RawAllocationRate.arrayTest_C1 -bm thrpt -gc false -wi 0 -w 30 -i 1 -r 30 -t 1 -f 1 -tu s -jvmArgs "-XX:-UseBlockZeroing -XX:BlockZeroingLowLimit=8" -p size=32` demonstrated good wall times on `zero_words_reg_imm` calls, as expected. >> 2. Jtreg ter1 test on Ampere Altra, AmpereOne, Graviton2 and 3, tier2 on Altra. No new issues found. Passed tests of GHA Sanity Checks. > > Patrick Zhang has updated the pull request incrementally with one additional commit since the last revision: > > Check is_zva_enabled when resetting BlockZeroingLowLimit > > Signed-off-by: Patrick Zhang I can't see any statistically-significant improvement. Please tell us your test results and your test conditions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26917#issuecomment-3258006534 From vaivanov at openjdk.org Fri Sep 5 15:07:18 2025 From: vaivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 5 Sep 2025 15:07:18 GMT Subject: RFR: 8363858: [perf] OptimizeFill may use wide set of intrinsics [v3] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 22:11:17 GMT, Vladimir Ivanov wrote: >> Default mode should use OptimizeFill=true option for the SRF platform. > > Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8363858: [perf] OptimizeFill may use wide set of intrinsics Sorry, miss perf data here. You can find perf numbers in the PR https://github.com/openjdk/jdk/pull/26747 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26974#issuecomment-3258683753 From epeter at openjdk.org Fri Sep 5 15:12:24 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Fri, 5 Sep 2025 15:12:24 GMT Subject: RFR: 8363858: [perf] OptimizeFill may use wide set of intrinsics [v3] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 15:04:20 GMT, Vladimir Ivanov wrote: >> Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: >> >> 8363858: [perf] OptimizeFill may use wide set of intrinsics > > Sorry, miss perf data here. You can find perf numbers in the PR https://github.com/openjdk/jdk/pull/26747 @IvaVladimir I'm not sure at which numbers to look there. Because it looks like there you just report numbers of the current master (with this patch here already integrated) vs your new changes from https://github.com/openjdk/jdk/pull/26747. What I would have liked to see: performance before and after this patch here. Is https://github.com/openjdk/jdk/pull/26747 a simple RFE, or is it a fix for a regression? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26974#issuecomment-3258707670 From epeter at openjdk.org Fri Sep 5 15:14:12 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Fri, 5 Sep 2025 15:14:12 GMT Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays [v4] In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 15:29:16 GMT, Vladimir Ivanov wrote: >> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays > > Later alignment improve performance a little bit. Current numbers are: > SRF | size | jdk26 | patched with "+optFill" | patched/jdk26 > ArraysFill.testByteFill | 16 | 151937.634 | 175045.819 | 1.15 > ArraysFill.testByteFill | 31 | 125661.092 | 211226.668 | 1.68 > ArraysFill.testByteFill | 250 | 57599.684 | 123670.638 | 2.15 > ArraysFill.testByteFill | 266 | 44617.505 | 147306.352 | 3.30 > ArraysFill.testByteFill | 511 | 61541.499 | 129234.48 | 2.10 > ArraysFill.testByteFill | 2047 | 32073.997 | 41503.438 | 1.29 > ArraysFill.testByteFill | 2048 | 31729.263 | 41977.271 | 1.32 > ArraysFill.testByteFill | 8195 | 10620.363 | 10911.334 | 1.03 > ArraysFill.testIntFill | 16 | 144924.577 | 264101.45 | 1.82 > ArraysFill.testIntFill | 31 | 128877.207 | 211225.233 | 1.64 > ArraysFill.testIntFill | 250 | 73785.182 | 79204.674 | 1.07 > ArraysFill.testIntFill | 266 | 67703.171 | 75436.831 | 1.11 > ArraysFill.testIntFill | 511 | 39489.095 | 36011.078 | 0.91 > ArraysFill.testIntFill | 2047 | 11431.835 | 10509.545 | 0.92 > ArraysFill.testIntFill | 2048 | 11178.661 | 10882.991 | 0.97 > ArraysFill.testIntFill | 8195 | 2629.065 | 2601.19 | 0.99 > ArraysFill.testLongFill | 16 | 211218.892 | 211250.585 | 1.00 > ArraysFill.testLongFill | 31 | 133026.186 | 137374.876 | 1.03 > ArraysFill.testLongFill | 250 | 42907.745 | 42937.988 | 1.00 > ArraysFill.testLongFill | 266 | 41935.645 | 41920.801 | 1.00 > ArraysFill.testLongFill | 511 | 23217.606 | 23227.904 | 1.00 > ArraysFill.testLongFill | 2047 | 6083.099 | 6083.384 | 1.00 > ArraysFill.testLongFill | 2048 | 5751.203 | 5753.409 | 1.00 > ArraysFill.testLongFill | 8195 | 612.17 | 612.634 | 1.00 > ArraysFill.testShortFill | 16 | 151917.079 | 352122.571 | 2.32 > ArraysFill.testShortFill | 31 | 138000.217 | 226271.221 | 1.64 > ArraysFill.testShortFill | 250 | 58641.362 | 99043.571 | 1.69 > ArraysFill.testShortFill | 266 | 90499.649 | 93200.335 | 1.03 > ArraysFill.testShortFill | 511 | 64958.462 | 77930.734 | 1.20 > ArraysFill.testShortFill | 2047 | 21577.954 | 21210.006 | 0.98 > ArraysFill.testShortFill | 2048 | 21538.005 | 21429.382 | 0.99 > ArraysFill.testShortFill | 8195 | 5883.097 | 5775.499 | 0.98 @IvaVladimir Both in the PR description and in your later results there are some significant regressions (-10&) as well as improvements. Can you please explain what is going on there? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26747#issuecomment-3258712616 From mhaessig at openjdk.org Fri Sep 5 15:32:49 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Fri, 5 Sep 2025 15:32:49 GMT Subject: RFR: 8366875: CompileTaskTimeout should be reset for each iteration of RepeatCompilation Message-ID: <4TbOkAMu-KU_tgQPg1sK0L8oto_0nD4mQo7yc0hJPm4=.8d87b900-a614-4c13-a4c6-6fe11e206482@github.com> When running a debug JVM on Linux with a compile task timeout and repeated compilation, the execution will time out almost always because the timeout does not reset for repetitions of a compilation. The core of the compile task timeout is to limit the amount of time a single compilation can take. Thus, this PR resets the `CompileTaskTimeout` for every compilation when running with `-XX:RepeatCompilation=` for n > 1. This PR is stacked on top of #27094. Testing: - [ ] Github Actions - [x] tier1, tier2, tier3 plus some additional internal testing ------------- Depends on: https://git.openjdk.org/jdk/pull/27094 Commit messages: - Reset timeout on repeated compilations - Add regression test Changes: https://git.openjdk.org/jdk/pull/27120/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27120&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366875 Stats: 17 lines in 4 files changed: 16 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27120.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27120/head:pull/27120 PR: https://git.openjdk.org/jdk/pull/27120 From lmesnik at openjdk.org Fri Sep 5 16:08:13 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 5 Sep 2025 16:08:13 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v3] In-Reply-To: References: Message-ID: > This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result. > The related fix here: > https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56 > Hope fix became clarere now. > > There 2 problems in this post_meth_exit: > 1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode. > 2) The method `get_jvmti_thread_state` should be called when thread is in vm state only. > > The fix adds `post_method_exit_transition` to have single exit point with oop restoration. Leonid Mesnik 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 five additional commits since the last revision: - small improvements - Merge branch 'master' of https://github.com/openjdk/jdk into 8365192-2 - comment - comment is fixed. - fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27112/files - new: https://git.openjdk.org/jdk/pull/27112/files/77c9c7a3..0bd9c98d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27112&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27112&range=01-02 Stats: 997 lines in 48 files changed: 628 ins; 159 del; 210 mod Patch: https://git.openjdk.org/jdk/pull/27112.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27112/head:pull/27112 PR: https://git.openjdk.org/jdk/pull/27112 From lmesnik at openjdk.org Fri Sep 5 17:15:13 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 5 Sep 2025 17:15:13 GMT Subject: RFR: 8366854: Extend jtreg failure handler with THP info [v2] In-Reply-To: References: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> Message-ID: On Thu, 4 Sep 2025 07:49:56 GMT, Stefan Karlsson wrote: >> I propose that we also dump /proc/meminfo, /proc/vmstat, and /sys/kernel/mm/transparent_hugepage/{enabled, defrag} from the failure handler. >> >> This information has been helpful when investigating a failure where there was an unexpected lack of transparent huge pages. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Add shmem_enabled Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27086#pullrequestreview-3190212809 From cslucas at openjdk.org Fri Sep 5 17:27:12 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Fri, 5 Sep 2025 17:27:12 GMT Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to conc_instruction_and_data_patch [v3] In-Reply-To: References: Message-ID: <2mUEu3_9zBcWAkwSos4lG5VxpzWLuqmVk6iiJlkaLYg=.949860c5-1d21-4634-89f0-df25b2714445@github.com> On Wed, 3 Sep 2025 00:37:59 GMT, Cesar Soares Lucas wrote: >> Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64. >> >> The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%. > > Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: > > Make PPC backend to also use concurrent code patching. @dbriemann - do you have access to a PPC machine that you can use to test this patch? TIA. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26999#issuecomment-3259209337 From duke at openjdk.org Fri Sep 5 19:02:02 2025 From: duke at openjdk.org (pf0n) Date: Fri, 5 Sep 2025 19:02:02 GMT Subject: RFR: 8366122: Shenandoah: Implement efficient support for object count after gc events [v3] In-Reply-To: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com> References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com> Message-ID: > ### Summary > > The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work. > > ### Performance > The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen) > > #### Default workload: > ObjectCountAfterGC disabled (master branch): > `[807.216s][info][gc,stats ] Pause Init Mark (G) = 0.003 s (a = 264 us)` > `[807.216s][info][gc,stats ] Pause Init Mark (N) = 0.001 s (a = 91 us)` > `[807.216s][info][gc,stats ] Concurrent Mark Roots = 0.041 s (a = 4099 us)` > `[807.216s][info][gc,stats ] Concurrent Marking = 1.660 s (a = 166035 us)` > `[807.216s][info][gc,stats ] Pause Final Mark (G) = 0.004 s (a = 446 us) ` > `[807.216s][info][gc,stats ] Pause Final Mark (G) = 0.004 s (a = 446 us) ` > `[807.216s][info][gc,stats ] Pause Final Mark (N) = 0.004 s (a = 357 us)` > > ObjectCountAfterGC disabled (feature branch): > `[807.104s][info][gc,stats ] Pause Init Mark (G) = 0.003 s (a = 302 us)` > `[807.104s][info][gc,stats ] Pause Init Mark (N) = 0.001 s (a = 92 us) ` > `[807.104s][info][gc,stats ] Concurrent Mark Roots = 0.048 s (a = 4827 us)` > `[807.104s][info][gc,stats ] Concurrent Marking = 1.666 s (a = 166638 us) ` > `[807.104s][info][gc,stats ] Pause Final Mark (G) = 0.006 s (a = 603 us)` > `[807.104s][info][gc,stats ] Pause Final Mark (N) = 0.005 s (a = 516 us)` > > ObjectCountAfterGC enabled (feature branch) > `[807.299s][info][gc,stats ] Pause Init Mark (G) = 0.002 s (a = 227 us)` > `[807.299s][info][gc,stats ] Pause Init Mark (N) = 0.001 s (a = 89 us) ` > `[807.299s][info][gc,stats ] Concurrent Mark Roots = 0.053 s (a = 5279 us)` > `[807.299s][info][gc,st... pf0n has updated the pull request incrementally with three additional commits since the last revision: - Whitespace - Filtering alive objects - Filtering alive objects ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26977/files - new: https://git.openjdk.org/jdk/pull/26977/files/6a3c6318..4295fed1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26977&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26977&range=01-02 Stats: 27 lines in 5 files changed: 22 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/26977.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26977/head:pull/26977 PR: https://git.openjdk.org/jdk/pull/26977 From duke at openjdk.org Fri Sep 5 19:07:29 2025 From: duke at openjdk.org (pf0n) Date: Fri, 5 Sep 2025 19:07:29 GMT Subject: RFR: 8366122: Shenandoah: Implement efficient support for object count after gc events [v4] In-Reply-To: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com> References: <7KUQJooZsasGtVU-HaCj7h8_rMFBX13d4yW3T4PfpBw=.07a12734-af51-45cc-9bbb-d6573806478a@github.com> Message-ID: <3oswYxtSVJyfVg1xsIkus9BfXpNFMEE0cS3tYxH1Mak=.237f1e90-9b60-4b4f-af13-16bb4826b9cc@github.com> > ### Summary > > The new implementation of ObjectCountAfterGC for Shenandoah piggybacks off of the existing marking phases and records strongly marked objects in a histogram. If the event is disabled, the original marking closures are used. When enabled new mark-and-count closures are used by the worker threads. Each worker thread updates its local histogram as it marks an object. These local histograms are merged at the conclusion of the marking phase under a mutex. The event is emitted outside a safepoint. Because (most) Shenandoah's marking is done concurrently, so is the object counting work. > > ### Performance > The performance test were ran using the Extremem benchmark on a default and stress workload. (will edit this section to include data after average time and test for GenShen) > > #### Default workload: > ObjectCountAfterGC disabled (master branch): > `[807.216s][info][gc,stats ] Pause Init Mark (G) = 0.003 s (a = 264 us)` > `[807.216s][info][gc,stats ] Pause Init Mark (N) = 0.001 s (a = 91 us)` > `[807.216s][info][gc,stats ] Concurrent Mark Roots = 0.041 s (a = 4099 us)` > `[807.216s][info][gc,stats ] Concurrent Marking = 1.660 s (a = 166035 us)` > `[807.216s][info][gc,stats ] Pause Final Mark (G) = 0.004 s (a = 446 us) ` > `[807.216s][info][gc,stats ] Pause Final Mark (G) = 0.004 s (a = 446 us) ` > `[807.216s][info][gc,stats ] Pause Final Mark (N) = 0.004 s (a = 357 us)` > > ObjectCountAfterGC disabled (feature branch): > `[807.104s][info][gc,stats ] Pause Init Mark (G) = 0.003 s (a = 302 us)` > `[807.104s][info][gc,stats ] Pause Init Mark (N) = 0.001 s (a = 92 us) ` > `[807.104s][info][gc,stats ] Concurrent Mark Roots = 0.048 s (a = 4827 us)` > `[807.104s][info][gc,stats ] Concurrent Marking = 1.666 s (a = 166638 us) ` > `[807.104s][info][gc,stats ] Pause Final Mark (G) = 0.006 s (a = 603 us)` > `[807.104s][info][gc,stats ] Pause Final Mark (N) = 0.005 s (a = 516 us)` > > ObjectCountAfterGC enabled (feature branch) > `[807.299s][info][gc,stats ] Pause Init Mark (G) = 0.002 s (a = 227 us)` > `[807.299s][info][gc,stats ] Pause Init Mark (N) = 0.001 s (a = 89 us) ` > `[807.299s][info][gc,stats ] Concurrent Mark Roots = 0.053 s (a = 5279 us)` > `[807.299s][info][gc,st... pf0n has updated the pull request incrementally with one additional commit since the last revision: Whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26977/files - new: https://git.openjdk.org/jdk/pull/26977/files/4295fed1..c7abbbf0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26977&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26977&range=02-03 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26977.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26977/head:pull/26977 PR: https://git.openjdk.org/jdk/pull/26977 From eastigeevich at openjdk.org Fri Sep 5 19:15:33 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Fri, 5 Sep 2025 19:15:33 GMT Subject: RFR: 8277444: Data race between JvmtiClassFileReconstituter::copy_bytecodes and class linking [v6] In-Reply-To: References: Message-ID: <1bLI04thwsSz_j_sbfMJnHjEjQR1Soo6vupBws-vDcU=.6e6b27ee-8830-41c6-9034-652c60bc3179@github.com> > There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. > > This PR adds linking a class before the `copy_bytecodes` method is called. > The PR also adds a regression test. > > Tested fastdebug and release builds: Linux x86_64 and arm64 > - The reproducer from JDK-8277444 passed. > - The regression test passed. > - Tier1 - tier3 passed. Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: Fix comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26863/files - new: https://git.openjdk.org/jdk/pull/26863/files/05207c6c..f442736a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26863&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26863&range=04-05 Stats: 7 lines in 2 files changed: 1 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26863.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26863/head:pull/26863 PR: https://git.openjdk.org/jdk/pull/26863 From asmehra at openjdk.org Fri Sep 5 19:30:27 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 5 Sep 2025 19:30:27 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry Message-ID: This PR removes the need to store entry point addresses in AdapterHandlerEntry by storing a direct pointer to AdapterBlob instead. Entry point addresses can be computed on the fly from the entry point offsets stored in AdapterBlob. ------------- Commit messages: - Do not call generate_i2c2i_adapters() on zero - Store pointer to AdapterBlob in AdapterHandlerEntry Changes: https://git.openjdk.org/jdk/pull/27101/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27101&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366905 Stats: 243 lines in 11 files changed: 39 ins; 98 del; 106 mod Patch: https://git.openjdk.org/jdk/pull/27101.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27101/head:pull/27101 PR: https://git.openjdk.org/jdk/pull/27101 From asmehra at openjdk.org Fri Sep 5 19:30:27 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 5 Sep 2025 19:30:27 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 14:49:48 GMT, Ashutosh Mehra wrote: > This PR removes the need to store entry point addresses in AdapterHandlerEntry by storing a direct pointer to AdapterBlob instead. Entry point addresses can be computed on the fly from the entry point offsets stored in AdapterBlob. @adinn @shipilev I am finding it a bit challenging to handle zero configuration with this change. Now that the AdapterHandlerEntry has only a pointer to AdapterBlob, it is not possible to use `zero_null_code_stub` address as the i2c and c2i entry points. If the AdapterBlob is null, then the getter methods for entry points in AdapterHandlerEntry return nullptr. See `get_i2c_entry`, `get_c2i_entry` in `sharedRuntime.hpp`. And we stopped creating AdapterBlob for the AdapterHandlerEntry. So the question is: for zero does it matter if we return `zero_null_code_stub` or nullptr? I remember at one point @shipilev was returning `nullptr` as the c2i entry address in one of the PR (https://github.com/openjdk/jdk/pull/26746) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27101#issuecomment-3254137764 From shade at openjdk.org Fri Sep 5 19:30:27 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 5 Sep 2025 19:30:27 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry In-Reply-To: References: Message-ID: <7NV2rmQ-JTvrarXBBQwjansfUkXLCiM5SKT0vevK1zk=.63dc4c02-dc1f-4ec6-a2ef-3631ad693840@github.com> On Thu, 4 Sep 2025 14:49:48 GMT, Ashutosh Mehra wrote: > This PR removes the need to store entry point addresses in AdapterHandlerEntry by storing a direct pointer to AdapterBlob instead. Entry point addresses can be computed on the fly from the entry point offsets stored in AdapterBlob. > So the question is: for zero does it matter if we return `zero_null_code_stub` or nullptr? I remember at one point @shipilev was returning `nullptr` as the c2i entry address in one of the PR (#26746) It is fine to return `nullptr` for entry addresses in Zero. Zero is arguably out of line for recording external addresses as "entry points", even for the sake of better debugging. @adinn wanted to clean this up eventually, not sure we ever did. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27101#issuecomment-3257156930 From eastigeevich at openjdk.org Fri Sep 5 19:33:12 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Fri, 5 Sep 2025 19:33:12 GMT Subject: RFR: 8277444: Data race between JvmtiClassFileReconstituter::copy_bytecodes and class linking [v3] In-Reply-To: References: <7vsa-iQGbnPfzVVS-kLVX4AENNt9ttN84F2Rbf8JlBk=.1160b190-19e9-4921-8dde-0882c109b4cd@github.com> Message-ID: On Wed, 27 Aug 2025 06:37:44 GMT, David Holmes wrote: >> (I realize this is a tangent, but maybe there is a separate bug here...) >> >>> To have a Class object it must have already undergone the "preparation" part of linking (it is done at the end of loading when we create the class mirror). >> >> If that's what "preparation" means, and Class.forName(name, false, loader) does not link the class, then posting the event here in InstanceKlass::link_class_impl() instead of earlier seems misplaced: >> >> https://github.com/openjdk/jdk/blob/c75534517729b903b63263cf64dc2ff841e3dcb1/src/hotspot/share/oops/instanceKlass.cpp#L1064 >> >> Class.forName(name, false, loader) would result in a prepared class but without the event being sent. > >> If that's what "preparation" means, and Class.forName(name, false, loader) does not link the class, then posting the event here in InstanceKlass::link_class_impl() instead of earlier seems misplaced > > @dean-long it seems the JVM TI "prepare" event is somewhat misnamed. It states "At this point, class fields, methods, and implemented interfaces are available, and no code from the class has been executed." but that neither describes preparation, nor the rest of linking. You can only access fields and methods after a class has been initialized! But lets take this elsewhere if needed. @dholmes-ora, Thank you for review. > I'm not sure about the test, in particular the attempt to calculate MIN_LINK_TIME_MS. It is very hard to see/know that you will actually induce the desired race. Making a reliable regression test was a problem. `MIN_LINK_TIME_MS` is based on the reproducer from JDK-8277444 and my experiments on x86 and arm64 hosts. Maybe the time is not the best. As you wrote there is no way to know the race has happened. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3259506293 From asmehra at openjdk.org Fri Sep 5 19:35:10 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 5 Sep 2025 19:35:10 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 14:49:48 GMT, Ashutosh Mehra wrote: > This PR removes the need to store entry point addresses in AdapterHandlerEntry by storing a direct pointer to AdapterBlob instead. Entry point addresses can be computed on the fly from the entry point offsets stored in AdapterBlob. This is ready for review now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27101#issuecomment-3259514639 From coleenp at openjdk.org Fri Sep 5 19:38:18 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 5 Sep 2025 19:38:18 GMT Subject: RFR: 8277444: Data race between JvmtiClassFileReconstituter::copy_bytecodes and class linking [v6] In-Reply-To: <1bLI04thwsSz_j_sbfMJnHjEjQR1Soo6vupBws-vDcU=.6e6b27ee-8830-41c6-9034-652c60bc3179@github.com> References: <1bLI04thwsSz_j_sbfMJnHjEjQR1Soo6vupBws-vDcU=.6e6b27ee-8830-41c6-9034-652c60bc3179@github.com> Message-ID: On Fri, 5 Sep 2025 19:15:33 GMT, Evgeny Astigeevich wrote: >> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. >> >> This PR adds linking a class before the `copy_bytecodes` method is called. >> The PR also adds a regression test. >> >> Tested fastdebug and release builds: Linux x86_64 and arm64 >> - The reproducer from JDK-8277444 passed. >> - The regression test passed. >> - Tier1 - tier3 passed. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments If the test becomes problematic because of timing, we could have another change to make it /manual. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3259525975 From kbarrett at openjdk.org Fri Sep 5 20:50:23 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 5 Sep 2025 20:50:23 GMT Subject: RFR: 8314488: Compiling the JDK with C++17 [v4] In-Reply-To: References: Message-ID: On Mon, 25 Aug 2025 23:31:03 GMT, Kim Barrett wrote: >> Please review this change to use C++17 for building C++ parts of the JDK. In >> particular this affects HotSpot. This change also includes an update to the >> HotSpot Style Guide regarding C++17 features and their use in HotSpot code. >> >> Testing: mach5 tier1-8 >> >> This change includes a modification of the Style Guide. Rough consensus among >> the HotSpot Group members is required to make such a change. Only Group >> members should vote for approval (via the github PR), though reasoned >> objections or comments from anyone will be considered. A decision on this >> proposal will not be made before Friday 5-September-2025 at 12h00 UTC. >> >> Since we're piggybacking on github PRs here, please use the PR review process >> to approve (click on Review Changes > Approve), rather than sending a "vote: >> yes" email reply that would be normal for a CFV. > > Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: > > - missing word > - stefank suggestions Thanks for your comments and approvals. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26884#issuecomment-3259707171 From kbarrett at openjdk.org Fri Sep 5 20:50:24 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 5 Sep 2025 20:50:24 GMT Subject: Integrated: 8314488: Compiling the JDK with C++17 In-Reply-To: References: Message-ID: On Thu, 21 Aug 2025 14:47:14 GMT, Kim Barrett wrote: > Please review this change to use C++17 for building C++ parts of the JDK. In > particular this affects HotSpot. This change also includes an update to the > HotSpot Style Guide regarding C++17 features and their use in HotSpot code. > > Testing: mach5 tier1-8 > > This change includes a modification of the Style Guide. Rough consensus among > the HotSpot Group members is required to make such a change. Only Group > members should vote for approval (via the github PR), though reasoned > objections or comments from anyone will be considered. A decision on this > proposal will not be made before Friday 5-September-2025 at 12h00 UTC. > > Since we're piggybacking on github PRs here, please use the PR review process > to approve (click on Review Changes > Approve), rather than sending a "vote: > yes" email reply that would be normal for a CFV. This pull request has now been integrated. Changeset: 1ebe9495 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/1ebe949507b48a6b62dd36e08f0ae80da2ee1dcc Stats: 1186 lines in 7 files changed: 1098 ins; 35 del; 53 mod 8314488: Compiling the JDK with C++17 Reviewed-by: dholmes, stefank, ayang, kvn, iwalulya, jsjolen, ihse ------------- PR: https://git.openjdk.org/jdk/pull/26884 From liach at openjdk.org Fri Sep 5 20:58:14 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 5 Sep 2025 20:58:14 GMT Subject: RFR: 8366477: Refactor AOT-related flag bits in klass.hpp [v3] In-Reply-To: <-FWCU8wOAOj3jKZmKMbezP7WzU3RCX0NW_zkg_Vlq7w=.173d7912-89f0-474a-8e19-f8d3fd3fecd9@github.com> References: <-FWCU8wOAOj3jKZmKMbezP7WzU3RCX0NW_zkg_Vlq7w=.173d7912-89f0-474a-8e19-f8d3fd3fecd9@github.com> Message-ID: On Thu, 4 Sep 2025 22:01:51 GMT, Ioi Lam wrote: >> This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology): >> >> 1. Rename from `Klass::_shared_class_flags` to `Klass::_aot_class_flags` >> 2. Move `_has_aot_safe_initializer` and `_is_runtime_setup_required` from `InstanceKlassFlags` (has run out of bits) to here (we still have 7 extra bits left), to accommodate future `@AOTXXX` annotations. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - @liach and @ashu-mehra comment: Renamed Klass::_is_generated_shared_class -> _is_aot_generated_class > - Merge branch 'master' into 8366477-refactor-aot-related-flag-bits-in-klass-hpp.saved > - Merge branch '8366475-rename-metaspace-shared-to-aot-metaspace' into 8366477-refactor-aot-related-flag-bits-in-klass-hpp > - removed unnecessary includes > - Redo changes in comments and tests > - Merge branch '8366474-rename_metaspaceobj_is_shared_to_in_aot_cache' into 8366475-rename-metaspace-shared-to-aot-metaspace > - Removed MetaspaceShared -> AOTMetaspace changes that are intended for https://github.com/openjdk/jdk/pull/27017 > - 8366477: Refactor AOT-related flag bits in klass.hpp > - Rename MetaspaceShared -> AOTMetaspace > - 8366474: Rename MetaspaceObj::is_shared() to MetaspaceObj::in_aot_cache() Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27018#pullrequestreview-3190767680 From iklam at openjdk.org Fri Sep 5 23:58:17 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 5 Sep 2025 23:58:17 GMT Subject: Integrated: 8366477: Refactor AOT-related flag bits in klass.hpp In-Reply-To: References: Message-ID: On Sat, 30 Aug 2025 02:35:11 GMT, Ioi Lam wrote: > This PR is one (of many) steps in [JDK-8366473](https://bugs.openjdk.org/browse/JDK-8366473) (Refactor CDS source code with new AOT terminology): > > 1. Rename from `Klass::_shared_class_flags` to `Klass::_aot_class_flags` > 2. Move `_has_aot_safe_initializer` and `_is_runtime_setup_required` from `InstanceKlassFlags` (has run out of bits) to here (we still have 7 extra bits left), to accommodate future `@AOTXXX` annotations. This pull request has now been integrated. Changeset: dbf4ffff Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/dbf4ffffe3fbbb513122081bbcc04c543473082e Stats: 60 lines in 7 files changed: 20 ins; 10 del; 30 mod 8366477: Refactor AOT-related flag bits in klass.hpp Reviewed-by: liach, asmehra, kvn ------------- PR: https://git.openjdk.org/jdk/pull/27018 From iklam at openjdk.org Fri Sep 5 23:58:17 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 5 Sep 2025 23:58:17 GMT Subject: RFR: 8366477: Refactor AOT-related flag bits in klass.hpp [v2] In-Reply-To: References: Message-ID: On Sat, 30 Aug 2025 14:25:43 GMT, Vladimir Kozlov wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch '8366475-rename-metaspace-shared-to-aot-metaspace' into 8366477-refactor-aot-related-flag-bits-in-klass-hpp >> - 8366477: Refactor AOT-related flag bits in klass.hpp > > Good. Thanks @vnkozlov @liach @ashu-mehra for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/27018#issuecomment-3260086664 From liach at openjdk.org Sat Sep 6 01:07:12 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 6 Sep 2025 01:07:12 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v4] In-Reply-To: <6p7ncBylItu9HEeCINmqu_JFoL6zNXwJuSQaZoQ0J2I=.451526e1-d918-4fee-b1a7-e8193da61545@github.com> References: <6p7ncBylItu9HEeCINmqu_JFoL6zNXwJuSQaZoQ0J2I=.451526e1-d918-4fee-b1a7-e8193da61545@github.com> Message-ID: On Thu, 4 Sep 2025 22:01:57 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 8. >> >> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. > > Christian Stein 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 five additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Update to use correct library directories > > See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files > - 8361950: Set required version to 8+2 > - 8361950: Update to use jtreg 8 #26749 was merged 4 days ago. Can we integrate this one now? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3260152639 From alanb at openjdk.org Sat Sep 6 07:04:14 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 6 Sep 2025 07:04:14 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v4] In-Reply-To: References: <6p7ncBylItu9HEeCINmqu_JFoL6zNXwJuSQaZoQ0J2I=.451526e1-d918-4fee-b1a7-e8193da61545@github.com> Message-ID: On Sat, 6 Sep 2025 01:04:56 GMT, Chen Liang wrote: > #26749 was merged 4 days ago. Can we integrate this one now? I think it would be useful to get input from @dholmes-ora and @lkorinth before doing this. There seems to be several timeout issues in the last few days, a few follow-on changes to adjust the timeout of a few tests, and a spate of tests being reported as timed out after passing. Updating jtreg adds another change to the picture. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3261436239 From djelinski at openjdk.org Sat Sep 6 07:32:45 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Sat, 6 Sep 2025 07:32:45 GMT Subject: RFR: 8366984: Remove delay slot support Message-ID: SPARC was the only supported architecture that uses a delay slot. The SPARC port was removed in JDK 15, and the code is effectively dead. Let's remove it. The changes are no-op on all architectures that do not use delay slots. I still tested tier 1-5 on mach5, no related failures. ------------- Depends on: https://git.openjdk.org/jdk/pull/27117 Commit messages: - Revert scope_desc change, breaks macos-aarch64 - Remove remaining comments - Update copyright - Remove commented out code - Remove unused variables - Comment out unused _unconditional_delay_slot - Remove bundle flags - Remove delay slot support from ADL - Clean up delay slot remnants from arm32 code - Remove Lir_OpDelay Changes: https://git.openjdk.org/jdk/pull/27119/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27119&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366984 Stats: 456 lines in 19 files changed: 1 ins; 407 del; 48 mod Patch: https://git.openjdk.org/jdk/pull/27119.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27119/head:pull/27119 PR: https://git.openjdk.org/jdk/pull/27119 From qpzhang at openjdk.org Sun Sep 7 01:52:08 2025 From: qpzhang at openjdk.org (Patrick Zhang) Date: Sun, 7 Sep 2025 01:52:08 GMT Subject: RFR: 8365991: AArch64: Ignore BlockZeroingLowLimit when UseBlockZeroing is false [v4] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 11:22:15 GMT, Andrew Haley wrote: > I can't see any statistically-significant improvement. Please tell us your test results and your test conditions. The impact can be divided into two parts, at execution time and at code generation time respectively. 1. Execution time measured by JMH RawAllocationRate test cases As mentioned in the initial PR summary, we do not expect significant improvement in the execution of `zero_words` with this PR, neither in the original version (C1 and C2) nor in the current revision (C1 only). The instruction sequences generated by both the baseline and patched versions show only minor differences under certain test conditions. Additionally, some reduction in `cmp` and `branch` instructions is insufficient to yield a significant performance benefit. Let us focus on tests that can generate diffs, for example, I run below on Ampere Altra (Neoverse-N1), Fedora 40, Kernel 6.1. JVM_ARGS="-XX:-UseBlockZeroing -XX:BlockZeroingLowLimit=8" JMH_ARGS="-p size=32 -p size=48 -p size=64 -p size=80 -p size=96 -p size=128 -p size=256" jdk/bin/java -jar images/test/micro/benchmarks.jar RawAllocationRate.instanceTest_C1 -bm thrpt -gc false -wi 2 -w 60 -i 1 -r 30 -t 1 -f 1 -tu s -jvmArgs "${JVM_ARGS}" ${JMH_ARGS} -rf csv -rff results.csv Results (Base) "Benchmark","Mode","Threads","Samples","Score","Score Error (99.9%)","Unit","Param: size" "org.openjdk.bench.vm.gc.RawAllocationRate.instanceTest_C1","thrpt",1,1,7013.365157,NaN,"ops/s",32 "org.openjdk.bench.vm.gc.RawAllocationRate.instanceTest_C1","thrpt",1,1,9160.068513,NaN,"ops/s",48 "org.openjdk.bench.vm.gc.RawAllocationRate.instanceTest_C1","thrpt",1,1,10216.516550,NaN,"ops/s",64 "org.openjdk.bench.vm.gc.RawAllocationRate.instanceTest_C1","thrpt",1,1,9512.467605,NaN,"ops/s",80 "org.openjdk.bench.vm.gc.RawAllocationRate.instanceTest_C1","thrpt",1,1,7555.693378,NaN,"ops/s",96 "org.openjdk.bench.vm.gc.RawAllocationRate.instanceTest_C1","thrpt",1,1,9033.057061,NaN,"ops/s",128 "org.openjdk.bench.vm.gc.RawAllocationRate.instanceTest_C1","thrpt",1,1,5559.689404,NaN,"ops/s",256 Patched (minor variations or slight improvements, as expected) "Benchmark","Mode","Threads","Samples","Score","Score Error (99.9%)","Unit","Param: size" "org.openjdk.bench.vm.gc.RawAllocationRate.instanceTest_C1","thrpt",1,1,7071.799147,NaN,"ops/s",32 "org.openjdk.bench.vm.gc.RawAllocationRate.instanceTest_C1","thrpt",1,1,9250.847903,NaN,"ops/s",48 "org.openjdk.bench.vm.gc.RawAllocationRate.instanceTest_C1","thrpt",1,1,10240.947817,NaN,"ops/s",64 "org.openjdk.bench.vm.gc.RawAllocationRate.instanceTest_C1","thrpt",1,1,9757.645075,NaN,"ops/s",80 "org.openjdk.bench.vm.gc.RawAllocationRate.instanceTest_C1","thrpt",1,1,7531.211049,NaN,"ops/s",96 "org.openjdk.bench.vm.gc.RawAllocationRate.instanceTest_C1","thrpt",1,1,9045.657067,NaN,"ops/s",128 "org.openjdk.bench.vm.gc.RawAllocationRate.instanceTest_C1","thrpt",1,1,5560.328088,NaN,"ops/s",256 Note that we do not include C2 tests and size > 256 as the generated code are same, no noticeable performance change. 2. Code-gen time measured by Gtest `test_MacroAssembler_zero_words.cpp` I created `jdk/test/hotspot/gtest/aarch64/test_MacroAssembler_zero_words.cpp` to measure the wall time of `zero_words` calls; however, I have not included it in this PR because it still contains some hardcoded variables. #include "asm/assembler.hpp" #include "asm/assembler.inline.hpp" #include "asm/macroAssembler.hpp" #include "unittest.hpp" #include #if defined(AARCH64) && !defined(ZERO) TEST_VM(AssemblerAArch64, zero_words_wall_time) { BufferBlob* b = BufferBlob::create("aarch64Test", 200000); CodeBuffer code(b); MacroAssembler _masm(&code); const size_t call_count = 1000; const size_t word_count = 4; // 32B / 8B-per-word = 4 // const size_t word_count = 16; // 128B / 8B-per-word = 16 uint64_t* buffer = new uint64_t[word_count]; Register base = r10; uint64_t cnt = word_count; // Set up base register to point to buffer _masm.mov(base, (uintptr_t)buffer); auto start = std::chrono::steady_clock::now(); for (size_t i = 0; i < call_count; ++i) { _masm.zero_words(base, cnt); } auto end = std::chrono::steady_clock::now(); auto wall_time_ns = std::chrono::duration_cast(end - start).count(); printf("zero_words wall time (ns): %ld\n", wall_time_ns / call_count); // Optionally verify buffer is zeroed for (size_t i = 0; i < word_count; ++i) { ASSERT_EQ(buffer[i], 0u); } delete[] buffer; } #endif // AARCH64 && !ZERO Firstly, we test clearing 4 words (32 bytes) with low limit 8 bytes (1 words), the patch will correct the low limit to 256 bytes (32 words). Run it 20 times to see the ratios of patch vs base (lower is better): for ((i=0;i<20;i++));do make test-only TEST="gtest:AssemblerAArch64.zero_words_wall_time" TEST_OPTS="JAVA_OPTIONS=-XX:-UseBlockZeroing -XX:BlockZeroingLowLimit=8" 2>/dev/null | grep "wall time" done Test results, zero_words wall time (ns): Base Patch Patch vs Base 346 45 0.13 393 45 0.11 398 46 0.12 390 30 0.08 322 29 0.09 398 27 0.07 392 51 0.13 392 44 0.11 361 53 0.15 390 44 0.11 299 28 0.09 303 29 0.10 419 52 0.12 390 44 0.11 403 29 0.07 387 44 0.11 387 53 0.14 307 29 0.09 298 45 0.15 387 45 0.12 Secondly, we test clearing larger memory, 16 words (128 bytes) with low limit 64 bytes (8 words). Remember to update `test_MacroAssembler_zero_words.cpp` with `const size_t word_count = 16;` and use below command line: for ((i=0;i<20;i++));do make test-only TEST="gtest:AssemblerAArch64.zero_words_wall_time" TEST_OPTS="JAVA_OPTIONS=-XX:-UseBlockZeroing -XX:BlockZeroingLowLimit=64" | grep "wall time" done New test results, zero_words wall time (ns): Base Patch Patch vs Base 370 204 0.55 310 205 0.66 369 209 0.57 381 208 0.55 384 172 0.45 365 209 0.57 364 205 0.56 378 204 0.54 388 208 0.54 375 200 0.53 369 201 0.54 289 204 0.71 377 204 0.54 380 201 0.53 379 201 0.53 379 199 0.53 388 207 0.53 375 204 0.54 402 201 0.50 373 202 0.54 In summary, the code changes bring a slight improvement to execution time, though some of these differences may be within normal variation, and a clear reduction in wall time for the `zero_words_reg_imm` calls under the specific test conditions where `UseBlockZeroing` is false and `mem words cnt > BlockZeroingLowLimit / BytesPerWord`. I understood that some of the observed differences are not statistically significant, and certain improved code-gen wall time ratios may be of limited concern. However, the primary purpose of this PR is to address the logical issue: ensuring that a configured `BlockZeroingLowLimit` should not take its confusing effect when `UseBlockZeroing` is false, unlike its behavior when true. Thanks for taking the time to read this long write-up in details. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26917#issuecomment-3263346980 From dholmes at openjdk.org Mon Sep 8 04:27:19 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 8 Sep 2025 04:27:19 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v4] In-Reply-To: <6p7ncBylItu9HEeCINmqu_JFoL6zNXwJuSQaZoQ0J2I=.451526e1-d918-4fee-b1a7-e8193da61545@github.com> References: <6p7ncBylItu9HEeCINmqu_JFoL6zNXwJuSQaZoQ0J2I=.451526e1-d918-4fee-b1a7-e8193da61545@github.com> Message-ID: On Thu, 4 Sep 2025 22:01:57 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 8. >> >> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. > > Christian Stein 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 five additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Update to use correct library directories > > See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files > - 8361950: Set required version to 8+2 > - 8361950: Update to use jtreg 8 I would appreciate it if this could hold off a while longer as we have a few issues causing noise in our testing at the moment and I don't want to muddy the waters even further. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3264544890 From dholmes at openjdk.org Mon Sep 8 05:38:15 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 8 Sep 2025 05:38:15 GMT Subject: RFR: 8365190: Remove LockingMode related code from share [v3] In-Reply-To: <44Gctjipr64z9PfAvwdEgRo4pq8sFtmpZOE4JehO4rc=.c6532986-972f-466c-b7c6-75e063613fa9@github.com> References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> <44Gctjipr64z9PfAvwdEgRo4pq8sFtmpZOE4JehO4rc=.c6532986-972f-466c-b7c6-75e063613fa9@github.com> Message-ID: On Thu, 4 Sep 2025 12:10:01 GMT, Fredrik Bredberg wrote: >> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR). >> >> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself. >> >> Passes tier1-tier5 with no added problems. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > New version for Coleen Marked as reviewed by dholmes (Reviewer). src/hotspot/share/runtime/lightweightSynchronizer.cpp line 768: > 766: } > 767: > 768: // LightweightSynchronizer::inflate_locked_or_imse is used to to get an Suggestion: // LightweightSynchronizer::inflate_locked_or_imse is used to get an src/hotspot/share/runtime/lightweightSynchronizer.cpp line 822: > 820: // The JavaThread* locking parameter requires that the > 821: // locking_thread == JavaThread::current, or is suspended throughout > 822: // the call by some other mechanism. Suggestion: // The JavaThread* locking parameter requires that the locking_thread == JavaThread::current, // or is suspended throughout the call by some other mechanism. ------------- PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3195015687 PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2329176488 PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2329179011 From xpeng at openjdk.org Mon Sep 8 05:43:52 2025 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 8 Sep 2025 05:43:52 GMT Subject: RFR: 8354555: Add generic JFR events for TaskTerminator [v10] In-Reply-To: <_7FP2wNe8p3N8SxKdmCN1x4zKO8TT5JWRcWEt51i35c=.4fbac292-3cb7-48b9-922e-1114f74e0549@github.com> References: <_7FP2wNe8p3N8SxKdmCN1x4zKO8TT5JWRcWEt51i35c=.4fbac292-3cb7-48b9-922e-1114f74e0549@github.com> Message-ID: > The purpose of the PR is to add generic JFR events for TaskTerminator to track the attempts and timings that GC threads have tried to terminate GC tasks. > > Today only G1 emits JFR event with name `Termination` from [G1ParEvacuateFollowersClosure](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/g1/g1YoungCollector.cpp#L555-L563), all other garbage collectors don't emit any JFR event for the termination attempt at all. > > By adding this, it gives performance engineers the visibility to the termination attempts and termination time when GC threads trying to finish GC tasks, we could build tool to analyze the jfr events to determine if there is potential data structure issue in application code, e.g. very large LinkedList or LinkedBlockingQueue. > > For the test, I have manually tested different GCs with Flight Recording enabled and verified the events: > G1: > > jdk.GCPhaseParallel { > startTime = 23:09:34.124 (2025-05-22) > duration = 0.0108 ms > gcId = 0 > gcWorkerId = 8 > name = "Termination" > eventThread = "GC Thread#4" (osThreadId = 20483) > } > > jdk.GCPhaseParallel { > startTime = 23:09:34.124 (2025-05-22) > duration = 0.0467 ms > gcId = 0 > gcWorkerId = 2 > name = "Termination" > eventThread = "GC Thread#2" (osThreadId = 21251) > } > > jdk.GCPhaseParallel { > startTime = 23:09:34.124 (2025-05-22) > duration = 0.0474 ms > gcId = 0 > gcWorkerId = 1 > name = "Termination" > eventThread = "GC Thread#8" (osThreadId = 36359) > } > jdk.GCPhaseParallel { > startTime = 23:09:41.925 (2025-05-22) > duration = 0.000834 ms > gcId = 14 > gcWorkerId = 7 > name = "Termination: Parallel Marking" > eventThread = "GC Thread#1" (osThreadId = 21507) > } > > jdk.GCPhaseParallel { > startTime = 23:09:41.925 (2025-05-22) > duration = 0.000166 ms > gcId = 14 > gcWorkerId = 7 > name = "Termination: Parallel Marking" > eventThread = "GC Thread#1" (osThreadId = 21507) > } > > > Shenandoah: > > jdk.GCPhaseParallel { > startTime = 23:39:58.890 (2025-05-22) > duration = 0.0202 ms > gcId = 0 > gcWorkerId = 0 > name = "Termination: Concurrent Mark" > eventThread = "Shenandoah GC Threads#3" (osThreadId = 13827) > } > > jdk.GCPhaseParallel { > startTime = 23:39:58.890 (2025-05-22) > duration = 0.0205 ms > gcId = 0 > gcWorkerId = 1 > name = "Termination: Concurrent Mark" > eventThread = "Shenandoah GC Threads#1" (osThreadId = 14339) > } > > jdk.GCPhaseParallel { > startTime = 23:39:58.890 (2025-05-22) > duration = 0.0127 ms > gcId = 0 > gcWorkerId = 5 > name = "Termination: Final Mark" > eventThread = "Shenandoah G... Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: - Merge branch 'openjdk:master' into JDK-8354555 - Merge branch 'openjdk:master' into JDK-8354555 - Merge branch 'openjdk:master' into JDK-8354555 - Merge branch 'openjdk:master' into JDK-8354555 - Merge branch 'openjdk:master' into JDK-8354555 - Merge branch 'openjdk:master' into JDK-8354555 - Fix jft test failure - Merge branch 'master' into JDK-8354555 - Patch to fix the PR concerns - Emit exact same events for G1 as G1 is emitting today from G1EvacuateRegionsBaseTask and G1STWRefProcProxyTask - ... and 24 more: https://git.openjdk.org/jdk/compare/b0ca9bf6...52d61612 ------------- Changes: https://git.openjdk.org/jdk/pull/24676/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24676&range=09 Stats: 90 lines in 10 files changed: 68 ins; 7 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/24676.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24676/head:pull/24676 PR: https://git.openjdk.org/jdk/pull/24676 From dholmes at openjdk.org Mon Sep 8 05:57:16 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 8 Sep 2025 05:57:16 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v3] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 16:08:13 GMT, Leonid Mesnik wrote: >> This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result. >> The related fix here: >> https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56 >> Hope fix became clarere now. >> >> There 2 problems in this post_meth_exit: >> 1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode. >> 2) The method `get_jvmti_thread_state` should be called when thread is in vm state only. >> >> The fix adds `post_method_exit_transition` to have single exit point with oop restoration. > > Leonid Mesnik 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 five additional commits since the last revision: > > - small improvements > - Merge branch 'master' of https://github.com/openjdk/jdk into 8365192-2 > - comment > - comment is fixed. > - fix I've taken a first pass through and the code reorg seems okay. It would have been a little clearer without factoring out the transition method. Thanks src/hotspot/share/prims/jvmtiExport.cpp line 1833: > 1831: // we just call into the interpreter to convert this into a jvalue. > 1832: // The post_method_exit_transition always makes transition to vm and back > 1833: // where GC can happen. So it is needed to preserve result and then restore it Suggestion: // where GC can happen. So it is needed to preserve result and then restore it src/hotspot/share/prims/jvmtiExport.cpp line 1857: > 1855: BasicType type, Handle result, jvalue value) { > 1856: JvmtiThreadState* state; // should be initialized in vm state only > 1857: JavaThread* current = thread; // for JRT_BLOCK If `thread` is always the current thread then I suggest just calling it `current` in the first place. ------------- PR Review: https://git.openjdk.org/jdk/pull/27112#pullrequestreview-3195023988 PR Review Comment: https://git.openjdk.org/jdk/pull/27112#discussion_r2329182820 PR Review Comment: https://git.openjdk.org/jdk/pull/27112#discussion_r2329187504 From kbarrett at openjdk.org Mon Sep 8 06:32:08 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 8 Sep 2025 06:32:08 GMT Subject: RFR: 8367014: Rename class Atomic to AtomicAccess Message-ID: Please review this change that renames the all-static class `Atomic` to `AtomicAccess`. The reason for this name change is to allow the introduction of the new type `Atomic` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)). The PR has several commits, according to the specific category of change being made. It may be easier to review the PR by studying these individual commits. Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose to not rename the various "atomic_.*" and "atomic__.*" files. There are a number of comments containing the word "Atomic" that I didn't change. They are generically about atomic operations, and will just as well serve as referring to the future `Atomic`. Testing: mach5 tier1, GHA sanity tests. This is one of those changes where successful builds indicate the change is good. ------------- Commit messages: - update copyrights - misc cleanups - fix indentation from rename - rename Atomic => AtomicAccess in gtests - rename Atomic => AtomicAccess - change includes of atomic.hpp in gtests - change includes of atomic.hpp - rename atomic.hpp => atomicAccess.hpp Changes: https://git.openjdk.org/jdk/pull/27135/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27135&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367014 Stats: 4894 lines in 427 files changed: 1237 ins; 1235 del; 2422 mod Patch: https://git.openjdk.org/jdk/pull/27135.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27135/head:pull/27135 PR: https://git.openjdk.org/jdk/pull/27135 From dholmes at openjdk.org Mon Sep 8 06:34:15 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 8 Sep 2025 06:34:15 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands [v2] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 19:35:36 GMT, Paul Hohensee wrote: >> src/hotspot/share/utilities/debug.cpp line 341: >> >>> 339: } >>> 340: return true; >>> 341: } >> >> I don't think we need this. The commands that require a JavaThread should be checking that directly themselves. Typically we assume/expect the person debugging to know what they are dealing with and use the appropriate commands. > > @dholmes-ora, are you sure you want this level of code duplication? As is it, the latest version duplicates the following 3 times > > if (!c.onThread()) return; > JavaThread* p = JavaThread::active(); > if (p == nullptr) { > tty->print_cr("Failed: JavaThread::active is null"); > return; > } > tty->print(" for thread: "); > p->print(); > tty->cr(); It is not ideal but the original if (!c.onJavaThread()) return; JavaThread* p = JavaThread::active(); is also duplicating the internals both inside `isOnJavaThread()` and in the callers. And what is mainly tripping us up is that `active()` is allowed to return null, but this fix wants to detect a null current thread as a sign of being detached. So we end up calling `Thread::current` multiple times. All of the debug functions that use `active()` are currently broken anyway because they never check it for null (and I'm not even sure they truly expect to work on a delegated JavaThread??). So I see this fix as having two parts: 1. The `onThread` check takes care of being attached 2. The `active() == nullptr` check just fixes the current broken code. But I still dislike the internal duplication between `onThread` and `active`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27033#discussion_r2329264472 From fbredberg at openjdk.org Mon Sep 8 07:08:31 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Mon, 8 Sep 2025 07:08:31 GMT Subject: RFR: 8365190: Remove LockingMode related code from share [v4] In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> Message-ID: > Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR). > > This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself. > > Passes tier1-tier5 with no added problems. Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: New version for David ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27041/files - new: https://git.openjdk.org/jdk/pull/27041/files/f2fc9a5f..905ef3fb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27041&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27041&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27041.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27041/head:pull/27041 PR: https://git.openjdk.org/jdk/pull/27041 From aboldtch at openjdk.org Mon Sep 8 07:08:31 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 8 Sep 2025 07:08:31 GMT Subject: RFR: 8365190: Remove LockingMode related code from share [v4] In-Reply-To: References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> Message-ID: On Mon, 8 Sep 2025 07:05:47 GMT, Fredrik Bredberg wrote: >> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR). >> >> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself. >> >> Passes tier1-tier5 with no added problems. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > New version for David Marked as reviewed by aboldtch (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3195220478 From fbredberg at openjdk.org Mon Sep 8 07:08:32 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Mon, 8 Sep 2025 07:08:32 GMT Subject: RFR: 8365190: Remove LockingMode related code from share [v3] In-Reply-To: References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> <44Gctjipr64z9PfAvwdEgRo4pq8sFtmpZOE4JehO4rc=.c6532986-972f-466c-b7c6-75e063613fa9@github.com> Message-ID: On Mon, 8 Sep 2025 05:33:05 GMT, David Holmes wrote: >> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: >> >> New version for Coleen > > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 768: > >> 766: } >> 767: >> 768: // LightweightSynchronizer::inflate_locked_or_imse is used to to get an > > Suggestion: > > // LightweightSynchronizer::inflate_locked_or_imse is used to get an Fixed > src/hotspot/share/runtime/lightweightSynchronizer.cpp line 822: > >> 820: // The JavaThread* locking parameter requires that the >> 821: // locking_thread == JavaThread::current, or is suspended throughout >> 822: // the call by some other mechanism. > > Suggestion: > > // The JavaThread* locking parameter requires that the locking_thread == JavaThread::current, > // or is suspended throughout the call by some other mechanism. Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2329325202 PR Review Comment: https://git.openjdk.org/jdk/pull/27041#discussion_r2329325682 From dholmes at openjdk.org Mon Sep 8 07:24:14 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 8 Sep 2025 07:24:14 GMT Subject: RFR: 8365190: Remove LockingMode related code from share [v4] In-Reply-To: References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> Message-ID: On Mon, 8 Sep 2025 07:08:31 GMT, Fredrik Bredberg wrote: >> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR). >> >> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself. >> >> Passes tier1-tier5 with no added problems. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > New version for David Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27041#pullrequestreview-3195269911 From dholmes at openjdk.org Mon Sep 8 08:20:10 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 8 Sep 2025 08:20:10 GMT Subject: RFR: 8367014: Rename class Atomic to AtomicAccess In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 06:26:03 GMT, Kim Barrett wrote: > Please review this change that renames the all-static class `Atomic` to > `AtomicAccess`. The reason for this name change is to allow the introduction > of the new type `Atomic` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)). > > The PR has several commits, according to the specific category of change being > made. It may be easier to review the PR by studying these individual commits. > > Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose > to not rename the various "atomic_.*" and "atomic__.*" files. > > There are a number of comments containing the word "Atomic" that I didn't > change. They are generically about atomic operations, and will just as well > serve as referring to the future `Atomic`. > > Testing: mach5 tier1, GHA sanity tests. > This is one of those changes where successful builds indicate the change is good. LGTM! Thanks for taking this on! ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27135#pullrequestreview-3195448260 From rrich at openjdk.org Mon Sep 8 08:33:27 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Mon, 8 Sep 2025 08:33:27 GMT Subject: RFR: 8360219: [AIX] assert(locals_base >= l2) failed: bad placement In-Reply-To: <6YAyMkyKnD_ipbw7yZMKciLoh5zEsiLeT78Pv4Crvvs=.b765ce7c-d210-4cdf-9047-6e4b18a81c98@github.com> References: <6YAyMkyKnD_ipbw7yZMKciLoh5zEsiLeT78Pv4Crvvs=.b765ce7c-d210-4cdf-9047-6e4b18a81c98@github.com> Message-ID: On Tue, 5 Aug 2025 14:53:30 GMT, Richard Reingruber wrote: > Weaken assertion because it is too strict. While the interpreted caller sometimes has a `frame::top_ijava_frame_abi` it is sufficient to assert that the locals don't overlap with the smaller `frame::parent_ijava_frame_abi` because only that's reserved for non-top frames (aka `parent` frames). > > Tested on AIX and Linux ppc: Tier 1-4 of hotspot and jdk. All of langtools and jaxp. Renaissance Suite and SAP specific tests. > > Details: > > It cannot be assumed that the interpreted caller of the bottom interpreted frame (from a compiled deoptee frame) has a large `frame::top_ijava_frame_abi`. In an ordinary i2c call it would keep its `frame::top_ijava_frame_abi` (see [`call_from_interpreter`](https://github.com/openjdk/jdk/blob/67ba8b45dd632c40d5e6872d2a6ce24f86c22152/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp#L1217)) but when it was thawed then it'll have only a `frame::java_abi` (alias for parent_ijava_frame_abi). > > There are [diagrams](https://github.com/openjdk/jdk/blob/8a571ee7f2d9a46ff485fd9f3658c552e2d20817/src/hotspot/cpu/ppc/continuationFreezeThaw_ppc.inline.hpp#L395) commenting `ThawBase::new_stack_frame()` that show this. > > It's not easy to see it in the code though. Note that the [frame size](https://github.com/openjdk/jdk/blob/8a571ee7f2d9a46ff485fd9f3658c552e2d20817/src/hotspot/cpu/ppc/continuationFreezeThaw_ppc.inline.hpp#L496) is calculated relative to hf's unextended_sp which [includes frame::metadata_words](https://github.com/openjdk/jdk/blob/8a571ee7f2d9a46ff485fd9f3658c552e2d20817/src/hotspot/cpu/ppc/stackChunkFrameStream_ppc.inline.hpp#L80) which is the size of `java_abi`. Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26643#issuecomment-3265165518 From rrich at openjdk.org Mon Sep 8 08:33:28 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Mon, 8 Sep 2025 08:33:28 GMT Subject: Integrated: 8360219: [AIX] assert(locals_base >= l2) failed: bad placement In-Reply-To: <6YAyMkyKnD_ipbw7yZMKciLoh5zEsiLeT78Pv4Crvvs=.b765ce7c-d210-4cdf-9047-6e4b18a81c98@github.com> References: <6YAyMkyKnD_ipbw7yZMKciLoh5zEsiLeT78Pv4Crvvs=.b765ce7c-d210-4cdf-9047-6e4b18a81c98@github.com> Message-ID: On Tue, 5 Aug 2025 14:53:30 GMT, Richard Reingruber wrote: > Weaken assertion because it is too strict. While the interpreted caller sometimes has a `frame::top_ijava_frame_abi` it is sufficient to assert that the locals don't overlap with the smaller `frame::parent_ijava_frame_abi` because only that's reserved for non-top frames (aka `parent` frames). > > Tested on AIX and Linux ppc: Tier 1-4 of hotspot and jdk. All of langtools and jaxp. Renaissance Suite and SAP specific tests. > > Details: > > It cannot be assumed that the interpreted caller of the bottom interpreted frame (from a compiled deoptee frame) has a large `frame::top_ijava_frame_abi`. In an ordinary i2c call it would keep its `frame::top_ijava_frame_abi` (see [`call_from_interpreter`](https://github.com/openjdk/jdk/blob/67ba8b45dd632c40d5e6872d2a6ce24f86c22152/src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp#L1217)) but when it was thawed then it'll have only a `frame::java_abi` (alias for parent_ijava_frame_abi). > > There are [diagrams](https://github.com/openjdk/jdk/blob/8a571ee7f2d9a46ff485fd9f3658c552e2d20817/src/hotspot/cpu/ppc/continuationFreezeThaw_ppc.inline.hpp#L395) commenting `ThawBase::new_stack_frame()` that show this. > > It's not easy to see it in the code though. Note that the [frame size](https://github.com/openjdk/jdk/blob/8a571ee7f2d9a46ff485fd9f3658c552e2d20817/src/hotspot/cpu/ppc/continuationFreezeThaw_ppc.inline.hpp#L496) is calculated relative to hf's unextended_sp which [includes frame::metadata_words](https://github.com/openjdk/jdk/blob/8a571ee7f2d9a46ff485fd9f3658c552e2d20817/src/hotspot/cpu/ppc/stackChunkFrameStream_ppc.inline.hpp#L80) which is the size of `java_abi`. This pull request has now been integrated. Changeset: bea2b029 Author: Richard Reingruber URL: https://git.openjdk.org/jdk/commit/bea2b029a77e126171d17c3a44baec6d5cafed4a Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod 8360219: [AIX] assert(locals_base >= l2) failed: bad placement Reviewed-by: dlong, mdoerr ------------- PR: https://git.openjdk.org/jdk/pull/26643 From ayang at openjdk.org Mon Sep 8 08:36:08 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 8 Sep 2025 08:36:08 GMT Subject: RFR: 8346005: Parallel: Incorrect page size calculation with UseLargePages [v4] In-Reply-To: References: Message-ID: > Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`. > > The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation. > > The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`. > > When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary. > > Test: tier1?8 Albert Mingkun Yang 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 five additional commits since the last revision: - page-size - Merge branch 'master' into pgc-largepage - Merge branch 'master' into pgc-largepage - Merge branch 'master' into pgc-largepage - pgc-largepage ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26700/files - new: https://git.openjdk.org/jdk/pull/26700/files/88702f07..74d4fa3c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=02-03 Stats: 23374 lines in 1065 files changed: 16423 ins; 3065 del; 3886 mod Patch: https://git.openjdk.org/jdk/pull/26700.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26700/head:pull/26700 PR: https://git.openjdk.org/jdk/pull/26700 From ayang at openjdk.org Mon Sep 8 08:42:18 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 8 Sep 2025 08:42:18 GMT Subject: RFR: 8346005: Parallel: Incorrect page size calculation with UseLargePages [v4] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 08:36:08 GMT, Albert Mingkun Yang wrote: >> Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`. >> >> The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation. >> >> The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`. >> >> When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary. >> >> Test: tier1?8 > > Albert Mingkun Yang 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 five additional commits since the last revision: > > - page-size > - Merge branch 'master' into pgc-largepage > - Merge branch 'master' into pgc-largepage > - Merge branch 'master' into pgc-largepage > - pgc-largepage Minor updates after [JDK-8366434](https://bugs.openjdk.org/browse/JDK-8366434), as the page-size of reserved-memory reflects the intended/actual OS page-size, when using transparent huge pages. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26700#issuecomment-3265204916 From kevinw at openjdk.org Mon Sep 8 08:47:15 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 8 Sep 2025 08:47:15 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands [v2] In-Reply-To: References: Message-ID: <-SmBLpOXlQ8uaUQNx3KHZLhNqUhVWWN_E8dMrzb63ls=.ad5fbe15-7706-490c-b2ff-02100ffe0a5e@github.com> On Tue, 2 Sep 2025 10:08:58 GMT, Kerem Kat wrote: >> Prevents segmentation faults during `gdb` sessions. The crashes were caused by the `ResourceMark` constructor being called on a native thread, which is not supported. This happened when invoking debug commands that require a `Thread` or `JavaThread` context from an incorrect thread type. >> >> ### Solution >> >> This change introduces `onThread()` and `onJavaThread()` helper methods to the `Command` class. These methods validate the thread context and ensure `ResourceMark` is only created when on a valid VM thread. All thread-dependent debug commands now use these guards to validate the context, printing a clear error and exiting gracefully upon failure. >> >> ### Testing >> >> Manually verified using `gdb` by calling the modified commands (`ps`, `universe`, `pns`, etc.) from different thread contexts (native, Java, and non-java threads) to ensure they fail gracefully with an error message instead of crashing the debug session. > > Kerem Kat has updated the pull request incrementally with two additional commits since the last revision: > > - add include for global placement new > - remove onJavaThread and check JavaThread::active null where needed src/hotspot/share/utilities/debug.cpp line 308: > 306: public: > 307: Command(const char* str) : _has_rm(false) { > 308: if (level++ == 0) { Hi, is this an accidental change, it was ">0" ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27033#discussion_r2329562498 From mli at openjdk.org Mon Sep 8 09:02:52 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 8 Sep 2025 09:02:52 GMT Subject: RFR: 8367066: RISC-V: refine register selection in MacroAssembler:: decode_klass_not_null Message-ID: Hi, Can you help to review this patch? Previously, the register selection in MacroAssembler:: decode_klass_not_null is misleading, better to refine it to improve the readability. Thanks! Running runtime test tier1/2/3... ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/27138/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27138&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367066 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27138.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27138/head:pull/27138 PR: https://git.openjdk.org/jdk/pull/27138 From tschatzl at openjdk.org Mon Sep 8 09:09:49 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 8 Sep 2025 09:09:49 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * sort includes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/2a614a2c..4601bf88 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=53 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=52-53 Stats: 7 lines in 4 files changed: 4 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From mdoerr at openjdk.org Mon Sep 8 09:34:18 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 8 Sep 2025 09:34:18 GMT Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to conc_instruction_and_data_patch [v3] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 00:37:59 GMT, Cesar Soares Lucas wrote: >> Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64. >> >> The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%. > > Cesar Soares Lucas has updated the pull request incrementally with one additional commit since the last revision: > > Make PPC backend to also use concurrent code patching. This change is a NOP for PPC64 since we're generating the same code for both patching types. GHA cross build has passed, so there's nothing to worry regarding PPC64. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26999#issuecomment-3265416475 From aph at openjdk.org Mon Sep 8 09:35:16 2025 From: aph at openjdk.org (Andrew Haley) Date: Mon, 8 Sep 2025 09:35:16 GMT Subject: RFR: 8367014: Rename class Atomic to AtomicAccess In-Reply-To: References: Message-ID: <12OJX5AFklPfeUixNRHyTHo38EV4dFzLX8Dp-yvMVrI=.bcd6c93a-d462-4ed9-9d34-e8197c7fb04a@github.com> On Mon, 8 Sep 2025 06:26:03 GMT, Kim Barrett wrote: > Please review this change that renames the all-static class `Atomic` to > `AtomicAccess`. The reason for this name change is to allow the introduction > of the new type `Atomic` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)). > > The PR has several commits, according to the specific category of change being > made. It may be easier to review the PR by studying these individual commits. > > Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose > to not rename the various "atomic_.*" and "atomic__.*" files. > > There are a number of comments containing the word "Atomic" that I didn't > change. They are generically about atomic operations, and will just as well > serve as referring to the future `Atomic`. > > Testing: mach5 tier1, GHA sanity tests. > This is one of those changes where successful builds indicate the change is good. `AtomicAccess` is a bit wordy, and this change is going to mess up diffs for backports terribly, but I can't think of a better way to do it. Thanks. ------------- Marked as reviewed by aph (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27135#pullrequestreview-3195732355 From kevinw at openjdk.org Mon Sep 8 09:43:15 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 8 Sep 2025 09:43:15 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands [v2] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 06:31:58 GMT, David Holmes wrote: >> @dholmes-ora, are you sure you want this level of code duplication? As is it, the latest version duplicates the following 3 times >> >> if (!c.onThread()) return; >> JavaThread* p = JavaThread::active(); >> if (p == nullptr) { >> tty->print_cr("Failed: JavaThread::active is null"); >> return; >> } >> tty->print(" for thread: "); >> p->print(); >> tty->cr(); > > It is not ideal but the original > > if (!c.onJavaThread()) return; > JavaThread* p = JavaThread::active(); > > is also duplicating the internals both inside `isOnJavaThread()` and in the callers. And what is mainly tripping us up is that `active()` is allowed to return null, but this fix wants to detect a null current thread as a sign of being detached. So we end up calling `Thread::current` multiple times. All of the debug functions that use `active()` are currently broken anyway because they never check it for null (and I'm not even sure they truly expect to work on a delegated JavaThread??). So I see this fix as having two parts: > 1. The `onThread` check takes care of being attached > 2. The `active() == nullptr` check just fixes the current broken code. > > But I still dislike the internal duplication between `onThread` and `active`. Have used these occasionally and am surprised to realize psf and others show frames from the VM operation's caller thread. The duplication around the active() checks is odd. If we are adding: bool onThread() If no current thread, print warning and return false. Callers will return immediately. Could we add e.g.: bool hasActiveThread() If no current thread, print warning and return false. Callers will return immediately. If no active thread, print warning and return false. Callers will return immediately. Callers can go on to use JavaThread* p = JavaThread::active(); without checking (as we currently do). (We are presumably in a debugger session, speed is not the priority, repeating some checks or fetching of active() is not tragic, but this file has less duplication.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27033#discussion_r2329709411 From kbarrett at openjdk.org Mon Sep 8 09:47:14 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 8 Sep 2025 09:47:14 GMT Subject: RFR: 8367014: Rename class Atomic to AtomicAccess In-Reply-To: <12OJX5AFklPfeUixNRHyTHo38EV4dFzLX8Dp-yvMVrI=.bcd6c93a-d462-4ed9-9d34-e8197c7fb04a@github.com> References: <12OJX5AFklPfeUixNRHyTHo38EV4dFzLX8Dp-yvMVrI=.bcd6c93a-d462-4ed9-9d34-e8197c7fb04a@github.com> Message-ID: On Mon, 8 Sep 2025 09:32:43 GMT, Andrew Haley wrote: > `AtomicAccess` is a bit wordy, and this change is going to mess up diffs for backports terribly, but I can't think of a better way to do it. Thanks. There was a bunch of internal to Oracle bike shedding over the names already. But I'm open to more if someone thinks they have a better idea. Note that once we're all done with switching to `Atomic` where appropriate, I don't expect very many direct uses of `AtomicAccess` to remain (though there will be _some_). Diffs for backports are going to get messed up anyway, since most uses of `AtomicAccess` will eventually be switched over to `Atomic` style usage. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27135#issuecomment-3265464120 From kevinw at openjdk.org Mon Sep 8 09:49:12 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 8 Sep 2025 09:49:12 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands [v2] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 10:08:58 GMT, Kerem Kat wrote: >> Prevents segmentation faults during `gdb` sessions. The crashes were caused by the `ResourceMark` constructor being called on a native thread, which is not supported. This happened when invoking debug commands that require a `Thread` or `JavaThread` context from an incorrect thread type. >> >> ### Solution >> >> This change introduces `onThread()` and `onJavaThread()` helper methods to the `Command` class. These methods validate the thread context and ensure `ResourceMark` is only created when on a valid VM thread. All thread-dependent debug commands now use these guards to validate the context, printing a clear error and exiting gracefully upon failure. >> >> ### Testing >> >> Manually verified using `gdb` by calling the modified commands (`ps`, `universe`, `pns`, etc.) from different thread contexts (native, Java, and non-java threads) to ensure they fail gracefully with an error message instead of crashing the debug session. > > Kerem Kat has updated the pull request incrementally with two additional commits since the last revision: > > - add include for global placement new > - remove onJavaThread and check JavaThread::active null where needed src/hotspot/share/utilities/debug.cpp line 520: > 518: Command c("psd"); > 519: if (!c.onThread()) return; > 520: nit - extra line 8-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27033#discussion_r2329722549 From tschatzl at openjdk.org Mon Sep 8 09:50:19 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 8 Sep 2025 09:50:19 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 09:09:49 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * sort includes We would like to finally wrap up this PR as we are about to Propose To Target [JEP 522](openjdk.org/jeps/522) to JDK 26, so it would be nice to get re-reviews from the reviewers that already signed it off if you think it is useful. Nothing much changed actually for months now, particularly in the area of target-specific support, but maybe one more rerun on the more exotic platforms (AIX/PPC, RISC-V) just in case would be fine. Internally it went through Oracle's tier1-8 without any issue again (that is revision https://github.com/openjdk/jdk/pull/23739/commits/b3873d66cd43518d5dc71e060fc52a13372dbfa5, but the changes since then were very cosmetic). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3265474466 From kevinw at openjdk.org Mon Sep 8 09:57:11 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 8 Sep 2025 09:57:11 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands [v2] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 10:08:58 GMT, Kerem Kat wrote: >> Prevents segmentation faults during `gdb` sessions. The crashes were caused by the `ResourceMark` constructor being called on a native thread, which is not supported. This happened when invoking debug commands that require a `Thread` or `JavaThread` context from an incorrect thread type. >> >> ### Solution >> >> This change introduces `onThread()` and `onJavaThread()` helper methods to the `Command` class. These methods validate the thread context and ensure `ResourceMark` is only created when on a valid VM thread. All thread-dependent debug commands now use these guards to validate the context, printing a clear error and exiting gracefully upon failure. >> >> ### Testing >> >> Manually verified using `gdb` by calling the modified commands (`ps`, `universe`, `pns`, etc.) from different thread contexts (native, Java, and non-java threads) to ensure they fail gracefully with an error message instead of crashing the debug session. > > Kerem Kat has updated the pull request incrementally with two additional commits since the last revision: > > - add include for global placement new > - remove onJavaThread and check JavaThread::active null where needed src/hotspot/share/utilities/debug.cpp line 308: > 306: public: > 307: Command(const char* str) : _has_rm(false) { > 308: if (level++ == 0) { "level" can recognise concurrent usage, but doesn't protect against it? The commands still proceed to do their thing, so it doesn't seem right make us skip printing "Executing..." if level was not exactly zero? (Adding the flush() if there is concurrent might be a good thing, it may help if there is output that could be confused, if that is even possible to achieve...) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27033#discussion_r2329749851 From aph at openjdk.org Mon Sep 8 10:18:14 2025 From: aph at openjdk.org (Andrew Haley) Date: Mon, 8 Sep 2025 10:18:14 GMT Subject: RFR: 8367014: Rename class Atomic to AtomicAccess In-Reply-To: References: <12OJX5AFklPfeUixNRHyTHo38EV4dFzLX8Dp-yvMVrI=.bcd6c93a-d462-4ed9-9d34-e8197c7fb04a@github.com> Message-ID: On Mon, 8 Sep 2025 09:44:26 GMT, Kim Barrett wrote: > > `AtomicAccess` is a bit wordy, and this change is going to mess up diffs for backports terribly, but I can't think of a better way to do it. Thanks. > > There was a bunch of internal to Oracle bike shedding over the names already. Sure, I imagine there was! It's a shame when decision making happens behind closed doors in a FOSS project, but public list bikeshedding would have been too much for this change. > Diffs for backports are going to get messed up anyway, since most uses of `AtomicAccess` will eventually be switched over to `Atomic` style usage. That's fair. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27135#issuecomment-3265596419 From fbredberg at openjdk.org Mon Sep 8 10:30:29 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Mon, 8 Sep 2025 10:30:29 GMT Subject: RFR: 8365190: Remove LockingMode related code from share [v4] In-Reply-To: References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> Message-ID: <3pd2IyLkKN1NErQilmGDrxPygkH03OTIelZwKZhDkBs=.7a5176ff-395b-4f82-a0eb-ff50ec1401a2@github.com> On Mon, 8 Sep 2025 07:08:31 GMT, Fredrik Bredberg wrote: >> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR). >> >> This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself. >> >> Passes tier1-tier7 with no added problems. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > New version for David Thank you all for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27041#issuecomment-3265647098 From fbredberg at openjdk.org Mon Sep 8 10:30:30 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Mon, 8 Sep 2025 10:30:30 GMT Subject: Integrated: 8365190: Remove LockingMode related code from share In-Reply-To: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> References: <4pmrLv9G-kotkKQ_B1wEyXSAJ9Vm3cnxditElz641_E=.23c81f11-ece2-4894-ae2f-8763ad343a4d@github.com> Message-ID: <8z9GgG5Q8z1MaKgjotL4d7FtJLtrPv_7J0XcQd9gSpo=.f15375ac-ed3b-47da-aada-9ffb10f4eb56@github.com> On Tue, 2 Sep 2025 08:24:10 GMT, Fredrik Bredberg wrote: > Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all `LockingMode` related code from all platforms (except from zero, which is done in this PR). > > This PR removes `LockingMode` related code from the shared (non-platform specific) files. It also removes the `LockingMode` variable itself. > > Passes tier1-tier7 with no added problems. This pull request has now been integrated. Changeset: a2726968 Author: Fredrik Bredberg URL: https://git.openjdk.org/jdk/commit/a272696813f2e5e896ac9de9985246aaeb9d476c Stats: 1277 lines in 50 files changed: 8 ins; 1137 del; 132 mod 8365190: Remove LockingMode related code from share Reviewed-by: aboldtch, dholmes, ayang, coleenp, lmesnik, rcastanedalo ------------- PR: https://git.openjdk.org/jdk/pull/27041 From fyang at openjdk.org Mon Sep 8 11:33:11 2025 From: fyang at openjdk.org (Fei Yang) Date: Mon, 8 Sep 2025 11:33:11 GMT Subject: RFR: 8367066: RISC-V: refine register selection in MacroAssembler:: decode_klass_not_null In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 08:57:15 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > > Previously, the register selection in MacroAssembler:: decode_klass_not_null is misleading, better to refine it to improve the readability. > > Thanks! > > Running runtime test tier1/2/3... Hi, seems we can further eliminate the use of `t0` replacing it with `tmp`. How about we go like this? diff --git a/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp b/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp index 1436bc02113..89e615b1cbb 100644 --- a/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp +++ b/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp @@ -3402,6 +3402,8 @@ void MacroAssembler::decode_klass_not_null(Register r, Register tmp) { void MacroAssembler::decode_klass_not_null(Register dst, Register src, Register tmp) { assert(UseCompressedClassPointers, "should only be used for compressed headers"); + assert_different_registers(src, tmp); + assert_different_registers(dst, tmp); if (CompressedKlassPointers::base() == nullptr) { if (CompressedKlassPointers::shift() != 0) { @@ -3421,7 +3423,7 @@ void MacroAssembler::decode_klass_not_null(Register dst, Register src, Register mv(xbase, (uintptr_t)CompressedKlassPointers::base()); if (CompressedKlassPointers::shift() != 0) { - Register t = src == dst ? dst : t0; + Register t = dst == xbase ? tmp : dst; assert_different_registers(t, xbase); shadd(dst, src, xbase, t, CompressedKlassPointers::shift()); } else { ------------- PR Review: https://git.openjdk.org/jdk/pull/27138#pullrequestreview-3196116708 From azafari at openjdk.org Mon Sep 8 12:15:13 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 8 Sep 2025 12:15:13 GMT Subject: RFR: 8366363: MemBaseline accesses VMT without using lock [v14] In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 11:46:26 GMT, Johan Sj?len wrote: >> Hi, >> >> The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Missed const-ness Still good. Thanks! ------------- Marked as reviewed by azafari (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27003#pullrequestreview-3196243257 From mli at openjdk.org Mon Sep 8 12:23:45 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 8 Sep 2025 12:23:45 GMT Subject: RFR: 8367098: RISC-V: sync CPU features with related JVM flags for dependant ones Message-ID: <0oRVVWoEhKWyjeC8d-fNSqpNoh4w90srEPWM-tjALqc=.3cbfde7b-6e07-42ab-9e30-64431f680437@github.com> Hi, Can you help to review this patch? some extensions depends on another one, for example, zvbb depends on rvv. That means if rvv is disabled or not supported by the CPU, UseZvbb should return false, and zvbb should not appear in cpu string. But the currently, the cpu string contains zvbb even if rvv is disabled, which is not right. This needs to be fixed. Thanks before fix, output for `-XX-UseRVV -Xlog:cpu*=debug` [0.064s][info ][os,cpu] CPU: total 32 (initial active 32) qemu rv64 rvi rvm rva rvf rvd rvc rvv zicbom zicboz zicbop zba zbb zbs zbkb zcb zfa zfh zfhmin zicsr zifencei zic64b ztso zacas zvbb zvbc zvfh zicond after fix, output for `-XX-UseRVV -Xlog:cpu*=debug` [0.065s][info ][os,cpu] CPU: total 32 (initial active 32) qemu rv64 rvi rvm rva rvf rvd rvc zicbom zicboz zicbop zba zbb zbs zbkb zcb zfa zfh zfhmin zicsr zifencei zic64b ztso zacas zicond ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/27142/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27142&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367098 Stats: 21 lines in 1 file changed: 2 ins; 0 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/27142.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27142/head:pull/27142 PR: https://git.openjdk.org/jdk/pull/27142 From mli at openjdk.org Mon Sep 8 12:52:10 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 8 Sep 2025 12:52:10 GMT Subject: RFR: 8367066: RISC-V: refine register selection in MacroAssembler:: decode_klass_not_null In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 11:30:46 GMT, Fei Yang wrote: > Hi, seems we can further eliminate the use of `t0` replacing it with `tmp`. How about we go like this? > > ``` > diff --git a/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp b/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp > index 1436bc02113..89e615b1cbb 100644 > --- a/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp > +++ b/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp > @@ -3402,6 +3402,8 @@ void MacroAssembler::decode_klass_not_null(Register r, Register tmp) { > > void MacroAssembler::decode_klass_not_null(Register dst, Register src, Register tmp) { > assert(UseCompressedClassPointers, "should only be used for compressed headers"); > + assert_different_registers(src, tmp); > + assert_different_registers(dst, tmp); > > if (CompressedKlassPointers::base() == nullptr) { > if (CompressedKlassPointers::shift() != 0) { > @@ -3421,7 +3423,7 @@ void MacroAssembler::decode_klass_not_null(Register dst, Register src, Register > mv(xbase, (uintptr_t)CompressedKlassPointers::base()); > > if (CompressedKlassPointers::shift() != 0) { > - Register t = src == dst ? dst : t0; > + Register t = dst == xbase ? tmp : dst; > assert_different_registers(t, xbase); > shadd(dst, src, xbase, t, CompressedKlassPointers::shift()); > } else { > ``` I applied your suggested patch, and it trigger an assert at `assert_different_registers(dst, tmp);`, assert(regs[i] != regs[j]) failed: regs[0] and regs[1] are both: t2 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27138#issuecomment-3266152717 From duke at openjdk.org Mon Sep 8 14:45:15 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 8 Sep 2025 14:45:15 GMT Subject: RFR: 8366881: Parallel: Obsolete HeapMaximumCompactionInterval [v2] In-Reply-To: References: Message-ID: <0rPxUVUGqNpsWYVJAbnMPAifk6vwVu5G7Zm_rXzLZio=.0e1afb81-5486-4baf-865c-a4382421381a@github.com> On Fri, 5 Sep 2025 09:30:45 GMT, Albert Mingkun Yang wrote: >> Remove a produce flag that controls maximum-compaction during a full-gc. The existing criteria, such as heap usage, old-gen density, are enough for deciding maximum-compaction. >> >> Test: tier1-3 > > Albert Mingkun Yang 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 three additional commits since the last revision: > > - review > - Merge branch 'master' into pgc-max-compaction-obsolete > - pgc-max-compaction-obsolete src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 342: > 340: // No need for max-compaction in this context. > 341: const bool should_do_max_compaction = false; > 342: PSParallelCompact::invoke(clear_all_soft_refs, should_do_max_compaction); Perhaps this might do too, without the need for an additional variable? Suggestion: PSParallelCompact::invoke(clear_all_soft_refs, false /* should_do_max_compaction */); src/hotspot/share/runtime/arguments.cpp line 571: > 569: > 570: { "PretenureSizeThreshold", JDK_Version::undefined(), JDK_Version::jdk(26), JDK_Version::jdk(27) }, > 571: { "HeapMaximumCompactionInterval",JDK_Version::undefined(), JDK_Version::jdk(26), JDK_Version::jdk(27) }, Maybe add a space? Suggestion: { "HeapMaximumCompactionInterval", JDK_Version::undefined(), JDK_Version::jdk(26), JDK_Version::jdk(27) }, ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27091#discussion_r2330468557 PR Review Comment: https://git.openjdk.org/jdk/pull/27091#discussion_r2330473880 From duke at openjdk.org Mon Sep 8 14:50:14 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 8 Sep 2025 14:50:14 GMT Subject: RFR: 8366881: Parallel: Obsolete HeapMaximumCompactionInterval [v2] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 09:30:45 GMT, Albert Mingkun Yang wrote: >> Remove a produce flag that controls maximum-compaction during a full-gc. The existing criteria, such as heap usage, old-gen density, are enough for deciding maximum-compaction. >> >> Test: tier1-3 > > Albert Mingkun Yang 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 three additional commits since the last revision: > > - review > - Merge branch 'master' into pgc-max-compaction-obsolete > - pgc-max-compaction-obsolete src/hotspot/share/gc/parallel/psParallelCompact.cpp line 829: > 827: } > 828: > 829: bool PSParallelCompact::check_maximum_compaction(bool should_do_max_compaction, I'd expect this method not to have any side effect, does it? If that's the case, you could consider not having `should_do_max_compaction` as a parameter, and replace calls to `check_maximum_compaction` with `should_do_max_compaction || check_maximum_compaction(...)`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27091#discussion_r2330487908 From ayang at openjdk.org Mon Sep 8 14:59:13 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 8 Sep 2025 14:59:13 GMT Subject: RFR: 8366881: Parallel: Obsolete HeapMaximumCompactionInterval [v2] In-Reply-To: <0rPxUVUGqNpsWYVJAbnMPAifk6vwVu5G7Zm_rXzLZio=.0e1afb81-5486-4baf-865c-a4382421381a@github.com> References: <0rPxUVUGqNpsWYVJAbnMPAifk6vwVu5G7Zm_rXzLZio=.0e1afb81-5486-4baf-865c-a4382421381a@github.com> Message-ID: On Mon, 8 Sep 2025 14:40:28 GMT, Francesco Andreuzzi wrote: >> Albert Mingkun Yang 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 three additional commits since the last revision: >> >> - review >> - Merge branch 'master' into pgc-max-compaction-obsolete >> - pgc-max-compaction-obsolete > > src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 342: > >> 340: // No need for max-compaction in this context. >> 341: const bool should_do_max_compaction = false; >> 342: PSParallelCompact::invoke(clear_all_soft_refs, should_do_max_compaction); > > Perhaps this might do too, without the need for an additional variable? > Suggestion: > > PSParallelCompact::invoke(clear_all_soft_refs, false /* should_do_max_compaction */); True; I chose this way mostly for consistency -- `satisfy_failed_allocation` uses local var instead of comment. > src/hotspot/share/gc/parallel/psParallelCompact.cpp line 829: > >> 827: } >> 828: >> 829: bool PSParallelCompact::check_maximum_compaction(bool should_do_max_compaction, > > I'd expect this method not to have any side effect, does it? > > If that's the case, you could consider not having `should_do_max_compaction` as a parameter, and replace calls to `check_maximum_compaction` with `should_do_max_compaction || check_maximum_compaction(...)`. This method is side-effect free. I chose this style so that all criteria on deciding max-compaction are grouped in a single location. > src/hotspot/share/runtime/arguments.cpp line 571: > >> 569: >> 570: { "PretenureSizeThreshold", JDK_Version::undefined(), JDK_Version::jdk(26), JDK_Version::jdk(27) }, >> 571: { "HeapMaximumCompactionInterval",JDK_Version::undefined(), JDK_Version::jdk(26), JDK_Version::jdk(27) }, > > Maybe add a space? > Suggestion: > > { "HeapMaximumCompactionInterval", JDK_Version::undefined(), JDK_Version::jdk(26), JDK_Version::jdk(27) }, That did cross my mind. However, I went for the current version as I feel aligning with previous line (identical obsolete/expire version) is more important. WDYT? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27091#discussion_r2330489484 PR Review Comment: https://git.openjdk.org/jdk/pull/27091#discussion_r2330497252 PR Review Comment: https://git.openjdk.org/jdk/pull/27091#discussion_r2330503549 From duke at openjdk.org Mon Sep 8 15:04:27 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 8 Sep 2025 15:04:27 GMT Subject: Withdrawn: 8365661: oops/resolvedMethodEntry.hpp could use default copy constructor In-Reply-To: <3V-g6lGBjx--oFb81q4dNzFWKNlHH7OumD5t-eWjoAY=.1d066012-82db-4d74-ad6e-c3b7e1ff1634@github.com> References: <3V-g6lGBjx--oFb81q4dNzFWKNlHH7OumD5t-eWjoAY=.1d066012-82db-4d74-ad6e-c3b7e1ff1634@github.com> Message-ID: <1_qIaWHDr6W77RkZL3XOWq2ksQP4sKWwOyygBV3zuzg=.7a666941-803e-4035-9c55-243726f167ad@github.com> On Mon, 18 Aug 2025 08:30:27 GMT, Francesco Andreuzzi wrote: > We may replace the non-default copy constructor and assignment with the default ones. It seems that all we have to do is a member-wise shallow copy. This would also make the class `TriviallyCopiable`. > > This change fixes a build failure I'm getting with clang20: > > /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:43:12: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedMethodEntry' [-Werror,-Wnontrivial-memcall] > 43 | memset(this, 0, sizeof(*this)); > | ^ > /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:43:12: note: explicitly cast the pointer to silence this warning > 43 | memset(this, 0, sizeof(*this)); > | ^ > | (void*) > /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:48:12: error: first argument in call to 'memset' is a pointer to non-trivially copyable type 'ResolvedMethodEntry' [-Werror,-Wnontrivial-memcall] > 48 | memset(this, 0, sizeof(*this)); > | ^ > /jdk/src/hotspot/share/oops/resolvedMethodEntry.cpp:48:12: note: explicitly cast the pointer to silence this warning > 48 | memset(this, 0, sizeof(*this)); > | ^ > | (void*) > 2 errors generated. > > > Testing: > - [x] tier1 fast-debug > - [x] tier2 fast-debug This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/26818 From duke at openjdk.org Mon Sep 8 15:04:30 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 8 Sep 2025 15:04:30 GMT Subject: RFR: 8366881: Parallel: Obsolete HeapMaximumCompactionInterval [v2] In-Reply-To: References: <0rPxUVUGqNpsWYVJAbnMPAifk6vwVu5G7Zm_rXzLZio=.0e1afb81-5486-4baf-865c-a4382421381a@github.com> Message-ID: On Mon, 8 Sep 2025 14:53:16 GMT, Albert Mingkun Yang wrote: >> src/hotspot/share/runtime/arguments.cpp line 571: >> >>> 569: >>> 570: { "PretenureSizeThreshold", JDK_Version::undefined(), JDK_Version::jdk(26), JDK_Version::jdk(27) }, >>> 571: { "HeapMaximumCompactionInterval",JDK_Version::undefined(), JDK_Version::jdk(26), JDK_Version::jdk(27) }, >> >> Maybe add a space? >> Suggestion: >> >> { "HeapMaximumCompactionInterval", JDK_Version::undefined(), JDK_Version::jdk(26), JDK_Version::jdk(27) }, > > That did cross my mind. However, I went for the current version as I feel aligning with previous line (identical obsolete/expire version) is more important. > > WDYT? What I would do in this case is to make L571 look nice and adapt the alignment of L570 accordingly, but I'm not sure if there's anything about this in the style guide. Feel free to ignore the comment ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27091#discussion_r2330523844 From duke at openjdk.org Mon Sep 8 15:04:28 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 8 Sep 2025 15:04:28 GMT Subject: RFR: 8366881: Parallel: Obsolete HeapMaximumCompactionInterval [v2] In-Reply-To: References: Message-ID: <5w5yRX_uPXBgAiZ-_gIfj1RG_PmM9NiDn_VcWHpapz8=.2944fcab-bc79-4b14-a6ea-0d6b440b3540@github.com> On Fri, 5 Sep 2025 09:30:45 GMT, Albert Mingkun Yang wrote: >> Remove a produce flag that controls maximum-compaction during a full-gc. The existing criteria, such as heap usage, old-gen density, are enough for deciding maximum-compaction. >> >> Test: tier1-3 > > Albert Mingkun Yang 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 three additional commits since the last revision: > > - review > - Merge branch 'master' into pgc-max-compaction-obsolete > - pgc-max-compaction-obsolete Marked as reviewed by fandreuz at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/27091#pullrequestreview-3196945742 From lmesnik at openjdk.org Mon Sep 8 15:31:54 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 8 Sep 2025 15:31:54 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v4] In-Reply-To: References: Message-ID: > This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result. > The related fix here: > https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56 > Hope fix became clarere now. > > There 2 problems in this post_meth_exit: > 1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode. > 2) The method `get_jvmti_thread_state` should be called when thread is in vm state only. > > The fix adds `post_method_exit_transition` to have single exit point with oop restoration. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: reverted to single method. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27112/files - new: https://git.openjdk.org/jdk/pull/27112/files/0bd9c98d..118d39e1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27112&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27112&range=02-03 Stats: 39 lines in 2 files changed: 5 ins; 18 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/27112.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27112/head:pull/27112 PR: https://git.openjdk.org/jdk/pull/27112 From lmesnik at openjdk.org Mon Sep 8 15:40:17 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 8 Sep 2025 15:40:17 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v5] In-Reply-To: References: Message-ID: > This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result. > The related fix here: > https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56 > Hope fix became clarere now. > > There 2 problems in this post_meth_exit: > 1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode. > 2) The method `get_jvmti_thread_state` should be called when thread is in vm state only. > > The fix adds `post_method_exit_transition` to have single exit point with oop restoration. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: more changes reverted ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27112/files - new: https://git.openjdk.org/jdk/pull/27112/files/118d39e1..ea941c2d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27112&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27112&range=03-04 Stats: 5 lines in 2 files changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27112.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27112/head:pull/27112 PR: https://git.openjdk.org/jdk/pull/27112 From mdoerr at openjdk.org Mon Sep 8 15:40:17 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 8 Sep 2025 15:40:17 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v5] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 15:36:45 GMT, Leonid Mesnik wrote: >> This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result. >> The related fix here: >> https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56 >> Hope fix became clarere now. >> >> There 2 problems in this post_meth_exit: >> 1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode. >> 2) The method `get_jvmti_thread_state` should be called when thread is in vm state only. >> >> The fix adds `post_method_exit_transition` to have single exit point with oop restoration. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > more changes reverted src/hotspot/share/prims/jvmtiExport.cpp line 1844: > 1842: BasicType type = current_frame.interpreter_frame_result(&oop_result, &value); > 1843: assert(type == T_VOID || current_frame.interpreter_frame_expression_stack_size() > 0, > 1844: "Stack shouldn't be empty"); I think this assertion needs an adaptation. The expression stack can be empty for native method calls. The result does not necessarily need to be on the expression stack depending on the platform. Or what else is the reason it is expected to be non-empty? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27112#discussion_r2330625454 From lmesnik at openjdk.org Mon Sep 8 15:59:58 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 8 Sep 2025 15:59:58 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v6] In-Reply-To: References: Message-ID: > This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result. > The related fix here: > https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56 > Hope fix became clarere now. > > There 2 problems in this post_meth_exit: > 1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode. > 2) The method `get_jvmti_thread_state` should be called when thread is in vm state only. > > The fix adds `post_method_exit_transition` to have single exit point with oop restoration. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: comments fixed. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27112/files - new: https://git.openjdk.org/jdk/pull/27112/files/ea941c2d..03c172a9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27112&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27112&range=04-05 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27112.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27112/head:pull/27112 PR: https://git.openjdk.org/jdk/pull/27112 From mdoerr at openjdk.org Mon Sep 8 16:12:12 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 8 Sep 2025 16:12:12 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v5] In-Reply-To: References: Message-ID: <26fQtgWL5JQWUBmFezDRvr42EDdJbXXUQTl2IAawOKA=.a0b2b356-039e-4828-9d0d-91295f374826@github.com> On Mon, 8 Sep 2025 15:36:45 GMT, Martin Doerr wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> more changes reverted > > src/hotspot/share/prims/jvmtiExport.cpp line 1844: > >> 1842: BasicType type = current_frame.interpreter_frame_result(&oop_result, &value); >> 1843: assert(type == T_VOID || current_frame.interpreter_frame_expression_stack_size() > 0, >> 1844: "Stack shouldn't be empty"); > > I think this assertion needs an adaptation. The expression stack can be empty for native method calls. The result does not necessarily need to be on the expression stack depending on the platform. > Or what else is the reason it is expected to be non-empty? Thanks for adding the native check! Looks good to me, now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27112#discussion_r2330715809 From sgehwolf at openjdk.org Mon Sep 8 16:15:22 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 8 Sep 2025 16:15:22 GMT Subject: RFR: 8365606: Container code should not be using jlong/julong Message-ID: Please review this refactoring to the container code in Hotspot to no longer use `jlong` and `julong`. Instead this patch proposes to move to `size_t` and `ssize_t` types. In a similar manner as was done with the `os::xxx` APIs in [JDK-8357086](https://bugs.openjdk.org/browse/JDK-8357086). With this patch the use of `OSCONTAINER_ERROR` (`-2`) is largely gone. It's not terribly useful to have to warrant the many special cases throughout the code. In this patch failure handling is being done by returning a boolean for success/failure of reading a value from the interface files. The notion of "not supported" is being folded into `-1` (unlimited for limit values, not supported for usage values). Note that the code already treated `-1` and `-2` similarly. The few cases where `-2` was actually used was in `VM.info` output or `hserr` files. Where `-2` was being treated as "not supported". However, file-reading errors would also fall into the `-2` bucket making the "not supported" case not 100% distinguishable either. The simplification here proposes to do away with `-2` (other than in traces) and fold it into the `-1` (unlimited) bucket as that's how the code has been handling those values (even prior to this patch). Testing: - [x] GHA (tier1) - [x] cgroup gtests and hotspot container tests on cgroup v1 and cgroup v2 (no regressions noted). Thoughts? ------------- Commit messages: - Improve commenting in os_linux.cpp - Fix compilation error on arm (32 bit) - Merge branch 'master' into jdk-8365606-size_t-container-subsys - Modify OSContainer API to use ssize_t/size_t - 8365606: container code should not be using julong Changes: https://git.openjdk.org/jdk/pull/27125/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27125&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365606 Stats: 873 lines in 14 files changed: 300 ins; 67 del; 506 mod Patch: https://git.openjdk.org/jdk/pull/27125.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27125/head:pull/27125 PR: https://git.openjdk.org/jdk/pull/27125 From sgehwolf at openjdk.org Mon Sep 8 17:54:10 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 8 Sep 2025 17:54:10 GMT Subject: RFR: 8360651: Create OSContainer API for memory limit [v2] In-Reply-To: References: Message-ID: > Please review this small addition to add a new `OSContainer::has_memory_limit()` API (Linux only - as with the entire OSContainer API) in preparation for [JDK-8350596](https://bugs.openjdk.org/browse/JDK-8350596) which proposes to increase the default `MaxRAMPercentage` when this new API returns true. The patch is pretty trivial. It's only the testing which amounts to the most lines in this patch. > > Testing: > - [x] GHA > - [x] Hotspot container tests on x86_64 Linux on cgroup v1 and cgroup v2 (including the new tests). > > Thoughts? Severin Gehwolf 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 four additional commits since the last revision: - Merge branch 'master' into jdk-8360651-mem-limit-api - MemoryLimitTest whitespace fixes. - TestContainerMemory whitespace fixes. - 8360651: Create OSContainer API for memory limit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26020/files - new: https://git.openjdk.org/jdk/pull/26020/files/c1de932d..571de6f3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26020&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26020&range=00-01 Stats: 128282 lines in 3429 files changed: 76338 ins; 33209 del; 18735 mod Patch: https://git.openjdk.org/jdk/pull/26020.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26020/head:pull/26020 PR: https://git.openjdk.org/jdk/pull/26020 From lmesnik at openjdk.org Mon Sep 8 18:31:51 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 8 Sep 2025 18:31:51 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v7] In-Reply-To: References: Message-ID: > This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result. > The related fix here: > https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56 > Hope fix became clarere now. > > There 2 problems in this post_meth_exit: > 1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode. > 2) The method `get_jvmti_thread_state` should be called when thread is in vm state only. > > The fix adds `post_method_exit_transition` to have single exit point with oop restoration. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: interopnly_state should be saved ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27112/files - new: https://git.openjdk.org/jdk/pull/27112/files/03c172a9..3a169797 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27112&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27112&range=05-06 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27112.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27112/head:pull/27112 PR: https://git.openjdk.org/jdk/pull/27112 From lmesnik at openjdk.org Mon Sep 8 18:35:15 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 8 Sep 2025 18:35:15 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v3] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 05:42:19 GMT, David Holmes wrote: >> Leonid Mesnik 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 five additional commits since the last revision: >> >> - small improvements >> - Merge branch 'master' of https://github.com/openjdk/jdk into 8365192-2 >> - comment >> - comment is fixed. >> - fix > > src/hotspot/share/prims/jvmtiExport.cpp line 1857: > >> 1855: BasicType type, Handle result, jvalue value) { >> 1856: JvmtiThreadState* state; // should be initialized in vm state only >> 1857: JavaThread* current = thread; // for JRT_BLOCK > > If `thread` is always the current thread then I suggest just calling it `current` in the first place. This line no remains unchanged. I also reverted some unnecessary changes so let keep fix minimal. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27112#discussion_r2331054856 From ayang at openjdk.org Mon Sep 8 19:17:17 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 8 Sep 2025 19:17:17 GMT Subject: RFR: 8366881: Parallel: Obsolete HeapMaximumCompactionInterval [v2] In-Reply-To: References: Message-ID: <3yMnY4hQ6tIgs5zhEta6LwtdHN5rarpjn_2Rp3mrizE=.c1d9efb0-a3fb-417e-972d-a6af29500e0e@github.com> On Fri, 5 Sep 2025 09:30:45 GMT, Albert Mingkun Yang wrote: >> Remove a produce flag that controls maximum-compaction during a full-gc. The existing criteria, such as heap usage, old-gen density, are enough for deciding maximum-compaction. >> >> Test: tier1-3 > > Albert Mingkun Yang 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 three additional commits since the last revision: > > - review > - Merge branch 'master' into pgc-max-compaction-obsolete > - pgc-max-compaction-obsolete Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27091#issuecomment-3267611323 From ayang at openjdk.org Mon Sep 8 19:17:18 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 8 Sep 2025 19:17:18 GMT Subject: Integrated: 8366881: Parallel: Obsolete HeapMaximumCompactionInterval In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 12:16:28 GMT, Albert Mingkun Yang wrote: > Remove a produce flag that controls maximum-compaction during a full-gc. The existing criteria, such as heap usage, old-gen density, are enough for deciding maximum-compaction. > > Test: tier1-3 This pull request has now been integrated. Changeset: 3e68d7d9 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/3e68d7d99fcf3039395ba94234ecbebe8e98c754 Stats: 57 lines in 5 files changed: 10 ins; 27 del; 20 mod 8366881: Parallel: Obsolete HeapMaximumCompactionInterval Reviewed-by: iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/27091 From mli at openjdk.org Mon Sep 8 20:00:21 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 8 Sep 2025 20:00:21 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap Message-ID: Hi, Can you help to review this patch? Currently, the cpu features of riscv are stored in separate RVFeature subclasses. But to support the store/restore CPU features for aot in the future, we need to store the cpu features in a continuous memory. As the riscv extensions are introduced continuously, I think it's better to do it via an simple bitmap at the beginning. Currently, just suppose the non-extension features will not be stored in aot image, so I also split the extension and non-extenion features. When we implement the related aot feature in the short future, we can revisit the way of splitting the features. Currently, just change the storage way of cpu features, lay the foundation for future aot. Thanks ------------- Commit messages: - refine - split extension and non-extension features - remove RVFeatureValue::_enabled - rename own to current - initial commit Changes: https://git.openjdk.org/jdk/pull/27152/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27152&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367103 Stats: 214 lines in 2 files changed: 144 ins; 4 del; 66 mod Patch: https://git.openjdk.org/jdk/pull/27152.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27152/head:pull/27152 PR: https://git.openjdk.org/jdk/pull/27152 From vaivanov at openjdk.org Mon Sep 8 21:12:18 2025 From: vaivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 8 Sep 2025 21:12:18 GMT Subject: RFR: 8363858: [perf] OptimizeFill may use wide set of intrinsics [v3] In-Reply-To: References: Message-ID: On Wed, 3 Sep 2025 22:11:17 GMT, Vladimir Ivanov wrote: >> Default mode should use OptimizeFill=true option for the SRF platform. > > Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8363858: [perf] OptimizeFill may use wide set of intrinsics Perf data for the Xeon 6740E looks as: Xeon 6740E | size | jdk_def | jdk_OptFill | p/def -- | -- | -- | -- | -- ArraysFill.testByteFill | 16 | 152113.563 | 173028.75 | 1.14 ArraysFill.testByteFill | 31 | 125889.446 | 212458.124 | 1.69 ArraysFill.testByteFill | 250 | 57942.562 | 148391.738 | 2.56 ArraysFill.testByteFill | 266 | 44883.928 | 156986.22 | 3.50 ArraysFill.testByteFill | 511 | 61848.425 | 130192.732 | 2.11 ArraysFill.testByteFill | 2047 | 32242.521 | 39893.863 | 1.24 ArraysFill.testByteFill | 2048 | 31918.795 | 40665.974 | 1.27 ArraysFill.testByteFill | 8195 | 10685.801 | 10126.615 | 0.95 ArraysFill.testIntFill | 16 | 145059.116 | 318660.232 | 2.20 ArraysFill.testIntFill | 31 | 131312.049 | 227632.469 | 1.73 ArraysFill.testIntFill | 250 | 73997.421 | 81060.479 | 1.10 ArraysFill.testIntFill | 266 | 68072.273 | 77967.322 | 1.15 ArraysFill.testIntFill | 511 | 39691.774 | 45220.274 | 1.14 ArraysFill.testIntFill | 2047 | 11499.726 | 11295.527 | 0.98 ArraysFill.testIntFill | 2048 | 11240.285 | 11419.196 | 1.02 ArraysFill.testIntFill | 8195 | 2758.273 | 1310.374 | 0.48 ArraysFill.testLongFill | 16 | 212459.292 | 212458.565 | 1.00 ArraysFill.testLongFill | 31 | 131924.591 | 137124.526 | 1.04 ArraysFill.testLongFill | 250 | 43105.961 | 43131.914 | 1.00 ArraysFill.testLongFill | 266 | 42149.578 | 42154.248 | 1.00 ArraysFill.testLongFill | 511 | 23358.361 | 23358.681 | 1.00 ArraysFill.testLongFill | 2047 | 6120.952 | 6121.333 | 1.00 ArraysFill.testLongFill | 2048 | 5781.826 | 5788.489 | 1.00 ArraysFill.testLongFill | 8195 | 615.994 | 616.218 | 1.00 ArraysFill.testShortFill | 16 | 152050.701 | 353826.527 | 2.33 ArraysFill.testShortFill | 31 | 136798.898 | 212330.48 | 1.55 ArraysFill.testShortFill | 250 | 58773.76 | 99592.044 | 1.69 ArraysFill.testShortFill | 266 | 91052.769 | 93735.404 | 1.03 ArraysFill.testShortFill | 511 | 65312.819 | 77820.206 | 1.19 ArraysFill.testShortFill | 2047 | 21704.419 | 20440.256 | 0.94 ArraysFill.testShortFill | 2048 | 21657.535 | 21625.922 | 1.00 ArraysFill.testShortFill | 8195 | 5920.221 | 5872.366 | 0.99 I.e. most of test cases reports better score with intrinsic code. Reported possible 2x drop (for example, ArraysFill.testIntFill, size=8195) relates to store_split metric and should be fixed by PR 26747. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26974#issuecomment-3268030499 From cslucas at openjdk.org Mon Sep 8 21:47:21 2025 From: cslucas at openjdk.org (Cesar Soares Lucas) Date: Mon, 8 Sep 2025 21:47:21 GMT Subject: Integrated: 8364936: Shenandoah: Switch nmethod entry barriers to conc_instruction_and_data_patch In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 00:02:42 GMT, Cesar Soares Lucas wrote: > Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64. > > The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%. This pull request has now been integrated. Changeset: 81a1e8e1 Author: Cesar Soares Lucas URL: https://git.openjdk.org/jdk/commit/81a1e8e1363446de499a59fc706221efde12dd86 Stats: 28 lines in 12 files changed: 0 ins; 19 del; 9 mod 8364936: Shenandoah: Switch nmethod entry barriers to conc_instruction_and_data_patch Reviewed-by: fyang, dzhang, kdnilsen, wkemper ------------- PR: https://git.openjdk.org/jdk/pull/26999 From dlong at openjdk.org Mon Sep 8 23:27:48 2025 From: dlong at openjdk.org (Dean Long) Date: Mon, 8 Sep 2025 23:27:48 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v5] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 21:26:22 GMT, Dean Long wrote: >> This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value. Further, it takes a fast-path that uses the previous direct store when at a safepoint. Combined, these changes should get us back to almost where we were before in terms of overhead. If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > one unconditional release should be enough I need another review for this. Any volunteers? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26399#issuecomment-3268323422 From fyang at openjdk.org Mon Sep 8 23:50:16 2025 From: fyang at openjdk.org (Fei Yang) Date: Mon, 8 Sep 2025 23:50:16 GMT Subject: RFR: 8367066: RISC-V: refine register selection in MacroAssembler:: decode_klass_not_null In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 08:57:15 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > > Previously, the register selection in MacroAssembler:: decode_klass_not_null is misleading, better to refine it to improve the readability. > > Thanks! > > Running runtime test tier1/2/3... Yes, we still need one extra change to guarantee that dst != tmp, which we can do with a TEMP_DEF effect for dst. I tried adding this change and it seems to work. @@ -8936,7 +8941,7 @@ instruct encodeKlass_not_null(iRegNNoSp dst, iRegP src) %{ instruct decodeKlass_not_null(iRegPNoSp dst, iRegN src, iRegPNoSp tmp) %{ match(Set dst (DecodeNKlass src)); - effect(TEMP tmp); + effect(TEMP_DEF dst, TEMP tmp); ins_cost(ALU_COST); format %{ "decode_klass_not_null $dst, $src\t#@decodeKlass_not_null" %} ------------- PR Comment: https://git.openjdk.org/jdk/pull/27138#issuecomment-3268370293 From kbarrett at openjdk.org Tue Sep 9 01:09:58 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 9 Sep 2025 01:09:58 GMT Subject: RFR: 8367051: Build failure with clang on linux and AIX after switch to C++17 Message-ID: 8367051: Build failure with clang on linux and AIX after switch to C++17 Please review this change to work around build failures with clang on some platforms after the switch to C++17. C++17 made the exception specification part of a function's type. Some standard libraries declare C library functions as noexcept. If HotSpot has a forbidding declaration for such a function (without a noexcept spec) before including the standard library header, clang reports this as an error (not just a warning that could be suppressed, a hard error). If the standard library header containing the noexpect declaration is first, then clang does *not* complain about the following forbidding declaration that doesn't have an exception spec. gcc permits either order. So the workaround consists of ensuring all the standard library headers for forbidden functions are included before the forbidding declarations. Exploration of other approaches to follow, but for now we need to fix the build errors. Testing: mach5 tier1 GHA saniticy checks in progress ------------- Commit messages: - another clang workaround for forbidding C functions Changes: https://git.openjdk.org/jdk/pull/27154/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27154&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367051 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27154.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27154/head:pull/27154 PR: https://git.openjdk.org/jdk/pull/27154 From kbarrett at openjdk.org Tue Sep 9 03:00:32 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 9 Sep 2025 03:00:32 GMT Subject: RFR: 8366057: HotSpot Style Guide should permit trailing return types [v2] In-Reply-To: References: Message-ID: <3BK_mYdIzPe4LIz8ntBVa5Hhph4kHIP1TxtGoAslqYw=.ba18dfad-8046-4e30-b0d4-e3a1ccc4cefe@github.com> > Please review this change to the HotSpot Style Guide to permit trailing return > types for functions. > > This is a modification of the Style Guide, so rough consensus among the > HotSpot Group members is required to make this change. Only Group members > should vote for approval (via the github PR), though reasoned objections or > comments from anyone will be considered. A decision on this proposal will not > be made before Monday 8-September-2025 at 12h00 UTC. > > Since we're piggybacking on github PRs here, please use the PR review process > to approve (click on Review Changes > Approve), rather than sending a "vote: > yes" email reply that would be normal for a CFV. Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into trailing-return-type - permit trailing return types ------------- Changes: https://git.openjdk.org/jdk/pull/26923/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26923&range=01 Stats: 85 lines in 2 files changed: 81 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26923.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26923/head:pull/26923 PR: https://git.openjdk.org/jdk/pull/26923 From kbarrett at openjdk.org Tue Sep 9 03:04:26 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 9 Sep 2025 03:04:26 GMT Subject: RFR: 8366057: HotSpot Style Guide should permit trailing return types [v2] In-Reply-To: <3BK_mYdIzPe4LIz8ntBVa5Hhph4kHIP1TxtGoAslqYw=.ba18dfad-8046-4e30-b0d4-e3a1ccc4cefe@github.com> References: <3BK_mYdIzPe4LIz8ntBVa5Hhph4kHIP1TxtGoAslqYw=.ba18dfad-8046-4e30-b0d4-e3a1ccc4cefe@github.com> Message-ID: On Tue, 9 Sep 2025 03:00:32 GMT, Kim Barrett wrote: >> Please review this change to the HotSpot Style Guide to permit trailing return >> types for functions. >> >> This is a modification of the Style Guide, so rough consensus among the >> HotSpot Group members is required to make this change. Only Group members >> should vote for approval (via the github PR), though reasoned objections or >> comments from anyone will be considered. A decision on this proposal will not >> be made before Monday 8-September-2025 at 12h00 UTC. >> >> Since we're piggybacking on github PRs here, please use the PR review process >> to approve (click on Review Changes > Approve), rather than sending a "vote: >> yes" email reply that would be normal for a CFV. > > Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' into trailing-return-type > - permit trailing return types There were merge conflicts with JDK-8314488, due to nearby changes. The conflicts have been resolved, and there weren't any modifications to the changes being proposed by this PR. But some re-reviews are still needed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26923#issuecomment-3268681741 From fyang at openjdk.org Tue Sep 9 04:09:26 2025 From: fyang at openjdk.org (Fei Yang) Date: Tue, 9 Sep 2025 04:09:26 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 09:09:49 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * sort includes > We would like to finally wrap up this PR as we are about to Propose To Target [JEP 522](openjdk.org/jeps/522) to JDK 26, so it would be nice to get re-reviews from the reviewers that already signed it off if you think it is useful. > > Nothing much changed actually for months now, particularly in the area of target-specific support, but maybe one more rerun on the more exotic platforms (AIX/PPC, RISC-V) just in case would be fine. > > Internally it went through Oracle's tier1-8 without any issue again (that is revision [b3873d6](https://github.com/openjdk/jdk/commit/b3873d66cd43518d5dc71e060fc52a13372dbfa5), but the changes since then were very cosmetic). Hi @tschatzl : I witnessed some conflicts when applying this on latest jdk head. Maybe you can do another merge and rebase? I can help rerun the tests on RISC-V. (Note that there is one failing test: `test/hotspot/jtreg/gtest/GTestWrapper.java` if I use the same base as in your repo, and that issue has been resolved by [JDK-8366897](https://bugs.openjdk.org/browse/JDK-8366897)) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3268789193 From dzhang at openjdk.org Tue Sep 9 04:22:41 2025 From: dzhang at openjdk.org (Dingli Zhang) Date: Tue, 9 Sep 2025 04:22:41 GMT Subject: RFR: 8367137: RISC-V: Detect Zicboz block size via hwprobe Message-ID: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> Hi, Can you help to review this patch? Thanks! We can extends RISC-V hwprobe support to include `RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`. The probed value is recorded in VM_Version::zicboz_block_size and then used to set the global CacheLineSize. This ensures correct usage of the Zicboz extension, as block zeroing instructions operate on cache-line granularity. FYI: https://docs.kernel.org/arch/riscv/hwprobe.html ------------- Commit messages: - fix typo - RISC-V: Add riscv_hwprobe syscall for zicboz block size Changes: https://git.openjdk.org/jdk/pull/27155/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27155&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367137 Stats: 51 lines in 3 files changed: 11 ins; 0 del; 40 mod Patch: https://git.openjdk.org/jdk/pull/27155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27155/head:pull/27155 PR: https://git.openjdk.org/jdk/pull/27155 From dzhang at openjdk.org Tue Sep 9 04:29:41 2025 From: dzhang at openjdk.org (Dingli Zhang) Date: Tue, 9 Sep 2025 04:29:41 GMT Subject: RFR: 8367137: RISC-V: Detect Zicboz block size via hwprobe [v2] In-Reply-To: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> References: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> Message-ID: > Hi, > Can you help to review this patch? Thanks! > > We can extends RISC-V hwprobe support to include `RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`. > The probed value is recorded in VM_Version::zicboz_block_size and then used to set the global CacheLineSize. > This ensures correct usage of the Zicboz extension, as block zeroing instructions operate on cache-line granularity. > > FYI: https://docs.kernel.org/arch/riscv/hwprobe.html Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: fix typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27155/files - new: https://git.openjdk.org/jdk/pull/27155/files/16c150df..00929922 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27155&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27155&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27155/head:pull/27155 PR: https://git.openjdk.org/jdk/pull/27155 From iklam at openjdk.org Tue Sep 9 05:27:22 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 9 Sep 2025 05:27:22 GMT Subject: RFR: 8367142: Simplify java mirror handling in JNI methods Message-ID: The purpose of this PR is to simplify JNI code and also to avoid unnecessary `InstanceKlass::cast()` calls. This PR is intended to be a strict clean-up that preserves existing behaviors. The following helper functions are added to simplify boilerplate code in JNI methods. static Klass* java_lang_Class::as_Klass(jobject java_class); static InstanceKlass* java_lang_Class::as_InstanceKlass(oop java_class); static InstanceKlass* java_lang_Class::as_InstanceKlass(jobject java_class); Klass* get_klass_considering_redefinition(jclass cls, JavaThread *thread); InstanceKlass* get_instance_klass_considering_redefinition(jclass cls, JavaThread *thread); Notes: [1] Before this PR, we have both patterns: java_lang_Class::as_Klass(JNIHandles::resolve(cls)); java_lang_Class::as_Klass(JNIHandles::resolve_non_null(cls)); If `cls` is null, we would get an assert in both cases (`as_Klass()` requires a non-null input). Therefore, I am using `resolve_non_null()` in the `jobject` versions of `as_Klass()`. [2] I refactored `JvmtiThreadState::class_to_verify_considering_redefinition()` so that the caller of this funcation can avoid using `InstanceKlass::cast()`. This is possible because we ONLY store `InstanceKlass*` in `JvmtiThreadState::set_class_being_redefined()` I also removed a few cases of unnecessary `InstanceKlass::cast()`. ------------- Commit messages: - more fixes - tmp: Clean up java mirror handling in JNI methods Changes: https://git.openjdk.org/jdk/pull/27158/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27158&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367142 Stats: 278 lines in 19 files changed: 46 ins; 65 del; 167 mod Patch: https://git.openjdk.org/jdk/pull/27158.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27158/head:pull/27158 PR: https://git.openjdk.org/jdk/pull/27158 From epeter at openjdk.org Tue Sep 9 05:49:21 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 9 Sep 2025 05:49:21 GMT Subject: RFR: 8363858: [perf] OptimizeFill may use wide set of intrinsics [v3] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 21:09:51 GMT, Vladimir Ivanov wrote: >> Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: >> >> 8363858: [perf] OptimizeFill may use wide set of intrinsics > > Perf data for the Xeon 6740E looks as: > > Xeon 6740E | size | jdk_def | jdk_OptFill | p/def > -- | -- | -- | -- | -- > ArraysFill.testByteFill | 16 | 152113.563 | 173028.75 | 1.14 > ArraysFill.testByteFill | 31 | 125889.446 | 212458.124 | 1.69 > ArraysFill.testByteFill | 250 | 57942.562 | 148391.738 | 2.56 > ArraysFill.testByteFill | 266 | 44883.928 | 156986.22 | 3.50 > ArraysFill.testByteFill | 511 | 61848.425 | 130192.732 | 2.11 > ArraysFill.testByteFill | 2047 | 32242.521 | 39893.863 | 1.24 > ArraysFill.testByteFill | 2048 | 31918.795 | 40665.974 | 1.27 > ArraysFill.testByteFill | 8195 | 10685.801 | 10126.615 | 0.95 > ArraysFill.testIntFill | 16 | 145059.116 | 318660.232 | 2.20 > ArraysFill.testIntFill | 31 | 131312.049 | 227632.469 | 1.73 > ArraysFill.testIntFill | 250 | 73997.421 | 81060.479 | 1.10 > ArraysFill.testIntFill | 266 | 68072.273 | 77967.322 | 1.15 > ArraysFill.testIntFill | 511 | 39691.774 | 45220.274 | 1.14 > ArraysFill.testIntFill | 2047 | 11499.726 | 11295.527 | 0.98 > ArraysFill.testIntFill | 2048 | 11240.285 | 11419.196 | 1.02 > ArraysFill.testIntFill | 8195 | 2758.273 | 1310.374 | 0.48 > ArraysFill.testLongFill | 16 | 212459.292 | 212458.565 | 1.00 > ArraysFill.testLongFill | 31 | 131924.591 | 137124.526 | 1.04 > ArraysFill.testLongFill | 250 | 43105.961 | 43131.914 | 1.00 > ArraysFill.testLongFill | 266 | 42149.578 | 42154.248 | 1.00 > ArraysFill.testLongFill | 511 | 23358.361 | 23358.681 | 1.00 > ArraysFill.testLongFill | 2047 | 6120.952 | 6121.333 | 1.00 > ArraysFill.testLongFill | 2048 | 5781.826 | 5788.489 | 1.00 > ArraysFill.testLongFill | 8195 | 615.994 | 616.218 | 1.00 > ArraysFill.testShortFill | 16 | 152050.701 | 353826.527 | 2.33 > ArraysFill.testShortFill | 31 | 136798.898 | 212330.48 | 1.55 > ArraysFill.testShortFill | 250 | 58773.76 | 99592.044 | 1.69 > ArraysFill.testShortFill | 266 | 91052.769 | 93735.404 | 1.03 > ArraysFill.testShortFill | 511 | 65312.819 | 77820.206 | 1.19 > ArraysFill.testShortFill | 2047 | 21704.419 | 20440.256 | 0.94 > ArraysFill.testShortFill | 2048 | 21657.535 | 21625.922 | 1.00 > ArraysFill.testShortFill | 8195 | 5920.221 | 5872.366 | 0.99 > > I.e. most of test cases reports better score with intrinsic code. > Reported possible 2x drop (for example, ArraysFill.testIntFill, size=8195) relates to store_split metric and should be fixed by PR 26747. @IvaVladimir Thanks for the numbers and explanations! In that case, it seems that [JDK-8365290](https://bugs.openjdk.org/browse/JDK-8365290) is a regression of [JDK-8363858](https://bugs.openjdk.org/browse/JDK-8363858), and should be linked as such. I made some changes to reflect that. If you disagree, please let me know :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26974#issuecomment-3268961045 From epeter at openjdk.org Tue Sep 9 06:00:13 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 9 Sep 2025 06:00:13 GMT Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays [v4] In-Reply-To: References: Message-ID: On Sat, 30 Aug 2025 16:04:00 GMT, Vladimir Ivanov wrote: >> On the SRF platform for runs with intrinsic scores for the ArrayFill test reports ~2x drop for several sizes due to a lot of the 'MEM_UOPS_RETIRED.SPLIT_STORES' events. The 'good' case for the ArraysFill.testCharFill with size=8195 reports numbers like >> MEM_UOPS_RETIRED.SPLIT_LOADS | 22.6711 >> MEM_UOPS_RETIRED.SPLIT_STORES | 4.0859 >> while for 'bad' case these metrics are >> MEM_UOPS_RETIRED.SPLIT_LOADS | 69.1785 >> MEM_UOPS_RETIRED.SPLIT_STORES | 259200.3659 >> >> With alignment on the cache size no score drops due to split_stores but small reduction may be reported due to extra >> SRF 6740E | Size | orig | pathed | pO/orig >> -- | -- | -- | -- | -- >> ArraysFill.testByteFill | 16 | 152031.2 | 157001.2 | 1.03 >> ArraysFill.testByteFill | 31 | 125795.9 | 177399.2 | 1.41 >> ArraysFill.testByteFill | 250 | 57961.69 | 120981.9 | 2.09 >> ArraysFill.testByteFill | 266 | 44900.15 | 147893.8 | 3.29 >> ArraysFill.testByteFill | 511 | 61908.17 | 129830.1 | 2.10 >> ArraysFill.testByteFill | 2047 | 32255.51 | 41986.6 | 1.30 >> ArraysFill.testByteFill | 2048 | 31928.97 | 42154.3 | 1.32 >> ArraysFill.testByteFill | 8195 | 10690.15 | 11036.3 | 1.03 >> ArraysFill.testIntFill | 16 | 145030.7 | 318796.9 | 2.20 >> ArraysFill.testIntFill | 31 | 134138.4 | 212487 | 1.58 >> ArraysFill.testIntFill | 250 | 74179.23 | 79522.66 | 1.07 >> ArraysFill.testIntFill | 266 | 68112.72 | 60116.49 | 0.88 >> ArraysFill.testIntFill | 511 | 39693.28 | 36225.09 | 0.91 >> ArraysFill.testIntFill | 2047 | 11504.14 | 10616.91 | 0.92 >> ArraysFill.testIntFill | 2048 | 11244.71 | 10969.14 | 0.98 >> ArraysFill.testIntFill | 8195 | 2751.289 | 2692.216 | 0.98 >> ArraysFill.testLongFill | 16 | 212532.5 | 212526 | 1.00 >> ArraysFill.testLongFill | 31 | 137432.4 | 137283.3 | 1.00 >> ArraysFill.testLongFill | 250 | 43185 | 43159.78 | 1.00 >> ArraysFill.testLongFill | 266 | 42172.22 | 42170.5 | 1.00 >> ArraysFill.testLongFill | 511 | 23370.15 | 23370.86 | 1.00 >> ArraysFill.testLongFill | 2047 | 6123.008 | 6122.73 | 1.00 >> ArraysFill.testLongFill | 2048 | 5793.722 | 5792.855 | 1.00 >> ArraysFill.testLongFill | 8195 | 616.552 | 616.585 | 1.00 >> ArraysFill.testShortFill | 16 | 152088.6 | 265646.1 | 1.75 >> ArraysFill.testShortFill | 31 | 137369.8 | 185596.4 | 1.35 >> ArraysFill.testShortFill | 250 | 58872.03 | 99621.15 | 1.69 >> ArraysFill.testShortFill | 266 | 91085.31 | 93746.62 | 1.03 >> ArraysFill.testShortFill | 511 | 65331.96 | 78003.83 | 1.19 >> ArraysFill.testShortFill | 2047 | 21716.32 | 21216.81 | 0.98 >> ArraysFill.testShortFill... > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays If I understood our conversation [here](https://github.com/openjdk/jdk/pull/26974#issuecomment-3268030499) right, then this is a regression fix especially for `ArraysFill.testIntFill 8195`. There, you got a `0.48` regression. Now here you report `0.98`. I was a little confused about what is the base-line in your current patch. Can you make it more explicit what `orig` refers to? Is it the "original state" before #26974, or the master state before this issue here #26747? Also, your PR comment abruptly stops mid sentence: > but small reduction may be reported due to extra Can you please fix that? It seems that maybe the benchmark is not super reliable. It may be beneficial to run extra forks of the benchmark, to ensure you get many executions and a more stable measurement. It is quite possible that some of the +-10% regressions are due to alignment for example. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26747#issuecomment-3268986227 From dholmes at openjdk.org Tue Sep 9 06:01:13 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 9 Sep 2025 06:01:13 GMT Subject: RFR: 8367142: Simplify java mirror handling in JNI methods In-Reply-To: References: Message-ID: <30w65N-VMzjkn9Tpy6cXrKz2F-gyoGSyCMpzLc2H8HI=.82760ff5-84b2-4adb-897e-ee8f94be6dad@github.com> On Tue, 9 Sep 2025 05:21:10 GMT, Ioi Lam wrote: > The purpose of this PR is to simplify JNI code and also to avoid unnecessary `InstanceKlass::cast()` calls. > > This PR is intended to be a strict clean-up that preserves existing behaviors. > > The following helper functions are added to simplify boilerplate code in JNI methods. > > > static Klass* java_lang_Class::as_Klass(jobject java_class); > static InstanceKlass* java_lang_Class::as_InstanceKlass(oop java_class); > static InstanceKlass* java_lang_Class::as_InstanceKlass(jobject java_class); > > Klass* get_klass_considering_redefinition(jclass cls, JavaThread *thread); > InstanceKlass* get_instance_klass_considering_redefinition(jclass cls, JavaThread *thread); > > > Notes: > > [1] Before this PR, we have both patterns: > > > java_lang_Class::as_Klass(JNIHandles::resolve(cls)); > java_lang_Class::as_Klass(JNIHandles::resolve_non_null(cls)); > > > If `cls` is null, we would get an assert in both cases (`as_Klass()` requires a non-null input). Therefore, I am using `resolve_non_null()` in the `jobject` versions of `as_Klass()`. > > [2] I refactored `JvmtiThreadState::class_to_verify_considering_redefinition()` so that the caller of this funcation can avoid using `InstanceKlass::cast()`. This is possible because we ONLY store `InstanceKlass*` in `JvmtiThreadState::set_class_being_redefined()` > > I also removed a few cases of unnecessary `InstanceKlass::cast()`. Sorry but I think this PR is trying to do too many things at once. It is pushing JNI resolving inside internal JVM methods, which I think is a bad thing - we resolve JNI references at the boundary to get the oop that the VM wants to work with. Internal APIs should be oblivious to jobject and friends IMO. Also there may be times that the JNI/JVM method needs get the oop itself before extracting the klass. You are converting klass to instanceKlass where it has to be instanceKlass e.g. with redefinition. This is a good thing, but it is a very distinct thing that deserves its own cleanup (as per previous changes in that area). You are defining a helper `java_lang_Class::as_InstanceKlass` to internalize the cast - this is fine but again a simple cleanup that would be better standalone IMO. It is also not clear that JVM/JNI API's are properly checking that the incoming jobject is in fact a class of the right kind (ie not an array class object). ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27158#pullrequestreview-3199393023 From epeter at openjdk.org Tue Sep 9 06:07:12 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 9 Sep 2025 06:07:12 GMT Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays [v4] In-Reply-To: References: Message-ID: On Sat, 30 Aug 2025 16:04:00 GMT, Vladimir Ivanov wrote: >> On the SRF platform for runs with intrinsic scores for the ArrayFill test reports ~2x drop for several sizes due to a lot of the 'MEM_UOPS_RETIRED.SPLIT_STORES' events. The 'good' case for the ArraysFill.testCharFill with size=8195 reports numbers like >> MEM_UOPS_RETIRED.SPLIT_LOADS | 22.6711 >> MEM_UOPS_RETIRED.SPLIT_STORES | 4.0859 >> while for 'bad' case these metrics are >> MEM_UOPS_RETIRED.SPLIT_LOADS | 69.1785 >> MEM_UOPS_RETIRED.SPLIT_STORES | 259200.3659 >> >> With alignment on the cache size no score drops due to split_stores but small reduction may be reported due to extra >> SRF 6740E | Size | orig | pathed | pO/orig >> -- | -- | -- | -- | -- >> ArraysFill.testByteFill | 16 | 152031.2 | 157001.2 | 1.03 >> ArraysFill.testByteFill | 31 | 125795.9 | 177399.2 | 1.41 >> ArraysFill.testByteFill | 250 | 57961.69 | 120981.9 | 2.09 >> ArraysFill.testByteFill | 266 | 44900.15 | 147893.8 | 3.29 >> ArraysFill.testByteFill | 511 | 61908.17 | 129830.1 | 2.10 >> ArraysFill.testByteFill | 2047 | 32255.51 | 41986.6 | 1.30 >> ArraysFill.testByteFill | 2048 | 31928.97 | 42154.3 | 1.32 >> ArraysFill.testByteFill | 8195 | 10690.15 | 11036.3 | 1.03 >> ArraysFill.testIntFill | 16 | 145030.7 | 318796.9 | 2.20 >> ArraysFill.testIntFill | 31 | 134138.4 | 212487 | 1.58 >> ArraysFill.testIntFill | 250 | 74179.23 | 79522.66 | 1.07 >> ArraysFill.testIntFill | 266 | 68112.72 | 60116.49 | 0.88 >> ArraysFill.testIntFill | 511 | 39693.28 | 36225.09 | 0.91 >> ArraysFill.testIntFill | 2047 | 11504.14 | 10616.91 | 0.92 >> ArraysFill.testIntFill | 2048 | 11244.71 | 10969.14 | 0.98 >> ArraysFill.testIntFill | 8195 | 2751.289 | 2692.216 | 0.98 >> ArraysFill.testLongFill | 16 | 212532.5 | 212526 | 1.00 >> ArraysFill.testLongFill | 31 | 137432.4 | 137283.3 | 1.00 >> ArraysFill.testLongFill | 250 | 43185 | 43159.78 | 1.00 >> ArraysFill.testLongFill | 266 | 42172.22 | 42170.5 | 1.00 >> ArraysFill.testLongFill | 511 | 23370.15 | 23370.86 | 1.00 >> ArraysFill.testLongFill | 2047 | 6123.008 | 6122.73 | 1.00 >> ArraysFill.testLongFill | 2048 | 5793.722 | 5792.855 | 1.00 >> ArraysFill.testLongFill | 8195 | 616.552 | 616.585 | 1.00 >> ArraysFill.testShortFill | 16 | 152088.6 | 265646.1 | 1.75 >> ArraysFill.testShortFill | 31 | 137369.8 | 185596.4 | 1.35 >> ArraysFill.testShortFill | 250 | 58872.03 | 99621.15 | 1.69 >> ArraysFill.testShortFill | 266 | 91085.31 | 93746.62 | 1.03 >> ArraysFill.testShortFill | 511 | 65331.96 | 78003.83 | 1.19 >> ArraysFill.testShortFill | 2047 | 21716.32 | 21216.81 | 0.98 >> ArraysFill.testShortFill... > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5921: > 5919: if (EnableX86ECoreOpts) { > 5920: // align 'big' arrays to 64 bytes (cache line size) to minimize split_stores > 5921: cmpptr(count, 256< 5928: movl(Address(to, 0), value); > 5929: addptr(to, 4); > 5930: subptr(count, 1< References: <0oRVVWoEhKWyjeC8d-fNSqpNoh4w90srEPWM-tjALqc=.3cbfde7b-6e07-42ab-9e30-64431f680437@github.com> Message-ID: On Mon, 8 Sep 2025 12:15:31 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > > some extensions depends on another one, for example, zvbb depends on rvv. > That means if rvv is disabled or not supported by the CPU, UseZvbb should return false, and zvbb should not appear in cpu string. > But the currently, the cpu string contains zvbb even if rvv is disabled, which is not right. > This needs to be fixed. > > Thanks > > before fix, output for `-XX-UseRVV -Xlog:cpu*=debug` > > [0.064s][info ][os,cpu] CPU: total 32 (initial active 32) qemu rv64 rvi rvm rva rvf rvd rvc rvv zicbom zicboz zicbop zba zbb zbs zbkb zcb zfa zfh zfhmin zicsr zifencei zic64b ztso zacas zvbb zvbc zvfh zicond > > > after fix, output for `-XX-UseRVV -Xlog:cpu*=debug` > > [0.065s][info ][os,cpu] CPU: total 32 (initial active 32) qemu rv64 rvi rvm rva rvf rvd rvc zicbom zicboz zicbop zba zbb zbs zbkb zcb zfa zfh zfhmin zicsr zifencei zic64b ztso zacas zicond LGTM! Thanks for fixing this! ------------- Marked as reviewed by fyang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27142#pullrequestreview-3199554769 From iklam at openjdk.org Tue Sep 9 06:32:14 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 9 Sep 2025 06:32:14 GMT Subject: RFR: 8367142: Simplify java mirror handling in JNI methods In-Reply-To: <30w65N-VMzjkn9Tpy6cXrKz2F-gyoGSyCMpzLc2H8HI=.82760ff5-84b2-4adb-897e-ee8f94be6dad@github.com> References: <30w65N-VMzjkn9Tpy6cXrKz2F-gyoGSyCMpzLc2H8HI=.82760ff5-84b2-4adb-897e-ee8f94be6dad@github.com> Message-ID: On Tue, 9 Sep 2025 05:58:32 GMT, David Holmes wrote: > Sorry but I think this PR is trying to do too many things at once. > > It is pushing JNI resolving inside internal JVM methods, which I think is a bad thing - we resolve JNI references at the boundary to get the oop that the VM wants to work with. Internal APIs should be oblivious to jobject and friends IMO. Also there may be times that the JNI/JVM method needs get the oop itself before extracting the klass. There are 92 header files that have the word `jobject` in them. There are 71 cpp/hpp files with the word `JNIHandles::resolve` in them. So I am not sure if we really have that separation anymore. There are 54 cases where we call `as_Klass(JNIHandles::resolve_non_null(x))`, so I think it would be nice to have a way to write less code. > You are converting klass to instanceKlass where it has to be instanceKlass e.g. with redefinition. This is a good thing, but it is a very distinct thing that deserves its own cleanup (as per previous changes in that area). I can move the considering_redefinition changes in a follow-up PR. > You are defining a helper `java_lang_Class::as_InstanceKlass` to internalize the cast - this is fine but again a simple cleanup that would be better standalone IMO. > > It is also not clear that JVM/JNI API's are properly checking that the incoming jobject is in fact a class of the right kind (ie not an array class object). I am just converting InstanceKlass* ik = InstanceKlass::cast(as_Klass(mirror)); to InstanceKlass* ik = as_InstanceKlass(mirror); The code already assumes that it has an InstanceKlass, and I am not changing that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27158#issuecomment-3269072414 From dholmes at openjdk.org Tue Sep 9 06:32:18 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 9 Sep 2025 06:32:18 GMT Subject: RFR: 8277444: Data race between JvmtiClassFileReconstituter::copy_bytecodes and class linking [v6] In-Reply-To: <1bLI04thwsSz_j_sbfMJnHjEjQR1Soo6vupBws-vDcU=.6e6b27ee-8830-41c6-9034-652c60bc3179@github.com> References: <1bLI04thwsSz_j_sbfMJnHjEjQR1Soo6vupBws-vDcU=.6e6b27ee-8830-41c6-9034-652c60bc3179@github.com> Message-ID: On Fri, 5 Sep 2025 19:15:33 GMT, Evgeny Astigeevich wrote: >> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. >> >> This PR adds linking a class before the `copy_bytecodes` method is called. >> The PR also adds a regression test. >> >> Tested fastdebug and release builds: Linux x86_64 and arm64 >> - The reproducer from JDK-8277444 passed. >> - The regression test passed. >> - Tier1 - tier3 passed. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments Nothing further from me. If there are issues with the test we will address them as needed. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26863#pullrequestreview-3199565160 From aboldtch at openjdk.org Tue Sep 9 06:35:52 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 9 Sep 2025 06:35:52 GMT Subject: RFR: 8367150: Add a header line to improve VMErrorCallback printing Message-ID: <7kHwLsN1YaX-vrNMs2hojrCnVuTyzxfDEI3323huo_c=.05650b47-8055-4825-8322-f7547e198251@github.com> Currently all the registered VMErrorCallback are printed one after another in the error report with only a newline separating them. It makes harder to both quickly find the section, or differentiate the where one starts and another begins in the case of multiple callbacks. I propose we add a simple header line before each callback. VMErrorCallback 1: [ First callback's print ] VMErrorCallback 2: [ Second callback's print ] ------------- Commit messages: - 8367150: Add a header line to improve VMErrorCallback printing Changes: https://git.openjdk.org/jdk/pull/27160/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27160&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367150 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27160.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27160/head:pull/27160 PR: https://git.openjdk.org/jdk/pull/27160 From aboldtch at openjdk.org Tue Sep 9 06:38:10 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 9 Sep 2025 06:38:10 GMT Subject: RFR: 8367149: Add ergonomic construction for creating ad-hoc VMErrorCallback Message-ID: Add a class OnVMError which uses the VMErrorCallback mechanism which is an ergonomic construction for creating ad-hoc VMErrorCallback which automatically calls the provided invocable f if a VM crash occurs within its lifetime. Can be used to instrument a build for more detailed contextual information gathering. Especially useful when hunting down intermittent bugs, or issues only reproducible in environments where access to a debugger is not readily available. Example use: ```C++ { // Note the lambda is invoked after an error occurs within this thread, // and during on_error's lifetime. If state prior to the crash is required, // capture a copy of it first. auto important_value = get_the_value(); OnVMError on_error([&](outputStream* st) { // Dump the important bits. st->print("Prior value: "); important_value.print_on(st); st->print("During crash: ") get_the_value().print_on(st); // Dump whole the whole state. this->print_on(st); }); // Sometimes doing a thing will crash the VM. do_a_thing(); } C++17 class template argument deduction finally makes these sort of constructions ergonomic to use without the need for auto and helper construction methods. ------------- Commit messages: - 8367149: Add ergonomic construction for creating ad-hoc VMErrorCallback Changes: https://git.openjdk.org/jdk/pull/27159/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27159&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367149 Stats: 37 lines in 1 file changed: 37 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27159.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27159/head:pull/27159 PR: https://git.openjdk.org/jdk/pull/27159 From epeter at openjdk.org Tue Sep 9 06:46:13 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 9 Sep 2025 06:46:13 GMT Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays [v4] In-Reply-To: References: Message-ID: On Sat, 30 Aug 2025 16:04:00 GMT, Vladimir Ivanov wrote: >> On the SRF platform for runs with intrinsic scores for the ArrayFill test reports ~2x drop for several sizes due to a lot of the 'MEM_UOPS_RETIRED.SPLIT_STORES' events. The 'good' case for the ArraysFill.testCharFill with size=8195 reports numbers like >> MEM_UOPS_RETIRED.SPLIT_LOADS | 22.6711 >> MEM_UOPS_RETIRED.SPLIT_STORES | 4.0859 >> while for 'bad' case these metrics are >> MEM_UOPS_RETIRED.SPLIT_LOADS | 69.1785 >> MEM_UOPS_RETIRED.SPLIT_STORES | 259200.3659 >> >> With alignment on the cache size no score drops due to split_stores but small reduction may be reported due to extra >> SRF 6740E | Size | orig | pathed | pO/orig >> -- | -- | -- | -- | -- >> ArraysFill.testByteFill | 16 | 152031.2 | 157001.2 | 1.03 >> ArraysFill.testByteFill | 31 | 125795.9 | 177399.2 | 1.41 >> ArraysFill.testByteFill | 250 | 57961.69 | 120981.9 | 2.09 >> ArraysFill.testByteFill | 266 | 44900.15 | 147893.8 | 3.29 >> ArraysFill.testByteFill | 511 | 61908.17 | 129830.1 | 2.10 >> ArraysFill.testByteFill | 2047 | 32255.51 | 41986.6 | 1.30 >> ArraysFill.testByteFill | 2048 | 31928.97 | 42154.3 | 1.32 >> ArraysFill.testByteFill | 8195 | 10690.15 | 11036.3 | 1.03 >> ArraysFill.testIntFill | 16 | 145030.7 | 318796.9 | 2.20 >> ArraysFill.testIntFill | 31 | 134138.4 | 212487 | 1.58 >> ArraysFill.testIntFill | 250 | 74179.23 | 79522.66 | 1.07 >> ArraysFill.testIntFill | 266 | 68112.72 | 60116.49 | 0.88 >> ArraysFill.testIntFill | 511 | 39693.28 | 36225.09 | 0.91 >> ArraysFill.testIntFill | 2047 | 11504.14 | 10616.91 | 0.92 >> ArraysFill.testIntFill | 2048 | 11244.71 | 10969.14 | 0.98 >> ArraysFill.testIntFill | 8195 | 2751.289 | 2692.216 | 0.98 >> ArraysFill.testLongFill | 16 | 212532.5 | 212526 | 1.00 >> ArraysFill.testLongFill | 31 | 137432.4 | 137283.3 | 1.00 >> ArraysFill.testLongFill | 250 | 43185 | 43159.78 | 1.00 >> ArraysFill.testLongFill | 266 | 42172.22 | 42170.5 | 1.00 >> ArraysFill.testLongFill | 511 | 23370.15 | 23370.86 | 1.00 >> ArraysFill.testLongFill | 2047 | 6123.008 | 6122.73 | 1.00 >> ArraysFill.testLongFill | 2048 | 5793.722 | 5792.855 | 1.00 >> ArraysFill.testLongFill | 8195 | 616.552 | 616.585 | 1.00 >> ArraysFill.testShortFill | 16 | 152088.6 | 265646.1 | 1.75 >> ArraysFill.testShortFill | 31 | 137369.8 | 185596.4 | 1.35 >> ArraysFill.testShortFill | 250 | 58872.03 | 99621.15 | 1.69 >> ArraysFill.testShortFill | 266 | 91085.31 | 93746.62 | 1.03 >> ArraysFill.testShortFill | 511 | 65331.96 | 78003.83 | 1.19 >> ArraysFill.testShortFill | 2047 | 21716.32 | 21216.81 | 0.98 >> ArraysFill.testShortFill... > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays I got a bit inspired and did some digging. TLDR: we need better benchmarks, I think. The current ones don't control for alignment, and are quite unstable with only 3 forks. ---------------------- I'm wondering if the benchmark `./test/micro/org/openjdk/bench/java/util/ArraysFill.java` is really very well suited to give us good information about unaligned arrays. Because all it does it just allocate arrays, but we have no information about the alignment at all. If I'm not wrong, I see that we only have 3 forks, so we do this: - 3x do: - allocate: maybe aligned, maybe misaligned - warmup - benchmark This only really gives us 3 alignment configurations. And in all cases, we start filling from the beginning of the array. That gives us really noisy information regarding alignment. What I'd love to see is some benchmark where we can manually adjust alignment, and iterate over all possible alignments/misalignments. We could do that by using `Arrays.fill(array, start, end, value)`, and filling only a part of the array, starting at different starting offsets. Honestly, I'm a little shocked to find no JMH benchmark using `Arrays.fill(array, start, end, value)`, they all seem to use `Arrays.fill(array, value)`. We should also compare to SuperWord performance, to see how well the intrinsic is doing in comparison. Personally, my hope would be that eventually auto-vectorization gets as close as possible to the intrinsics, I'm not sure how close we are exactly yet. Here a related tracking issue: [JDK-8299808](https://bugs.openjdk.org/browse/JDK-8299808) Let me see if there are any other related benchmarks we could use here: `./test/micro/org/openjdk/bench/vm/compiler/ArrayFill.java` It probably tests for automatic detection of fill loops, which should also use the fill intrinsic. But we also have no real control of alignment there. I did some previous work on alignment, though for auto-vectorization: - `test/micro/org/openjdk/bench/vm/compiler/VectorAutoAlignment.java` - Memory segment with native memory. Not directly relevant here, but the method of going over all sorts of `offset_load` and `offset_store` is helpful for array fill and copy. I'm now looking at copy intrinsics too (`System.arraycopy`). Important to note: we just allowed many more copy patterns to auto-vectorize with [JDK-8324751](https://bugs.openjdk.org/browse/JDK-8324751) (Aliasing runtime check), so we have more things to compare to here. - `./test/micro/org/openjdk/bench/java/lang/ArrayCopy.java` - only does full array copy, so no control for alignment - `./test/micro/org/openjdk/bench/java/lang/ArrayCopyAligned.java` - I think it claims to always work with an aligned base. But that's probably not true any more with Lilliput that changes the alignment of the first element for some element types. - These do a similar thing, so no idea if they really hold their promise, i.e. if they really measure what they promise. They also only measure one alignment configuration, so that's a weakness. - `./test/micro/org/openjdk/bench/java/lang/ArrayCopyUnalignedBoth.java` - `./test/micro/org/openjdk/bench/java/lang/ArrayCopyUnalignedDst.java` - `./test/micro/org/openjdk/bench/java/lang/ArrayCopyUnalignedSrc.java` - `test/micro/org/openjdk/bench/java/lang/ArrayFiddle.java` - claims that intrinsics are a lot better than hand written loops. We may want to look into that info again since [JDK-8324751](https://bugs.openjdk.org/browse/JDK-8324751) (Aliasing runtime check). Then there are also the `MemorySegment` fill and copy benchmarks. But maybe we leave those for another day. ----------------------- I'm filing an RFE to create better `fill` and `copy` benchmarks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26747#issuecomment-3269114783 From fyang at openjdk.org Tue Sep 9 06:59:13 2025 From: fyang at openjdk.org (Fei Yang) Date: Tue, 9 Sep 2025 06:59:13 GMT Subject: RFR: 8367137: RISC-V: Detect Zicboz block size via hwprobe [v2] In-Reply-To: References: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> Message-ID: <2tl4xqekzI29HxkmCB34tCvZAi5CraxcvSz8NLpyEQk=.788b5c41-0330-4764-a811-92c7b23e2ab0@github.com> On Tue, 9 Sep 2025 04:29:41 GMT, Dingli Zhang wrote: >> Hi, >> Can you help to review this patch? Thanks! >> >> We can extends RISC-V hwprobe support to include `RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`. >> The probed value is recorded in VM_Version::zicboz_block_size and then used to set the global CacheLineSize. >> This ensures correct usage of the Zicboz extension, as block zeroing instructions operate on cache-line granularity. >> >> FYI: https://docs.kernel.org/arch/riscv/hwprobe.html > > Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: > > fix typo src/hotspot/cpu/riscv/vm_version_riscv.cpp line 184: > 182: } > 183: > 184: if (UseZicboz) { I don't think it's safe to turn on `UseBlockZeroing` without knowing the actual cache block size. So we might want to add check for that here. Maybe change this if condition into something like: if (UseZicboz && (UseZic64b || zicboz_block_size.enabled())) { src/hotspot/cpu/riscv/vm_version_riscv.cpp line 187: > 185: if (zicboz_block_size.enabled()) { > 186: assert(UseZic64b ? zicboz_block_size.value() == 64 : true, "Zicboz block size should be 64 when UseZic64b is true"); > 187: assert(is_power_of_2(zicboz_block_size.value()), "CacheLineSize must be a power of 2"); Can we merge the two assertions into one? Like: `assert(UseZic64b ? zicboz_block_size.value() == 64 : is_power_of_2(zicboz_block_size.value()), "Sanity");` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27155#discussion_r2332218887 PR Review Comment: https://git.openjdk.org/jdk/pull/27155#discussion_r2332213815 From dholmes at openjdk.org Tue Sep 9 07:00:16 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 9 Sep 2025 07:00:16 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v7] In-Reply-To: References: Message-ID: <5XlD7SZVcGUSw8qhHTp_aKb2-2IIS9CwEryCrE1GQ1E=.c9de4cab-9e40-423a-9822-851f89835de1@github.com> On Mon, 8 Sep 2025 18:31:51 GMT, Leonid Mesnik wrote: >> This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result. >> The related fix here: >> https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56 >> Hope fix became clarere now. >> >> There 2 problems in this post_meth_exit: >> 1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode. >> 2) The method `get_jvmti_thread_state` should be called when thread is in vm state only. >> >> The fix adds `post_method_exit_transition` to have single exit point with oop restoration. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > interopnly_state should be saved Thanks that looks clearer to me now. One pre-existing typo. src/hotspot/share/prims/jvmtiExport.cpp line 1870: > 1868: JRT_BLOCK_END > 1869: if (interp_only) { > 1870: // The JRT_BLOCK_END can safepoint in ThreadInVMfromJava desctructor. Now it is safe to allow Suggestion: // The JRT_BLOCK_END can safepoint in ThreadInVMfromJava destructor. Now it is safe to allow ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27112#pullrequestreview-3199680287 PR Review Comment: https://git.openjdk.org/jdk/pull/27112#discussion_r2332223595 From dholmes at openjdk.org Tue Sep 9 07:06:20 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 9 Sep 2025 07:06:20 GMT Subject: RFR: 8366057: HotSpot Style Guide should permit trailing return types [v2] In-Reply-To: <3BK_mYdIzPe4LIz8ntBVa5Hhph4kHIP1TxtGoAslqYw=.ba18dfad-8046-4e30-b0d4-e3a1ccc4cefe@github.com> References: <3BK_mYdIzPe4LIz8ntBVa5Hhph4kHIP1TxtGoAslqYw=.ba18dfad-8046-4e30-b0d4-e3a1ccc4cefe@github.com> Message-ID: On Tue, 9 Sep 2025 03:00:32 GMT, Kim Barrett wrote: >> Please review this change to the HotSpot Style Guide to permit trailing return >> types for functions. >> >> This is a modification of the Style Guide, so rough consensus among the >> HotSpot Group members is required to make this change. Only Group members >> should vote for approval (via the github PR), though reasoned objections or >> comments from anyone will be considered. A decision on this proposal will not >> be made before Monday 8-September-2025 at 12h00 UTC. >> >> Since we're piggybacking on github PRs here, please use the PR review process >> to approve (click on Review Changes > Approve), rather than sending a "vote: >> yes" email reply that would be normal for a CFV. > > Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' into trailing-return-type > - permit trailing return types Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26923#pullrequestreview-3199704552 From duke at openjdk.org Tue Sep 9 07:22:33 2025 From: duke at openjdk.org (duke) Date: Tue, 9 Sep 2025 07:22:33 GMT Subject: Withdrawn: 8356027: Print enhanced compilation timings In-Reply-To: References: Message-ID: On Thu, 1 May 2025 12:35:38 GMT, Aleksey Shipilev wrote: > In Leyden, we have the extended compilation timings printouts with -XX:+PrintCompilation / UL, that are very useful to study compiler dynamics. These timings include: > 1. Time spent before queuing: shows the compilation queue bottlenecks > 2. Time spent in the queue: shows delays caused by queue bottlenecks and compiler load > 3. Time spent actually compiling: shows the per-method compilation costs > > We should consider the same kind of printout for mainline. This would also require us to print the compilation task _after_ the compilation, not only before it. This improvement would also obviate any need for `PrintCompilation2` flag, [JDK-8356028](https://bugs.openjdk.org/browse/JDK-8356028). > > The difference from the output format we ship in Leyden: > 1. This output prints before/after the compilation to maintain old behavior partially. The "before" printout is now prepended with `started` to clearly mark it as such. > 2. The output is raw number in microseconds. In Leyden repo, we have these prepended with characters, like `C0.1`, but that prepending makes it a bit inconvenient with scripts. This PR also does microseconds, instead of fractional milliseconds. This should be enough to capture the wide range of durations. > > See the sample `-XX:+PrintCompilation` output in the comments. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `compiler` > - [x] Linux x86_64 server fastdebug, `all` This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/24984 From dholmes at openjdk.org Tue Sep 9 07:33:39 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 9 Sep 2025 07:33:39 GMT Subject: RFR: 8367051: Build failure with clang on linux and AIX after switch to C++17 In-Reply-To: References: Message-ID: <3-GcAnpnrmdtFYqAQX4en_CFTmha14uizxwmxtMeNbQ=.080b984b-399a-4f47-affe-600a9ec52f18@github.com> On Tue, 9 Sep 2025 01:00:30 GMT, Kim Barrett wrote: > 8367051: Build failure with clang on linux and AIX after switch to C++17 > > Please review this change to work around build failures with clang on some > platforms after the switch to C++17. > > C++17 made the exception specification part of a function's type. Some > standard libraries declare C library functions as noexcept. If HotSpot has a > forbidding declaration for such a function (without a noexcept spec) before > including the standard library header, clang reports this as an error (not > just a warning that could be suppressed, a hard error). If the standard > library header containing the noexpect declaration is first, then clang > does *not* complain about the following forbidding declaration that doesn't > have an exception spec. gcc permits either order. > > So the workaround consists of ensuring all the standard library headers for > forbidden functions are included before the forbidding declarations. > > Exploration of other approaches to follow, but for now we need to fix the > build errors. > > Testing: mach5 tier1 > GHA saniticy checks in progress Seems reasonable as a workaround. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27154#pullrequestreview-3199802380 From jsjolen at openjdk.org Tue Sep 9 07:34:55 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 9 Sep 2025 07:34:55 GMT Subject: Integrated: 8366363: MemBaseline accesses VMT without using lock In-Reply-To: References: Message-ID: On Fri, 29 Aug 2025 12:13:57 GMT, Johan Sj?len wrote: > Hi, > > The `MemBaseline` used to access the VMT instance directly without a lock. We fix that, and we switch from using a `LinkedList` to a copied `RegionsTree` instead. This pull request has now been integrated. Changeset: ecfba66d Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/ecfba66d3d7c1fef755f0824f342189d0f231007 Stats: 229 lines in 12 files changed: 164 ins; 44 del; 21 mod 8366363: MemBaseline accesses VMT without using lock Co-authored-by: Casper Norrbin Reviewed-by: azafari, cnorrbin ------------- PR: https://git.openjdk.org/jdk/pull/27003 From dholmes at openjdk.org Tue Sep 9 07:41:02 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 9 Sep 2025 07:41:02 GMT Subject: RFR: 8367142: Simplify java mirror handling in JNI methods In-Reply-To: References: <30w65N-VMzjkn9Tpy6cXrKz2F-gyoGSyCMpzLc2H8HI=.82760ff5-84b2-4adb-897e-ee8f94be6dad@github.com> Message-ID: On Tue, 9 Sep 2025 06:29:51 GMT, Ioi Lam wrote: > So I am not sure if we really have that separation anymore. I think it is more that there are many bits of code that actually form the "boundary" (prims, services, some runtime, jvmci, interpreter-related). But I guess it is hard to argue this makes it markedly worse. > The code already assumes that it has an InstanceKlass, and I am not changing that. Okay. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27158#issuecomment-3269331429 From ayang at openjdk.org Tue Sep 9 07:49:24 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 9 Sep 2025 07:49:24 GMT Subject: RFR: 8367051: Build failure with clang on linux and AIX after switch to C++17 In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 01:00:30 GMT, Kim Barrett wrote: > 8367051: Build failure with clang on linux and AIX after switch to C++17 > > Please review this change to work around build failures with clang on some > platforms after the switch to C++17. > > C++17 made the exception specification part of a function's type. Some > standard libraries declare C library functions as noexcept. If HotSpot has a > forbidding declaration for such a function (without a noexcept spec) before > including the standard library header, clang reports this as an error (not > just a warning that could be suppressed, a hard error). If the standard > library header containing the noexpect declaration is first, then clang > does *not* complain about the following forbidding declaration that doesn't > have an exception spec. gcc permits either order. > > So the workaround consists of ensuring all the standard library headers for > forbidden functions are included before the forbidding declarations. > > Exploration of other approaches to follow, but for now we need to fix the > build errors. > > Testing: mach5 tier1 > GHA saniticy checks in progress Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27154#pullrequestreview-3199864198 From epeter at openjdk.org Tue Sep 9 07:49:38 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 9 Sep 2025 07:49:38 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 09:09:49 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * sort includes test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestIRMatching.java line 1489: > 1487: @Test > 1488: @IR(failOn = IRNode.ALLOC) > 1489: @IR(counts = {IRNode.COUNTED_LOOP, ">1"}) // not fail Can you explain what led to the difference? Can you also set an upper bound? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2332346985 From rcastanedalo at openjdk.org Tue Sep 9 07:55:59 2025 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Tue, 9 Sep 2025 07:55:59 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: <_sI2w99vG5BN7dhrgs-LabreQQG3r-7RaP6ejUls1_w=.ae0c7c90-87db-4136-b96f-d8b29ce8bdcf@github.com> On Mon, 8 Sep 2025 09:09:49 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * sort includes The compiler changes (including the x64 and aarch64 platform-specific code) still look good, thanks for this work! ------------- Marked as reviewed by rcastanedalo (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23739#pullrequestreview-3199884440 From aph at openjdk.org Tue Sep 9 07:58:11 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 9 Sep 2025 07:58:11 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v5] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 21:26:22 GMT, Dean Long wrote: >> This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value. Further, it takes a fast-path that uses the previous direct store when at a safepoint. Combined, these changes should get us back to almost where we were before in terms of overhead. If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > one unconditional release should be enough That looks like a nice improvement. Thanks. ------------- Marked as reviewed by aph (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26399#pullrequestreview-3199895559 From aph at openjdk.org Tue Sep 9 08:15:54 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 9 Sep 2025 08:15:54 GMT Subject: RFR: 8365606: Container code should not be using jlong/julong In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 17:24:58 GMT, Severin Gehwolf wrote: > Please review this refactoring to the container code in Hotspot to no longer use `jlong` and `julong`. Instead this patch proposes to move to `size_t` and `ssize_t` types. In a similar manner as was done with the `os::xxx` APIs in [JDK-8357086](https://bugs.openjdk.org/browse/JDK-8357086). With this patch the use of `OSCONTAINER_ERROR` (`-2`) is largely gone. It's not terribly useful to have to warrant the many special cases throughout the code. > > In this patch failure handling is being done by returning a boolean for success/failure of reading a value from the interface files. The notion of "not supported" is being folded into `-1` (unlimited for limit values, not supported for usage values). Note that the code already treated `-1` and `-2` similarly. The few cases where `-2` was actually used was in `VM.info` output or `hserr` files. Where `-2` was being treated as "not supported". However, file-reading errors would also fall into the `-2` bucket making the "not supported" case not 100% distinguishable either. The simplification here proposes to do away with `-2` (other than in traces) and fold it into the `-1` (unlimited) bucket as that's how the code has been handling those values (even prior to this patch). > > Testing: > - [x] GHA (tier1) > - [x] cgroup gtests and hotspot container tests on cgroup v1 and cgroup v2 (no regressions noted). > > Thoughts? On some 32-bit systems this PR moves memory sizes from 64 bits, where they can't overflow, to 32 bits, where they can. While I've looked at this carefully, I can't exclude the possibility that overflow may occur. While we could pick through every change line by line, wouldn't it be safer simply to stay with 64-bit sizes on all systems? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27125#issuecomment-3269452347 From jsjolen at openjdk.org Tue Sep 9 08:18:24 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 9 Sep 2025 08:18:24 GMT Subject: Integrated: 8367231: [BACKOUT] JDK-8366363: MemBaseline accesses VMT without using lock Message-ID: This reverts commit ecfba66d3d7c1fef755f0824f342189d0f231007. I broke the build because I didn't merge with master before integrating, let this be a lesson to me! ------------- Commit messages: - Revert "8366363: MemBaseline accesses VMT without using lock" Changes: https://git.openjdk.org/jdk/pull/27164/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27164&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367231 Stats: 228 lines in 12 files changed: 43 ins; 163 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/27164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27164/head:pull/27164 PR: https://git.openjdk.org/jdk/pull/27164 From kbarrett at openjdk.org Tue Sep 9 08:18:25 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 9 Sep 2025 08:18:25 GMT Subject: Integrated: 8367231: [BACKOUT] JDK-8366363: MemBaseline accesses VMT without using lock In-Reply-To: References: Message-ID: <6_ENSNvXpbC6WPNkLCs-yltp0u57lfSzKruXrkEqTrA=.488aae70-d034-4471-8fa8-4629aaec4ff1@github.com> On Tue, 9 Sep 2025 08:07:52 GMT, Johan Sj?len wrote: > This reverts commit ecfba66d3d7c1fef755f0824f342189d0f231007. > > I broke the build because I didn't merge with master before integrating, let this be a lesson to me! Looks like a good backout. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27164#pullrequestreview-3199979587 From dholmes at openjdk.org Tue Sep 9 08:18:25 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 9 Sep 2025 08:18:25 GMT Subject: Integrated: 8367231: [BACKOUT] JDK-8366363: MemBaseline accesses VMT without using lock In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 08:07:52 GMT, Johan Sj?len wrote: > This reverts commit ecfba66d3d7c1fef755f0824f342189d0f231007. > > I broke the build because I didn't merge with master before integrating, let this be a lesson to me! Backout looks accurate. That said keep a watch on src/hotspot/share/nmt/regionsTree.cpp as this may have undone a fix from the "sort include files for NMT" PR ( you don't include a .hpp and .inline.hpp) ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27164#pullrequestreview-3199992021 From jsjolen at openjdk.org Tue Sep 9 08:18:26 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 9 Sep 2025 08:18:26 GMT Subject: Integrated: 8367231: [BACKOUT] JDK-8366363: MemBaseline accesses VMT without using lock In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 08:07:52 GMT, Johan Sj?len wrote: > This reverts commit ecfba66d3d7c1fef755f0824f342189d0f231007. > > I broke the build because I didn't merge with master before integrating, let this be a lesson to me! This pull request has now been integrated. Changeset: e16c5100 Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/e16c510071f84bdbd57a8b2d3810c484c314ccf9 Stats: 228 lines in 12 files changed: 43 ins; 163 del; 22 mod 8367231: [BACKOUT] JDK-8366363: MemBaseline accesses VMT without using lock Reviewed-by: kbarrett, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/27164 From mbaesken at openjdk.org Tue Sep 9 08:23:09 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 9 Sep 2025 08:23:09 GMT Subject: RFR: 8367051: Build failure with clang on linux and AIX after switch to C++17 In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 01:00:30 GMT, Kim Barrett wrote: > 8367051: Build failure with clang on linux and AIX after switch to C++17 > > Please review this change to work around build failures with clang on some > platforms after the switch to C++17. > > C++17 made the exception specification part of a function's type. Some > standard libraries declare C library functions as noexcept. If HotSpot has a > forbidding declaration for such a function (without a noexcept spec) before > including the standard library header, clang reports this as an error (not > just a warning that could be suppressed, a hard error). If the standard > library header containing the noexpect declaration is first, then clang > does *not* complain about the following forbidding declaration that doesn't > have an exception spec. gcc permits either order. > > So the workaround consists of ensuring all the standard library headers for > forbidden functions are included before the forbidding declarations. > > Exploration of other approaches to follow, but for now we need to fix the > build errors. > > Testing: mach5 tier1 > GHA saniticy checks in progress Thanks for the fix ! ------------- Marked as reviewed by mbaesken (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27154#pullrequestreview-3200026482 From dzhang at openjdk.org Tue Sep 9 08:26:43 2025 From: dzhang at openjdk.org (Dingli Zhang) Date: Tue, 9 Sep 2025 08:26:43 GMT Subject: RFR: 8367137: RISC-V: Detect Zicboz block size via hwprobe [v3] In-Reply-To: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> References: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> Message-ID: <23CI4KDVcMCZIYAGe0vznUlPgYHSyTR9W7zDF3UZGbo=.aeeaf1d3-c62c-4d39-af11-032cba41b82f@github.com> > Hi, > Can you help to review this patch? Thanks! > > We can extends RISC-V hwprobe support to include `RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`. > The probed value is recorded in VM_Version::zicboz_block_size and then used to set the global CacheLineSize. > This ensures correct usage of the Zicboz extension, as block zeroing instructions operate on cache-line granularity. > > FYI: https://docs.kernel.org/arch/riscv/hwprobe.html Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: fix some assert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27155/files - new: https://git.openjdk.org/jdk/pull/27155/files/00929922..bcb0453b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27155&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27155&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27155/head:pull/27155 PR: https://git.openjdk.org/jdk/pull/27155 From dzhang at openjdk.org Tue Sep 9 08:26:46 2025 From: dzhang at openjdk.org (Dingli Zhang) Date: Tue, 9 Sep 2025 08:26:46 GMT Subject: RFR: 8367137: RISC-V: Detect Zicboz block size via hwprobe [v2] In-Reply-To: <2tl4xqekzI29HxkmCB34tCvZAi5CraxcvSz8NLpyEQk=.788b5c41-0330-4764-a811-92c7b23e2ab0@github.com> References: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> <2tl4xqekzI29HxkmCB34tCvZAi5CraxcvSz8NLpyEQk=.788b5c41-0330-4764-a811-92c7b23e2ab0@github.com> Message-ID: On Tue, 9 Sep 2025 06:55:03 GMT, Fei Yang wrote: >> Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: >> >> fix typo > > src/hotspot/cpu/riscv/vm_version_riscv.cpp line 184: > >> 182: } >> 183: >> 184: if (UseZicboz) { > > I don't think it's safe to turn on `UseBlockZeroing` without knowing the actual cache block size. > So we might want to add check for that here. Maybe change this if condition into something like: > > if (UseZicboz && (UseZic64b || zicboz_block_size.enabled())) { Fixed. > src/hotspot/cpu/riscv/vm_version_riscv.cpp line 187: > >> 185: if (zicboz_block_size.enabled()) { >> 186: assert(UseZic64b ? zicboz_block_size.value() == 64 : true, "Zicboz block size should be 64 when UseZic64b is true"); >> 187: assert(is_power_of_2(zicboz_block_size.value()), "CacheLineSize must be a power of 2"); > > Can we merge the two assertions into one? Like: > `assert(UseZic64b ? zicboz_block_size.value() == 64 : is_power_of_2(zicboz_block_size.value()), "Sanity");` Thanks! Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27155#discussion_r2332476372 PR Review Comment: https://git.openjdk.org/jdk/pull/27155#discussion_r2332476152 From ysuenaga at openjdk.org Tue Sep 9 08:29:09 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 9 Sep 2025 08:29:09 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU [v2] In-Reply-To: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> Message-ID: > On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`. > > > $ jfr print --events jdk.CPUInformation test.jfr > jdk.CPUInformation { > startTime = 10:49:27.692 (2025-09-04) > cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64" > description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel > Family: (0x6), Model: (0xb5), Stepping: 0x0 > Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650 > Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff > Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800 > Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instruc tion, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC" > sockets = 1 > cores = 7 > hwThreads = 14 > } > > > Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`. > > We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least. > > This patch sets `0` to `cores` and "Hybrid Architecture" ... Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Use jmc_undefined_long if runs on hybrid CPU ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27080/files - new: https://git.openjdk.org/jdk/pull/27080/files/7ac3885f..2ebbde5f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27080&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27080&range=00-01 Stats: 16 lines in 4 files changed: 7 ins; 4 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27080.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27080/head:pull/27080 PR: https://git.openjdk.org/jdk/pull/27080 From ysuenaga at openjdk.org Tue Sep 9 08:29:10 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 9 Sep 2025 08:29:10 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU In-Reply-To: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> Message-ID: On Thu, 4 Sep 2025 02:15:01 GMT, Yasumasa Suenaga wrote: > On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`. > > > $ jfr print --events jdk.CPUInformation test.jfr > jdk.CPUInformation { > startTime = 10:49:27.692 (2025-09-04) > cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64" > description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel > Family: (0x6), Model: (0xb5), Stepping: 0x0 > Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650 > Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff > Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800 > Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instruc tion, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC" > sockets = 1 > cores = 7 > hwThreads = 14 > } > > > Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`. > > We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least. > > This patch sets `0` to `cores` and "Hybrid Architecture" ... I updated this patch to set `jmc_undefined_long` if runs on hybrid CPU. It passed jdk_jfr test on my laptop. @egahlin Can you review? You can see `jdk.CPUInformation` event generated on hybrid CPU as following: jdk.CPUInformation { startTime = 16:15:19.185 (2025-09-09) cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64" description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel Family: (0x6), Model: (0xb5), Stepping: 0x0 Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650 Features: ebx: 0x10800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800 Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instructi on, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC, Hybrid Architecture" sockets = 1 cores = N/A hwThreads = 14 } ------------- PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3269483510 From mdoerr at openjdk.org Tue Sep 9 09:08:40 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 9 Sep 2025 09:08:40 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v7] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 18:31:51 GMT, Leonid Mesnik wrote: >> This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result. >> The related fix here: >> https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56 >> Hope fix became clarere now. >> >> There 2 problems in this post_meth_exit: >> 1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode. >> 2) The method `get_jvmti_thread_state` should be called when thread is in vm state only. >> >> The fix adds `post_method_exit_transition` to have single exit point with oop restoration. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > interopnly_state should be saved Marked as reviewed by mdoerr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27112#pullrequestreview-3200261168 From epeter at openjdk.org Tue Sep 9 09:14:05 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 9 Sep 2025 09:14:05 GMT Subject: RFR: 8366984: Remove delay slot support In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 14:24:50 GMT, Daniel Jeli?ski wrote: > SPARC was the only supported architecture that uses a delay slot. The SPARC port was removed in JDK 15, and the code is effectively dead. Let's remove it. > > The changes are no-op on all architectures that do not use delay slots. I still tested tier 1-5 on mach5, no related failures. Looks reasonable, thanks for doing the cleanup! I have 2 minor questions though. (please also run additional stress testing, see slack) src/hotspot/cpu/arm/arm.ad line 3383: > 3381: BR : R; > 3382: %} > 3383: Where was this used? Or is it an unrelated cleanup? src/hotspot/share/adlc/adlparse.cpp line 1394: > 1392: parse_err(SYNERR, "Using obsolete token, branch_has_delay_slot"); > 1393: break; > 1394: } I'm curious: why do you add that special warning? It would fail later anyway, right? Are we expecting anyone to parse things produced by different versions? ------------- Marked as reviewed by epeter (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27119#pullrequestreview-3200246647 PR Review Comment: https://git.openjdk.org/jdk/pull/27119#discussion_r2332626258 PR Review Comment: https://git.openjdk.org/jdk/pull/27119#discussion_r2332620923 From djelinski at openjdk.org Tue Sep 9 09:18:21 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 9 Sep 2025 09:18:21 GMT Subject: RFR: 8366984: Remove delay slot support In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 09:03:18 GMT, Emanuel Peter wrote: >> SPARC was the only supported architecture that uses a delay slot. The SPARC port was removed in JDK 15, and the code is effectively dead. Let's remove it. >> >> The changes are no-op on all architectures that do not use delay slots. I still tested tier 1-5 on mach5, no related failures. > > src/hotspot/share/adlc/adlparse.cpp line 1394: > >> 1392: parse_err(SYNERR, "Using obsolete token, branch_has_delay_slot"); >> 1393: break; >> 1394: } > > I'm curious: why do you add that special warning? It would fail later anyway, right? Are we expecting anyone to parse things produced by different versions? I took my inspiration from earlier work on adlc (see 6e35bcbf038cec0210c38428a8e1c233e102911a or 3f9c8a39201644952c6d07b97695a5a7ef918622), but I don't mind removing these warnings and the related code block entirely. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27119#discussion_r2332667364 From djelinski at openjdk.org Tue Sep 9 09:26:04 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 9 Sep 2025 09:26:04 GMT Subject: RFR: 8366984: Remove delay slot support In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 09:04:48 GMT, Emanuel Peter wrote: >> SPARC was the only supported architecture that uses a delay slot. The SPARC port was removed in JDK 15, and the code is effectively dead. Let's remove it. >> >> The changes are no-op on all architectures that do not use delay slots. I still tested tier 1-5 on mach5, no related failures. > > src/hotspot/cpu/arm/arm.ad line 3383: > >> 3381: BR : R; >> 3382: %} >> 3383: > > Where was this used? Or is it an unrelated cleanup? Removing the comment alone didn't feel quite right, so I removed the following block as well. The block appears to be unused. It was copy-pasted from [SPARC](https://github.com/openjdk/jdk/blob/8153779ad32d1e8ddd37ced826c76c7aafc61894/hotspot/src/cpu/sparc/vm/sparc.ad#L4984), where it was also unused. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27119#discussion_r2332702728 From mli at openjdk.org Tue Sep 9 09:29:24 2025 From: mli at openjdk.org (Hamlin Li) Date: Tue, 9 Sep 2025 09:29:24 GMT Subject: RFR: 8367098: RISC-V: sync CPU features with related JVM flags for dependant ones In-Reply-To: References: <0oRVVWoEhKWyjeC8d-fNSqpNoh4w90srEPWM-tjALqc=.3cbfde7b-6e07-42ab-9e30-64431f680437@github.com> Message-ID: On Tue, 9 Sep 2025 06:27:09 GMT, Fei Yang wrote: > LGTM! Thanks for fixing this! Thank you for reviewing! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27142#issuecomment-3269732314 From krk at openjdk.org Tue Sep 9 09:30:27 2025 From: krk at openjdk.org (Kerem Kat) Date: Tue, 9 Sep 2025 09:30:27 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands [v2] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 09:40:58 GMT, Kevin Walls wrote: >> It is not ideal but the original >> >> if (!c.onJavaThread()) return; >> JavaThread* p = JavaThread::active(); >> >> is also duplicating the internals both inside `isOnJavaThread()` and in the callers. And what is mainly tripping us up is that `active()` is allowed to return null, but this fix wants to detect a null current thread as a sign of being detached. So we end up calling `Thread::current` multiple times. All of the debug functions that use `active()` are currently broken anyway because they never check it for null (and I'm not even sure they truly expect to work on a delegated JavaThread??). So I see this fix as having two parts: >> 1. The `onThread` check takes care of being attached >> 2. The `active() == nullptr` check just fixes the current broken code. >> >> But I still dislike the internal duplication between `onThread` and `active`. > > Have used these occasionally and am surprised to realize psf and others show frames from the VM operation's caller thread. > > > The duplication around the active() checks is odd. If we are adding: > > bool onThread() > If no current thread, print warning and return false. Callers will return immediately. > > Could we add e.g.: > > bool hasActiveThread() > If no current thread, print warning and return false. Callers will return immediately. > If no active thread, print warning and return false. Callers will return immediately. > Callers can go on to use JavaThread* p = JavaThread::active(); without checking (as we currently do). > (We are presumably in a debugger session, speed is not the priority, repeating some checks or fetching of active() is not tragic, but this file has less duplication.) Thank you for the description for `hasActiveThread`. Is it much different than the `onJavaThread` in the first revision? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27033#discussion_r2332718975 From mli at openjdk.org Tue Sep 9 09:32:41 2025 From: mli at openjdk.org (Hamlin Li) Date: Tue, 9 Sep 2025 09:32:41 GMT Subject: Integrated: 8367098: RISC-V: sync CPU features with related JVM flags for dependant ones In-Reply-To: <0oRVVWoEhKWyjeC8d-fNSqpNoh4w90srEPWM-tjALqc=.3cbfde7b-6e07-42ab-9e30-64431f680437@github.com> References: <0oRVVWoEhKWyjeC8d-fNSqpNoh4w90srEPWM-tjALqc=.3cbfde7b-6e07-42ab-9e30-64431f680437@github.com> Message-ID: On Mon, 8 Sep 2025 12:15:31 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > > some extensions depends on another one, for example, zvbb depends on rvv. > That means if rvv is disabled or not supported by the CPU, UseZvbb should return false, and zvbb should not appear in cpu string. > But the currently, the cpu string contains zvbb even if rvv is disabled, which is not right. > This needs to be fixed. > > Thanks > > before fix, output for `-XX-UseRVV -Xlog:cpu*=debug` > > [0.064s][info ][os,cpu] CPU: total 32 (initial active 32) qemu rv64 rvi rvm rva rvf rvd rvc rvv zicbom zicboz zicbop zba zbb zbs zbkb zcb zfa zfh zfhmin zicsr zifencei zic64b ztso zacas zvbb zvbc zvfh zicond > > > after fix, output for `-XX-UseRVV -Xlog:cpu*=debug` > > [0.065s][info ][os,cpu] CPU: total 32 (initial active 32) qemu rv64 rvi rvm rva rvf rvd rvc zicbom zicboz zicbop zba zbb zbs zbkb zcb zfa zfh zfhmin zicsr zifencei zic64b ztso zacas zicond This pull request has now been integrated. Changeset: f51e442b Author: Hamlin Li URL: https://git.openjdk.org/jdk/commit/f51e442b0e26d0e9ebb6ec0da9584ba4f548322c Stats: 21 lines in 1 file changed: 2 ins; 0 del; 19 mod 8367098: RISC-V: sync CPU features with related JVM flags for dependant ones Reviewed-by: fyang ------------- PR: https://git.openjdk.org/jdk/pull/27142 From krk at openjdk.org Tue Sep 9 09:47:12 2025 From: krk at openjdk.org (Kerem Kat) Date: Tue, 9 Sep 2025 09:47:12 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands [v2] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 09:54:38 GMT, Kevin Walls wrote: >> Kerem Kat has updated the pull request incrementally with two additional commits since the last revision: >> >> - add include for global placement new >> - remove onJavaThread and check JavaThread::active null where needed > > src/hotspot/share/utilities/debug.cpp line 308: > >> 306: public: >> 307: Command(const char* str) : _has_rm(false) { >> 308: if (level++ == 0) { > > "level" can recognise concurrent usage, but doesn't protect against it? The commands still proceed to do their thing, so it doesn't seem right make us skip printing "Executing..." if level was not exactly zero? > > (Adding the flush() if there is concurrent might be a good thing, it may help if there is output that could be confused, if that is even possible to achieve...) My original understanding for the level variable was to handle nested command calls, not concurrent ones. For instance, if a command like `find` were to internally call `findm`, printing two "Executing..." messages would be more confusing, as the user executed a single command from gdb. On the other hand, is it possible to call these functions from gdb concurrently? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27033#discussion_r2332794218 From sgehwolf at openjdk.org Tue Sep 9 09:51:59 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 9 Sep 2025 09:51:59 GMT Subject: RFR: 8365606: Container code should not be using jlong/julong In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 08:13:05 GMT, Andrew Haley wrote: > On some 32-bit systems this PR moves memory sizes from 64 bits, where they can't overflow, to 32 bits, where they can. While I've looked at this carefully, I can't exclude the possibility that overflow may occur. > > While we could pick through every change line by line, wouldn't it be safer simply to stay with 64-bit sizes on all systems? I agree. It's a valid concern. But this PR is basically an extension to [JDK-8357086](https://bugs.openjdk.org/browse/JDK-8357086). That one is already in JDK 26. It's also worth noting that 32-bit support is [on its way out](https://mail.openjdk.org/pipermail/jdk-dev/2025-April/009909.html). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27125#issuecomment-3269849969 From kevinw at openjdk.org Tue Sep 9 10:06:09 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 9 Sep 2025 10:06:09 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands [v2] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 09:44:42 GMT, Kerem Kat wrote: >> src/hotspot/share/utilities/debug.cpp line 308: >> >>> 306: public: >>> 307: Command(const char* str) : _has_rm(false) { >>> 308: if (level++ == 0) { >> >> "level" can recognise concurrent usage, but doesn't protect against it? The commands still proceed to do their thing, so it doesn't seem right make us skip printing "Executing..." if level was not exactly zero? >> >> (Adding the flush() if there is concurrent might be a good thing, it may help if there is output that could be confused, if that is even possible to achieve...) > > My original understanding for the level variable was to handle nested command calls, not concurrent ones. > > For instance, if a command like `find` were to internally call `findm`, printing two "Executing..." messages would be more confusing, as the user executed a single command from gdb. > > On the other hand, is it possible to call these functions from gdb concurrently? Right, I don't think anybody expects concurrent calls from gdb. 8-) I didn't see any nested commands either. I thought it worth mentioning as it is a behaviour change. I wonder if a command can fail, fault within debugger control, and not decrement the static level? That might be a reason not to change this, but don't worry too much about proving that, happy either way.. As mentioned earlier the user by this point should be able to cope with whatever happens. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27033#discussion_r2332868837 From kevinw at openjdk.org Tue Sep 9 10:21:51 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 9 Sep 2025 10:21:51 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands [v2] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 09:27:22 GMT, Kerem Kat wrote: >> Have used these occasionally and am surprised to realize psf and others show frames from the VM operation's caller thread. >> >> >> The duplication around the active() checks is odd. If we are adding: >> >> bool onThread() >> If no current thread, print warning and return false. Callers will return immediately. >> >> Could we add e.g.: >> >> bool hasActiveThread() >> If no current thread, print warning and return false. Callers will return immediately. >> If no active thread, print warning and return false. Callers will return immediately. >> Callers can go on to use JavaThread* p = JavaThread::active(); without checking (as we currently do). >> (We are presumably in a debugger session, speed is not the priority, repeating some checks or fetching of active() is not tragic, but this file has less duplication.) > > Thank you for the description for `hasActiveThread`. Is it much different than the `onJavaThread` in the first revision? OK, I see now that I'm suggesting more like what you had originally, that you go back to what David disliked. 8-) I would have gone for having this check in the helper method (even if it means multiple Thread::current calls) over duplication inserted into three command implementations. Seems like a way to fix their assumptions also. Just want to check with David if he might agree that keeping the individual commands simpler is worth permitting the additional helper method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27033#discussion_r2332935293 From egahlin at openjdk.org Tue Sep 9 10:34:09 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 9 Sep 2025 10:34:09 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU [v2] In-Reply-To: References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> Message-ID: On Tue, 9 Sep 2025 08:29:09 GMT, Yasumasa Suenaga wrote: >> On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`. >> >> >> $ jfr print --events jdk.CPUInformation test.jfr >> jdk.CPUInformation { >> startTime = 10:49:27.692 (2025-09-04) >> cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64" >> description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel >> Family: (0x6), Model: (0xb5), Stepping: 0x0 >> Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650 >> Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff >> Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800 >> Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instru ction, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC" >> sockets = 1 >> cores = 7 >> hwThreads = 14 >> } >> >> >> Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`. >> >> We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least. >> >> This patc... > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Use jmc_undefined_long if runs on hybrid CPU It should not be a problem to change to type long. Values are stored as compressed integers, but you might want to check the event in JMC just to be sure. Problem might be the API, e.g. int cores = event.getInt("cores") or Integer cores = event.getValue("cores"). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3270024207 From epeter at openjdk.org Tue Sep 9 10:59:48 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 9 Sep 2025 10:59:48 GMT Subject: RFR: 8366984: Remove delay slot support In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 14:24:50 GMT, Daniel Jeli?ski wrote: > SPARC was the only supported architecture that uses a delay slot. The SPARC port was removed in JDK 15, and the code is effectively dead. Let's remove it. > > The changes are no-op on all architectures that do not use delay slots. I still tested tier 1-5 on mach5, no related failures. Thanks for the answers! You'll of course have to merge the dependency, and get a second review :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27119#issuecomment-3270142011 From epeter at openjdk.org Tue Sep 9 10:59:51 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 9 Sep 2025 10:59:51 GMT Subject: RFR: 8366984: Remove delay slot support In-Reply-To: References: Message-ID: <6dsuRmIveoGusgv0MnsHqIv87ZjbwXy3z9DoBvbUwVc=.9437cbe1-e0ad-43ce-bbda-86403a5971fc@github.com> On Tue, 9 Sep 2025 09:23:46 GMT, Daniel Jeli?ski wrote: >> src/hotspot/cpu/arm/arm.ad line 3383: >> >>> 3381: BR : R; >>> 3382: %} >>> 3383: >> >> Where was this used? Or is it an unrelated cleanup? > > Removing the comment alone didn't feel quite right, so I removed the following block as well. The block appears to be unused. It was copy-pasted from [SPARC](https://github.com/openjdk/jdk/blob/8153779ad32d1e8ddd37ced826c76c7aafc61894/hotspot/src/cpu/sparc/vm/sparc.ad#L4984), where it was also unused. Thanks for the explanation :) >> src/hotspot/share/adlc/adlparse.cpp line 1394: >> >>> 1392: parse_err(SYNERR, "Using obsolete token, branch_has_delay_slot"); >>> 1393: break; >>> 1394: } >> >> I'm curious: why do you add that special warning? It would fail later anyway, right? Are we expecting anyone to parse things produced by different versions? > > I took my inspiration from earlier work on adlc (see 6e35bcbf038cec0210c38428a8e1c233e102911a or 3f9c8a39201644952c6d07b97695a5a7ef918622), but I don't mind removing these warnings and the related code block entirely. Sounds good, just keep the "obsolete" error :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27119#discussion_r2333063403 PR Review Comment: https://git.openjdk.org/jdk/pull/27119#discussion_r2333062954 From ysuenaga at openjdk.org Tue Sep 9 11:04:34 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 9 Sep 2025 11:04:34 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU [v2] In-Reply-To: References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> Message-ID: On Tue, 9 Sep 2025 10:27:22 GMT, Erik Gahlin wrote: > you might want to check the event in JMC just to be sure. I checked the flight record, but JMC 9.1 showed raw min_jlong value. I think it is a problem on JMC. image > Problem might be the API, e.g. int cores = event.getInt("cores") or Integer cores = event.getValue("cores"). I hope the problem would be found by jdk_jfr tests - it passed on both GHA and my Linux box. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3270165692 From stefank at openjdk.org Tue Sep 9 11:20:11 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 9 Sep 2025 11:20:11 GMT Subject: RFR: 8366854: Extend jtreg failure handler with THP info [v2] In-Reply-To: References: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> Message-ID: <48KBVP1dUIm4u54Deyd86JjTvGWYgVFpVNcZpByQcxM=.43aac7fb-2918-4e66-ac00-b734c0a871b8@github.com> On Thu, 4 Sep 2025 07:49:56 GMT, Stefan Karlsson wrote: >> I propose that we also dump /proc/meminfo, /proc/vmstat, and /sys/kernel/mm/transparent_hugepage/{enabled, defrag} from the failure handler. >> >> This information has been helpful when investigating a failure where there was an unexpected lack of transparent huge pages. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Add shmem_enabled Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27086#issuecomment-3270221506 From stefank at openjdk.org Tue Sep 9 11:20:13 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 9 Sep 2025 11:20:13 GMT Subject: Integrated: 8366854: Extend jtreg failure handler with THP info In-Reply-To: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> References: <6kTyf-hvGeBqsboyZbdJlxPOr-G-5PtMi4tUr9_QGL8=.95f99eb6-47b4-489e-ba20-e77b919deec1@github.com> Message-ID: <7Nwy3L2GxuSImNvYy6bSE8aqD4miLiZF9HjeE47UpYk=.1851f7d8-1006-4f0d-8e40-bf9aa698e7f3@github.com> On Thu, 4 Sep 2025 07:03:01 GMT, Stefan Karlsson wrote: > I propose that we also dump /proc/meminfo, /proc/vmstat, and /sys/kernel/mm/transparent_hugepage/{enabled, defrag} from the failure handler. > > This information has been helpful when investigating a failure where there was an unexpected lack of transparent huge pages. This pull request has now been integrated. Changeset: a1ab12b7 Author: Stefan Karlsson URL: https://git.openjdk.org/jdk/commit/a1ab12b77266c7124a297e1b2e0a8608b8facb2a Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod 8366854: Extend jtreg failure handler with THP info Reviewed-by: ayang, shade, tschatzl, lmesnik, sjohanss ------------- PR: https://git.openjdk.org/jdk/pull/27086 From egahlin at openjdk.org Tue Sep 9 11:35:10 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 9 Sep 2025 11:35:10 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU [v2] In-Reply-To: References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> Message-ID: On Tue, 9 Sep 2025 11:01:32 GMT, Yasumasa Suenaga wrote: > I checked the flight record, but JMC 9.1 showed raw min_jlong value. I think it is a problem on JMC. Interesting, it has worked in the past. > I hope the problem would be found by jdk_jfr tests Try to add: + event.getInt("cores"); + Integer value = event.getValue("cores"); to TestCPUInformation.java. There's no need to check in the changes, but it would be good to know what happens if it is a long value. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3270271752 From stefank at openjdk.org Tue Sep 9 11:52:03 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 9 Sep 2025 11:52:03 GMT Subject: RFR: 8367014: Rename class Atomic to AtomicAccess In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 06:26:03 GMT, Kim Barrett wrote: > Please review this change that renames the all-static class `Atomic` to > `AtomicAccess`. The reason for this name change is to allow the introduction > of the new type `Atomic` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)). > > The PR has several commits, according to the specific category of change being > made. It may be easier to review the PR by studying these individual commits. > > Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose > to not rename the various "atomic_.*" and "atomic__.*" files. > > There are a number of comments containing the word "Atomic" that I didn't > change. They are generically about atomic operations, and will just as well > serve as referring to the future `Atomic`. > > Testing: mach5 tier1, GHA sanity tests. > This is one of those changes where successful builds indicate the change is good. I've checked through the patch and it looks good. I found one file that lacked alignment adjustments. > Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose > to not rename the various "atomic_." and "atomic__." files. Could you motivate why you chose to not do that? src/hotspot/os_cpu/bsd_x86/atomic_bsd_x86.hpp line 43: > 41: template<> > 42: template > 43: inline D AtomicAccess::PlatformAdd<4>::fetch_then_add(D volatile* dest, I add_value, This file has multiple alignment issues. ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27135#pullrequestreview-3200998425 PR Review Comment: https://git.openjdk.org/jdk/pull/27135#discussion_r2333148324 From stefank at openjdk.org Tue Sep 9 11:55:57 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 9 Sep 2025 11:55:57 GMT Subject: RFR: 8367150: Add a header line to improve VMErrorCallback printing In-Reply-To: <7kHwLsN1YaX-vrNMs2hojrCnVuTyzxfDEI3323huo_c=.05650b47-8055-4825-8322-f7547e198251@github.com> References: <7kHwLsN1YaX-vrNMs2hojrCnVuTyzxfDEI3323huo_c=.05650b47-8055-4825-8322-f7547e198251@github.com> Message-ID: On Tue, 9 Sep 2025 06:26:43 GMT, Axel Boldt-Christmas wrote: > Currently all the registered VMErrorCallback are printed one after another in the error report with only a newline separating them. It makes harder to both quickly find the section, or differentiate the where one starts and another begins in the case of multiple callbacks. I propose we add a simple header line before each callback. > > > VMErrorCallback 1: > [ First callback's print ] > VMErrorCallback 2: > [ Second callback's print ] Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27160#pullrequestreview-3201122460 From ysuenaga at openjdk.org Tue Sep 9 11:58:56 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 9 Sep 2025 11:58:56 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU [v2] In-Reply-To: References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> Message-ID: On Tue, 9 Sep 2025 11:32:20 GMT, Erik Gahlin wrote: >>> you might want to check the event in JMC just to be sure. >> >> I checked the flight record, but JMC 9.1 showed raw min_jlong value. I think it is a problem on JMC. >> >> image >> >> >>> Problem might be the API, e.g. int cores = event.getInt("cores") or Integer cores = event.getValue("cores"). >> >> I hope the problem would be found by jdk_jfr tests - it passed on both GHA and my Linux box. > >> I checked the flight record, but JMC 9.1 showed raw min_jlong value. I think it is a problem on JMC. > > Interesting, it has worked in the past. > >> I hope the problem would be found by jdk_jfr tests > > Try to add: > > + event.getInt("cores"); > + Integer value = event.getValue("cores"); > > to TestCPUInformation.java. There's no need to check in the changes, but it would be good to know what happens if it is a long value. @egahlin `event.getInt("cores")`: failed java.lang.IllegalArgumentException: Attempt to get field "cores" with illegal data type conversion int at jdk.jfr/jdk.jfr.consumer.RecordedObject.newIllegalArgumentException(RecordedObject.java:890) at jdk.jfr/jdk.jfr.consumer.RecordedObject.getInt(RecordedObject.java:553) at jdk.jfr.event.os.TestCPUInformation.main(TestCPUInformation.java:56) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1474) `Integer value = event.getValue("cores")`: failed java.lang.ClassCastException: class java.lang.Long cannot be cast to class java.lang.Integer (java.lang.Long and java.lang.Integer are in module java.base of loader 'bootstrap') at jdk.jfr.event.os.TestCPUInformation.main(TestCPUInformation.java:57) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1474) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3270354691 From jsjolen at openjdk.org Tue Sep 9 12:04:26 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 9 Sep 2025 12:04:26 GMT Subject: RFR: 8367249: [REDO] MemBaseline accesses VMT without using lock Message-ID: Hi, This is a REDO, as the previous attempt caused build failures when merged with latest master. The only difference is that the copy ctr for the RBTRee had been integrated with a different PR, but it never should have been. I deleted the copy ctr. Thanks. ------------- Commit messages: - Delete unneeded copy ctr - Merge remote-tracking branch 'openjdk/master' into cleanup-membaseline - Missed const-ness - Move into rbTree.inline.hpp file - Merge remote-tracking branch 'openjdk/master' into cleanup-membaseline - Rename to _vma_allocations - After a lot of casting - Yup - Some more ugly casts - Aha, _root is typed as an IntrusiveRBNode - ... and 10 more: https://git.openjdk.org/jdk/compare/06326176...9539fe96 Changes: https://git.openjdk.org/jdk/pull/27170/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27170&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367249 Stats: 235 lines in 12 files changed: 162 ins; 50 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/27170.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27170/head:pull/27170 PR: https://git.openjdk.org/jdk/pull/27170 From azafari at openjdk.org Tue Sep 9 12:04:26 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 9 Sep 2025 12:04:26 GMT Subject: RFR: 8367249: [REDO] MemBaseline accesses VMT without using lock In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 11:53:41 GMT, Johan Sj?len wrote: > Hi, > > This is a REDO, as the previous attempt caused build failures when merged with latest master. > The only difference is that the copy ctr for the RBTRee had been integrated with a different PR, but it never should have been. I deleted the copy ctr. > > Thanks. LGTM. Thanks! ------------- Marked as reviewed by azafari (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27170#pullrequestreview-3201147166 From cnorrbin at openjdk.org Tue Sep 9 12:04:27 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Tue, 9 Sep 2025 12:04:27 GMT Subject: RFR: 8367249: [REDO] MemBaseline accesses VMT without using lock In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 11:53:41 GMT, Johan Sj?len wrote: > Hi, > > This is a REDO, as the previous attempt caused build failures when merged with latest master. > The only difference is that the copy ctr for the RBTRee had been integrated with a different PR, but it never should have been. I deleted the copy ctr. > > Thanks. Still good! ------------- Marked as reviewed by cnorrbin (Committer). PR Review: https://git.openjdk.org/jdk/pull/27170#pullrequestreview-3201151569 From epeter at openjdk.org Tue Sep 9 12:06:21 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 9 Sep 2025 12:06:21 GMT Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays [v4] In-Reply-To: References: Message-ID: On Sat, 30 Aug 2025 16:04:00 GMT, Vladimir Ivanov wrote: >> On the SRF platform for runs with intrinsic scores for the ArrayFill test reports ~2x drop for several sizes due to a lot of the 'MEM_UOPS_RETIRED.SPLIT_STORES' events. The 'good' case for the ArraysFill.testCharFill with size=8195 reports numbers like >> MEM_UOPS_RETIRED.SPLIT_LOADS | 22.6711 >> MEM_UOPS_RETIRED.SPLIT_STORES | 4.0859 >> while for 'bad' case these metrics are >> MEM_UOPS_RETIRED.SPLIT_LOADS | 69.1785 >> MEM_UOPS_RETIRED.SPLIT_STORES | 259200.3659 >> >> With alignment on the cache size no score drops due to split_stores but small reduction may be reported due to extra >> SRF 6740E | Size | orig | pathed | pO/orig >> -- | -- | -- | -- | -- >> ArraysFill.testByteFill | 16 | 152031.2 | 157001.2 | 1.03 >> ArraysFill.testByteFill | 31 | 125795.9 | 177399.2 | 1.41 >> ArraysFill.testByteFill | 250 | 57961.69 | 120981.9 | 2.09 >> ArraysFill.testByteFill | 266 | 44900.15 | 147893.8 | 3.29 >> ArraysFill.testByteFill | 511 | 61908.17 | 129830.1 | 2.10 >> ArraysFill.testByteFill | 2047 | 32255.51 | 41986.6 | 1.30 >> ArraysFill.testByteFill | 2048 | 31928.97 | 42154.3 | 1.32 >> ArraysFill.testByteFill | 8195 | 10690.15 | 11036.3 | 1.03 >> ArraysFill.testIntFill | 16 | 145030.7 | 318796.9 | 2.20 >> ArraysFill.testIntFill | 31 | 134138.4 | 212487 | 1.58 >> ArraysFill.testIntFill | 250 | 74179.23 | 79522.66 | 1.07 >> ArraysFill.testIntFill | 266 | 68112.72 | 60116.49 | 0.88 >> ArraysFill.testIntFill | 511 | 39693.28 | 36225.09 | 0.91 >> ArraysFill.testIntFill | 2047 | 11504.14 | 10616.91 | 0.92 >> ArraysFill.testIntFill | 2048 | 11244.71 | 10969.14 | 0.98 >> ArraysFill.testIntFill | 8195 | 2751.289 | 2692.216 | 0.98 >> ArraysFill.testLongFill | 16 | 212532.5 | 212526 | 1.00 >> ArraysFill.testLongFill | 31 | 137432.4 | 137283.3 | 1.00 >> ArraysFill.testLongFill | 250 | 43185 | 43159.78 | 1.00 >> ArraysFill.testLongFill | 266 | 42172.22 | 42170.5 | 1.00 >> ArraysFill.testLongFill | 511 | 23370.15 | 23370.86 | 1.00 >> ArraysFill.testLongFill | 2047 | 6123.008 | 6122.73 | 1.00 >> ArraysFill.testLongFill | 2048 | 5793.722 | 5792.855 | 1.00 >> ArraysFill.testLongFill | 8195 | 616.552 | 616.585 | 1.00 >> ArraysFill.testShortFill | 16 | 152088.6 | 265646.1 | 1.75 >> ArraysFill.testShortFill | 31 | 137369.8 | 185596.4 | 1.35 >> ArraysFill.testShortFill | 250 | 58872.03 | 99621.15 | 1.69 >> ArraysFill.testShortFill | 266 | 91085.31 | 93746.62 | 1.03 >> ArraysFill.testShortFill | 511 | 65331.96 | 78003.83 | 1.19 >> ArraysFill.testShortFill | 2047 | 21716.32 | 21216.81 | 0.98 >> ArraysFill.testShortFill... > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays Here is my previous investigation on split-stores performance: https://github.com/openjdk/jdk/pull/25065 I could easily see regressions from 20-50% due to split stores / misalignment. So getting the benchmark right is very important to take the right decisions in automatic alignment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26747#issuecomment-3270389251 From rehn at openjdk.org Tue Sep 9 12:55:42 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 9 Sep 2025 12:55:42 GMT Subject: RFR: 8367137: RISC-V: Detect Zicboz block size via hwprobe [v3] In-Reply-To: <23CI4KDVcMCZIYAGe0vznUlPgYHSyTR9W7zDF3UZGbo=.aeeaf1d3-c62c-4d39-af11-032cba41b82f@github.com> References: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> <23CI4KDVcMCZIYAGe0vznUlPgYHSyTR9W7zDF3UZGbo=.aeeaf1d3-c62c-4d39-af11-032cba41b82f@github.com> Message-ID: <9zDt5wIqdDWHRlfmoIuH02l0-GusedD2z5GjmDZAcAg=.e975db12-3c7f-493b-94c8-855e7b1d70b4@github.com> On Tue, 9 Sep 2025 08:26:43 GMT, Dingli Zhang wrote: >> Hi, >> Can you help to review this patch? Thanks! >> >> We can extends RISC-V hwprobe support to include `RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`. >> The probed value is recorded in VM_Version::zicboz_block_size and then used to set the global CacheLineSize. >> This ensures correct usage of the Zicboz extension, as block zeroing instructions operate on cache-line granularity. >> >> FYI: https://docs.kernel.org/arch/riscv/hwprobe.html > > Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: > > fix some assert I looked at the kernel side, there is no gauarantee that ZICBOZ_BLOCK_SIZE and ZICBOM_BLOCK_SIZE are the same value. Also the kernel seems to have a bug, if it can't retrive those value it will return 0 as value for those. And your patch doesn't consider a user supplied cache line size, e.g. -XX:CacheLineSize=64 or -XX:+UseZic64b. You should only change the value if the user didn't change it. This becomes a bit messy, as e.g. UseRVA23U64 mandates zic64b which mandates 64b cache line. So if user says rva23 he is setting the cache line to 64b IMHO. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27155#issuecomment-3270608461 From mli at openjdk.org Tue Sep 9 12:59:35 2025 From: mli at openjdk.org (Hamlin Li) Date: Tue, 9 Sep 2025 12:59:35 GMT Subject: RFR: 8367253: RISC-V: refactor dependent cpu extensions Message-ID: Hi, Can you help to review this patch? Dependent extensions could be improved in several ways. Currently, the dependent cpu extensions are processed in 2 separate places: 1. update_flag() when calling VM_Version::setup_cpu_available_features() 2. at the end of VM_Version::common_initialize(). But we can do it in one single place, that is update_flag(). And, dependency relationship can only be expressed in (1:1) way, can not be expressed (1:N) way, but in fact some extensions can depend on several different other extensions, for example, zvfh depends on zvf and rvv. It's would be better to support this (1:N) relationship. Thanks! ------------- Commit messages: - remove obsolete extension dependency code - initial commit Changes: https://git.openjdk.org/jdk/pull/27171/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27171&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367253 Stats: 142 lines in 2 files changed: 52 ins; 30 del; 60 mod Patch: https://git.openjdk.org/jdk/pull/27171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27171/head:pull/27171 PR: https://git.openjdk.org/jdk/pull/27171 From mdoerr at openjdk.org Tue Sep 9 13:39:31 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 9 Sep 2025 13:39:31 GMT Subject: RFR: 8367051: Build failure with clang on linux and AIX after switch to C++17 In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 01:00:30 GMT, Kim Barrett wrote: > 8367051: Build failure with clang on linux and AIX after switch to C++17 > > Please review this change to work around build failures with clang on some > platforms after the switch to C++17. > > C++17 made the exception specification part of a function's type. Some > standard libraries declare C library functions as noexcept. If HotSpot has a > forbidding declaration for such a function (without a noexcept spec) before > including the standard library header, clang reports this as an error (not > just a warning that could be suppressed, a hard error). If the standard > library header containing the noexpect declaration is first, then clang > does *not* complain about the following forbidding declaration that doesn't > have an exception spec. gcc permits either order. > > So the workaround consists of ensuring all the standard library headers for > forbidden functions are included before the forbidding declarations. > > Exploration of other approaches to follow, but for now we need to fix the > build errors. > > Testing: mach5 tier1 > GHA saniticy checks in progress Marked as reviewed by mdoerr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27154#pullrequestreview-3201654079 From ysuenaga at openjdk.org Tue Sep 9 13:47:45 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 9 Sep 2025 13:47:45 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU [v3] In-Reply-To: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> Message-ID: > On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`. > > > $ jfr print --events jdk.CPUInformation test.jfr > jdk.CPUInformation { > startTime = 10:49:27.692 (2025-09-04) > cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64" > description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel > Family: (0x6), Model: (0xb5), Stepping: 0x0 > Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650 > Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff > Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800 > Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instruc tion, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC" > sockets = 1 > cores = 7 > hwThreads = 14 > } > > > Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`. > > We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least. > > This patch sets `0` to `cores` and "Hybrid Architecture" ... Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' into jfr-on-hy-cpu - Use jmc_undefined_long if runs on hybrid CPU - Revert "Update condition" This reverts commit ebf4aec23fa95c8d54d1196c7be85e99f0846420. - Update condition - Add fallback code if logical_cpus == 0 - 8365633: JFR reports incorrect number of cores on hybrid CPU ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27080/files - new: https://git.openjdk.org/jdk/pull/27080/files/2ebbde5f..aeea3fb0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27080&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27080&range=01-02 Stats: 14182 lines in 512 files changed: 6597 ins; 4715 del; 2870 mod Patch: https://git.openjdk.org/jdk/pull/27080.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27080/head:pull/27080 PR: https://git.openjdk.org/jdk/pull/27080 From mdoerr at openjdk.org Tue Sep 9 14:06:25 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 9 Sep 2025 14:06:25 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: <3t1NXG7f_TsOxvst83-A9dDPQ9ZOyl5ybNJDtpkhvAk=.671d5ae9-e32c-42de-a519-f52929495100@github.com> On Mon, 8 Sep 2025 09:09:49 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * sort includes Still works fine on SAP supported platforms (including PPC64). @RealFYang: Three way merge succeded. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3270891086 From mli at openjdk.org Tue Sep 9 14:13:16 2025 From: mli at openjdk.org (Hamlin Li) Date: Tue, 9 Sep 2025 14:13:16 GMT Subject: RFR: 8367066: RISC-V: refine register selection in MacroAssembler:: decode_klass_not_null [v2] In-Reply-To: References: Message-ID: > Hi, > Can you help to review this patch? > > Previously, the register selection in MacroAssembler:: decode_klass_not_null is misleading, better to refine it to improve the readability. > > Thanks! > > Running runtime test tier1/2/3... Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: refine ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27138/files - new: https://git.openjdk.org/jdk/pull/27138/files/7598f4d0..89ed8b85 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27138&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27138&range=00-01 Stats: 11 lines in 2 files changed: 2 ins; 6 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27138.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27138/head:pull/27138 PR: https://git.openjdk.org/jdk/pull/27138 From mli at openjdk.org Tue Sep 9 14:13:17 2025 From: mli at openjdk.org (Hamlin Li) Date: Tue, 9 Sep 2025 14:13:17 GMT Subject: RFR: 8367066: RISC-V: refine register selection in MacroAssembler:: decode_klass_not_null In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 23:47:48 GMT, Fei Yang wrote: > Yes, we still need one extra change to guarantee that dst != tmp, which we can do with a TEMP_DEF effect for dst. I tried adding this extra change and it seems to work. > > EDIT: My local `hotspot:tier1` passed with fastdebug build on SG2042. > > ``` > @@ -8936,7 +8941,7 @@ instruct encodeKlass_not_null(iRegNNoSp dst, iRegP src) %{ > instruct decodeKlass_not_null(iRegPNoSp dst, iRegN src, iRegPNoSp tmp) %{ > match(Set dst (DecodeNKlass src)); > > - effect(TEMP tmp); > + effect(TEMP_DEF dst, TEMP tmp); > > ins_cost(ALU_COST); > format %{ "decode_klass_not_null $dst, $src\t#@decodeKlass_not_null" %} > ``` In this sense, we're not saving one register (t0), as we require extra register by `effect(TEMP_DEF dst, TEMP tmp);`, right? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27138#issuecomment-3270918249 From mli at openjdk.org Tue Sep 9 14:13:18 2025 From: mli at openjdk.org (Hamlin Li) Date: Tue, 9 Sep 2025 14:13:18 GMT Subject: RFR: 8367066: RISC-V: refine register selection in MacroAssembler:: decode_klass_not_null In-Reply-To: References: Message-ID: <3Xne6ZyEvzrclfVRZbCQf-Hpd7Z09jNTkzAbGrUSAYo=.86349de3-67b2-4358-8ade-717472e4062f@github.com> On Mon, 8 Sep 2025 08:57:15 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > > Previously, the register selection in MacroAssembler:: decode_klass_not_null is misleading, better to refine it to improve the readability. > > Thanks! > > Running runtime test tier1/2/3... I think we can further simplify the code in `decode_klass_not_null`, pleaes check the latest commit. Test running... ------------- PR Comment: https://git.openjdk.org/jdk/pull/27138#issuecomment-3270919419 From lmesnik at openjdk.org Tue Sep 9 14:27:53 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 9 Sep 2025 14:27:53 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v8] In-Reply-To: References: Message-ID: > This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result. > The related fix here: > https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56 > Hope fix became clarere now. > > There 2 problems in this post_meth_exit: > 1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode. > 2) The method `get_jvmti_thread_state` should be called when thread is in vm state only. > > The fix adds `post_method_exit_transition` to have single exit point with oop restoration. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/prims/jvmtiExport.cpp Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27112/files - new: https://git.openjdk.org/jdk/pull/27112/files/3a169797..85482ae4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27112&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27112&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27112.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27112/head:pull/27112 PR: https://git.openjdk.org/jdk/pull/27112 From rehn at openjdk.org Tue Sep 9 15:01:19 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 9 Sep 2025 15:01:19 GMT Subject: RFR: 8367137: RISC-V: Detect Zicboz block size via hwprobe [v3] In-Reply-To: <23CI4KDVcMCZIYAGe0vznUlPgYHSyTR9W7zDF3UZGbo=.aeeaf1d3-c62c-4d39-af11-032cba41b82f@github.com> References: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> <23CI4KDVcMCZIYAGe0vznUlPgYHSyTR9W7zDF3UZGbo=.aeeaf1d3-c62c-4d39-af11-032cba41b82f@github.com> Message-ID: On Tue, 9 Sep 2025 08:26:43 GMT, Dingli Zhang wrote: >> Hi, >> Can you help to review this patch? Thanks! >> >> We can extends RISC-V hwprobe support to include `RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`. >> The probed value is recorded in VM_Version::zicboz_block_size and then used to set the global CacheLineSize. >> This ensures correct usage of the Zicboz extension, as block zeroing instructions operate on cache-line granularity. >> >> FYI: https://docs.kernel.org/arch/riscv/hwprobe.html > > Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: > > fix some assert I checked with kernel/cpu guy, apperently "cache blocks size" is instruction dependent in cmo spec. It have nothing todo with cache line size. (in theroy, but in practice to implement these in a high performance way they do) So you could have zic64b, with cboz size of 32 and zicbom size of 128. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27155#issuecomment-3271113818 From kbarrett at openjdk.org Tue Sep 9 15:03:22 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 9 Sep 2025 15:03:22 GMT Subject: RFR: 8367051: Build failure with clang on linux and AIX after switch to C++17 In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 01:00:30 GMT, Kim Barrett wrote: > 8367051: Build failure with clang on linux and AIX after switch to C++17 > > Please review this change to work around build failures with clang on some > platforms after the switch to C++17. > > C++17 made the exception specification part of a function's type. Some > standard libraries declare C library functions as noexcept. If HotSpot has a > forbidding declaration for such a function (without a noexcept spec) before > including the standard library header, clang reports this as an error (not > just a warning that could be suppressed, a hard error). If the standard > library header containing the noexpect declaration is first, then clang > does *not* complain about the following forbidding declaration that doesn't > have an exception spec. gcc permits either order. > > So the workaround consists of ensuring all the standard library headers for > forbidden functions are included before the forbidding declarations. > > Exploration of other approaches to follow, but for now we need to fix the > build errors. > > Testing: mach5 tier1 > GHA saniticy checks in progress Thanks for reviews. Since this is a simple change that fixes a build failure, I'm going to integrate now, without waiting for the usual 24 hours. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27154#issuecomment-3271124770 From kbarrett at openjdk.org Tue Sep 9 15:07:07 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 9 Sep 2025 15:07:07 GMT Subject: Integrated: 8367051: Build failure with clang on linux and AIX after switch to C++17 In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 01:00:30 GMT, Kim Barrett wrote: > 8367051: Build failure with clang on linux and AIX after switch to C++17 > > Please review this change to work around build failures with clang on some > platforms after the switch to C++17. > > C++17 made the exception specification part of a function's type. Some > standard libraries declare C library functions as noexcept. If HotSpot has a > forbidding declaration for such a function (without a noexcept spec) before > including the standard library header, clang reports this as an error (not > just a warning that could be suppressed, a hard error). If the standard > library header containing the noexpect declaration is first, then clang > does *not* complain about the following forbidding declaration that doesn't > have an exception spec. gcc permits either order. > > So the workaround consists of ensuring all the standard library headers for > forbidden functions are included before the forbidding declarations. > > Exploration of other approaches to follow, but for now we need to fix the > build errors. > > Testing: mach5 tier1 > GHA saniticy checks in progress This pull request has now been integrated. Changeset: b653ae92 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/b653ae92d5941202780873fad1a7cefd51e4e7a8 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod 8367051: Build failure with clang on linux and AIX after switch to C++17 Reviewed-by: dholmes, ayang, mbaesken, mdoerr ------------- PR: https://git.openjdk.org/jdk/pull/27154 From djelinski at openjdk.org Tue Sep 9 15:25:25 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 9 Sep 2025 15:25:25 GMT Subject: RFR: 8366984: Remove delay slot support [v2] In-Reply-To: References: Message-ID: > SPARC was the only supported architecture that uses a delay slot. The SPARC port was removed in JDK 15, and the code is effectively dead. Let's remove it. > > The changes are no-op on all architectures that do not use delay slots. I still tested tier 1-5 on mach5, no related failures. Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27119/files - new: https://git.openjdk.org/jdk/pull/27119/files/330d5ad1..330d5ad1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27119&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27119&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27119.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27119/head:pull/27119 PR: https://git.openjdk.org/jdk/pull/27119 From simonis at openjdk.org Tue Sep 9 15:36:21 2025 From: simonis at openjdk.org (Volker Simonis) Date: Tue, 9 Sep 2025 15:36:21 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands [v2] In-Reply-To: References: Message-ID: On Tue, 2 Sep 2025 10:08:58 GMT, Kerem Kat wrote: >> Prevents segmentation faults during `gdb` sessions. The crashes were caused by the `ResourceMark` constructor being called on a native thread, which is not supported. This happened when invoking debug commands that require a `Thread` or `JavaThread` context from an incorrect thread type. >> >> ### Solution >> >> This change introduces `onThread()` and `onJavaThread()` helper methods to the `Command` class. These methods validate the thread context and ensure `ResourceMark` is only created when on a valid VM thread. All thread-dependent debug commands now use these guards to validate the context, printing a clear error and exiting gracefully upon failure. >> >> ### Testing >> >> Manually verified using `gdb` by calling the modified commands (`ps`, `universe`, `pns`, etc.) from different thread contexts (native, Java, and non-java threads) to ensure they fail gracefully with an error message instead of crashing the debug session. > > Kerem Kat has updated the pull request incrementally with two additional commits since the last revision: > > - add include for global placement new > - remove onJavaThread and check JavaThread::active null where needed Thanks for this change, I like it! src/hotspot/share/utilities/debug.cpp line 305: > 303: // ResourceMark is only created if a Thread or a JavaThread is required, > 304: // and we are actually on a Thread. > 305: union { ResourceMark _rm; }; The semantics of `union { ResourceMark _rm; }` was not familiar to me and it took me some time to find it in the specification. Maybe make this more obvious by refining the comment to something like: // Union members of class type are implicitly allocated but not constructed automatically. // We therefor have to explicitly construct '_rm' with a placement new call (see 'onThread()') and // clean it up afterwards with an explicit destructor call (see '~Command()'). ------------- PR Review: https://git.openjdk.org/jdk/pull/27033#pullrequestreview-3202179268 PR Review Comment: https://git.openjdk.org/jdk/pull/27033#discussion_r2334025808 From mdoerr at openjdk.org Tue Sep 9 15:51:38 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 9 Sep 2025 15:51:38 GMT Subject: RFR: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state [v8] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 14:27:53 GMT, Leonid Mesnik wrote: >> This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result. >> The related fix here: >> https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56 >> Hope fix became clarere now. >> >> There 2 problems in this post_meth_exit: >> 1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode. >> 2) The method `get_jvmti_thread_state` should be called when thread is in vm state only. >> >> The fix adds `post_method_exit_transition` to have single exit point with oop restoration. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/prims/jvmtiExport.cpp > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> Marked as reviewed by mdoerr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27112#pullrequestreview-3202259586 From mdoerr at openjdk.org Tue Sep 9 15:54:43 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 9 Sep 2025 15:54:43 GMT Subject: RFR: 8367051: Build failure with clang on linux and AIX after switch to C++17 In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 01:00:30 GMT, Kim Barrett wrote: > 8367051: Build failure with clang on linux and AIX after switch to C++17 > > Please review this change to work around build failures with clang on some > platforms after the switch to C++17. > > C++17 made the exception specification part of a function's type. Some > standard libraries declare C library functions as noexcept. If HotSpot has a > forbidding declaration for such a function (without a noexcept spec) before > including the standard library header, clang reports this as an error (not > just a warning that could be suppressed, a hard error). If the standard > library header containing the noexpect declaration is first, then clang > does *not* complain about the following forbidding declaration that doesn't > have an exception spec. gcc permits either order. > > So the workaround consists of ensuring all the standard library headers for > forbidden functions are included before the forbidding declarations. > > Exploration of other approaches to follow, but for now we need to fix the > build errors. > > Testing: mach5 tier1 > GHA saniticy checks in progress Thanks for fixing it quickly! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27154#issuecomment-3271321606 From jwaters at openjdk.org Tue Sep 9 16:48:11 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 9 Sep 2025 16:48:11 GMT Subject: RFR: 8367051: Build failure with clang on linux and AIX after switch to C++17 In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 01:00:30 GMT, Kim Barrett wrote: > 8367051: Build failure with clang on linux and AIX after switch to C++17 > > Please review this change to work around build failures with clang on some > platforms after the switch to C++17. > > C++17 made the exception specification part of a function's type. Some > standard libraries declare C library functions as noexcept. If HotSpot has a > forbidding declaration for such a function (without a noexcept spec) before > including the standard library header, clang reports this as an error (not > just a warning that could be suppressed, a hard error). If the standard > library header containing the noexpect declaration is first, then clang > does *not* complain about the following forbidding declaration that doesn't > have an exception spec. gcc permits either order. > > So the workaround consists of ensuring all the standard library headers for > forbidden functions are included before the forbidding declarations. > > Exploration of other approaches to follow, but for now we need to fix the > build errors. > > Testing: mach5 tier1 > GHA saniticy checks in progress Seems like a good reminder for me to resume working on that static analyzer as soon as possible. Wasn't fast enough to add my approval but have a +1 anyway ------------- PR Comment: https://git.openjdk.org/jdk/pull/27154#issuecomment-3271497568 From asmehra at openjdk.org Tue Sep 9 16:49:12 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 9 Sep 2025 16:49:12 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v6] In-Reply-To: References: Message-ID: On Thu, 28 Aug 2025 21:17:42 GMT, Ioi Lam wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - @DanHeidinga comments -- added comments and asserts about the handling of enums > - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase > - @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run > - @DanHeidinga comments > - tightened SystemDictionary::preload_class() > - Fixed bugs found in JCK > - added entry in ProblemList-AotJdk.txt due to 8323727 > - more clean up > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - ... and 10 more: https://git.openjdk.org/jdk/compare/075ddef8...1a8ea501 src/hotspot/share/cds/aotOopChecker.cpp line 53: > 51: // the production run. > 52: void AOTOopChecker::check(oop obj) { > 53: precond(vmClasses::URL_klass()->is_final()); `AOTOopChecker::check` is a generic method, so this precond should ideally be inside the next block that explicitly handles URL class objects. src/hotspot/share/cds/aotOopChecker.cpp line 55: > 53: precond(vmClasses::URL_klass()->is_final()); > 54: > 55: if (obj->klass()->is_subclass_of(vmClasses::URL_klass())) { URL is a final class, so shouldn't `obj->klass() == vmClasses::URL_klass()` be sufficient? src/hotspot/share/classfile/javaClasses.cpp line 1063: > 1061: > 1062: // Statically allocate fixup lists because they always get created. > 1063: void java_lang_Class::allocate_fixup_lists() { Do we need `fixup_module_field_list` when `is_using_preloaded_classes` is true? src/hotspot/share/memory/iterator.inline.hpp line 58: > 56: ClaimMetadataVisitingOopIterateClosure::do_cld(cld); > 57: } else { > 58: assert(AOTLinkedClassBulkLoader::is_pending_aot_linked_class(k), "sanity"); Why is the null check and assert not valid anymore? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2331108015 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2334124611 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2334124798 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2334211674 From djelinski at openjdk.org Tue Sep 9 16:59:31 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 9 Sep 2025 16:59:31 GMT Subject: RFR: 8366984: Remove delay slot support [v3] In-Reply-To: References: Message-ID: > SPARC was the only supported architecture that uses a delay slot. The SPARC port was removed in JDK 15, and the code is effectively dead. Let's remove it. > > The changes are no-op on all architectures that do not use delay slots. I still tested tier 1-5 on mach5, no related failures. Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Merge remote-tracking branch 'origin/master' into delay-slot - Revert scope_desc change, breaks macos-aarch64 - Remove remaining comments - Update copyright - Remove commented out code - Remove unused variables - Comment out unused _unconditional_delay_slot - Remove bundle flags - Remove delay slot support from ADL - Clean up delay slot remnants from arm32 code - ... and 4 more: https://git.openjdk.org/jdk/compare/cc6d34b2...fb68b5a8 ------------- Changes: https://git.openjdk.org/jdk/pull/27119/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27119&range=02 Stats: 456 lines in 19 files changed: 1 ins; 407 del; 48 mod Patch: https://git.openjdk.org/jdk/pull/27119.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27119/head:pull/27119 PR: https://git.openjdk.org/jdk/pull/27119 From krk at openjdk.org Tue Sep 9 17:19:23 2025 From: krk at openjdk.org (Kerem Kat) Date: Tue, 9 Sep 2025 17:19:23 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands [v3] In-Reply-To: References: Message-ID: > Prevents segmentation faults during `gdb` sessions. The crashes were caused by the `ResourceMark` constructor being called on a native thread, which is not supported. This happened when invoking debug commands that require a `Thread` or `JavaThread` context from an incorrect thread type. > > ### Solution > > This change introduces `onThread()` and `onJavaThread()` helper methods to the `Command` class. These methods validate the thread context and ensure `ResourceMark` is only created when on a valid VM thread. All thread-dependent debug commands now use these guards to validate the context, printing a clear error and exiting gracefully upon failure. > > ### Testing > > Manually verified using `gdb` by calling the modified commands (`ps`, `universe`, `pns`, etc.) from different thread contexts (native, Java, and non-java threads) to ensure they fail gracefully with an error message instead of crashing the debug session. Kerem Kat has updated the pull request incrementally with two additional commits since the last revision: - refine comment - remove redundant proto for findpc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27033/files - new: https://git.openjdk.org/jdk/pull/27033/files/0d3ded95..d19470e7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27033&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27033&range=01-02 Stats: 6 lines in 1 file changed: 1 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27033.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27033/head:pull/27033 PR: https://git.openjdk.org/jdk/pull/27033 From krk at openjdk.org Tue Sep 9 17:19:26 2025 From: krk at openjdk.org (Kerem Kat) Date: Tue, 9 Sep 2025 17:19:26 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands [v2] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 15:31:30 GMT, Volker Simonis wrote: >> Kerem Kat has updated the pull request incrementally with two additional commits since the last revision: >> >> - add include for global placement new >> - remove onJavaThread and check JavaThread::active null where needed > > src/hotspot/share/utilities/debug.cpp line 305: > >> 303: // ResourceMark is only created if a Thread or a JavaThread is required, >> 304: // and we are actually on a Thread. >> 305: union { ResourceMark _rm; }; > > The semantics of `union { ResourceMark _rm; }` was not familiar to me and it took me some time to find it in the specification. Maybe make this more obvious by refining the comment to something like: > > > // Union members of class type are implicitly allocated but not constructed automatically. > // We therefor have to explicitly construct '_rm' with a placement new call (see 'onThread()') and > // clean it up afterwards with an explicit destructor call (see '~Command()'). Thank you, updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27033#discussion_r2334269045 From krk at openjdk.org Tue Sep 9 17:19:27 2025 From: krk at openjdk.org (Kerem Kat) Date: Tue, 9 Sep 2025 17:19:27 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands [v3] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 10:19:19 GMT, Kevin Walls wrote: >> Thank you for the description for `hasActiveThread`. Is it much different than the `onJavaThread` in the first revision? > > OK, I see now that I'm suggesting more like what you had originally, that you go back to what David disliked. 8-) > > I would have gone for having this check in the helper method (even if it means multiple Thread::current calls) over duplication inserted into three command implementations. Seems like a way to fix their assumptions also. > > Just want to check with David if he might agree that keeping the individual commands simpler is worth permitting the additional helper method. Thank you for the clarification! That makes sense. I'll move forward with David's suggestion to have the duplication where the `Command` objects are used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27033#discussion_r2334277875 From simonis at openjdk.org Tue Sep 9 18:10:08 2025 From: simonis at openjdk.org (Volker Simonis) Date: Tue, 9 Sep 2025 18:10:08 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands [v3] In-Reply-To: References: Message-ID: <1dkECDXYXbMwDI4_7PbC517BJcFIASPiw8zyMq_AskA=.27c45170-eb91-4aa2-8957-0d1f01c524c9@github.com> On Tue, 9 Sep 2025 17:19:23 GMT, Kerem Kat wrote: >> Prevents segmentation faults during `gdb` sessions. The crashes were caused by the `ResourceMark` constructor being called on a native thread, which is not supported. This happened when invoking debug commands that require a `Thread` or `JavaThread` context from an incorrect thread type. >> >> ### Solution >> >> This change introduces `onThread()` and `onJavaThread()` helper methods to the `Command` class. These methods validate the thread context and ensure `ResourceMark` is only created when on a valid VM thread. All thread-dependent debug commands now use these guards to validate the context, printing a clear error and exiting gracefully upon failure. >> >> ### Testing >> >> Manually verified using `gdb` by calling the modified commands (`ps`, `universe`, `pns`, etc.) from different thread contexts (native, Java, and non-java threads) to ensure they fail gracefully with an error message instead of crashing the debug session. > > Kerem Kat has updated the pull request incrementally with two additional commits since the last revision: > > - refine comment > - remove redundant proto for findpc Marked as reviewed by simonis (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27033#pullrequestreview-3202719219 From eosterlund at openjdk.org Tue Sep 9 19:37:31 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 9 Sep 2025 19:37:31 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v5] In-Reply-To: References: Message-ID: On Mon, 4 Aug 2025 21:26:22 GMT, Dean Long wrote: >> This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value. Further, it takes a fast-path that uses the previous direct store when at a safepoint. Combined, these changes should get us back to almost where we were before in terms of overhead. If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > one unconditional release should be enough Sorry for the delay. Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26399#pullrequestreview-3203004583 From asmehra at openjdk.org Tue Sep 9 22:06:17 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 9 Sep 2025 22:06:17 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 14:49:48 GMT, Ashutosh Mehra wrote: > This PR removes the need to store entry point addresses in AdapterHandlerEntry by storing a direct pointer to AdapterBlob instead. Entry point addresses can be computed on the fly from the entry point offsets stored in AdapterBlob. @adinn @shipilev can you please review this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27101#issuecomment-3272423932 From iklam at openjdk.org Tue Sep 9 22:09:06 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 9 Sep 2025 22:09:06 GMT Subject: RFR: 8367142: Simplify java mirror handling in JNI methods [v2] In-Reply-To: References: Message-ID: > The purpose of this PR is to simplify JNI code and also to avoid unnecessary `InstanceKlass::cast()` calls. > > This PR is intended to be a strict clean-up that preserves existing behaviors. > > The following helper functions are added to simplify boilerplate code in JNI methods. > > > static Klass* java_lang_Class::as_Klass(jobject java_class); > static InstanceKlass* java_lang_Class::as_InstanceKlass(oop java_class); > static InstanceKlass* java_lang_Class::as_InstanceKlass(jobject java_class); > > Klass* get_klass_considering_redefinition(jclass cls, JavaThread *thread); > InstanceKlass* get_instance_klass_considering_redefinition(jclass cls, JavaThread *thread); > > > Notes: > > [1] Before this PR, we have both patterns: > > > java_lang_Class::as_Klass(JNIHandles::resolve(cls)); > java_lang_Class::as_Klass(JNIHandles::resolve_non_null(cls)); > > > If `cls` is null, we would get an assert in both cases (`as_Klass()` requires a non-null input). Therefore, I am using `resolve_non_null()` in the `jobject` versions of `as_Klass()`. > > [2] I refactored `JvmtiThreadState::class_to_verify_considering_redefinition()` so that the caller of this funcation can avoid using `InstanceKlass::cast()`. This is possible because we ONLY store `InstanceKlass*` in `JvmtiThreadState::set_class_being_redefined()` > > I also removed a few cases of unnecessary `InstanceKlass::cast()`. Ioi Lam 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 8367142-simplify-java-mirror-handling-in-jni-methods - @dholmes-ora comments - remove class_to_verify_considering_redefinition() changes, to be done in separate PR - more fixes - tmp: Clean up java mirror handling in JNI methods ------------- Changes: https://git.openjdk.org/jdk/pull/27158/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27158&range=01 Stats: 150 lines in 17 files changed: 20 ins; 32 del; 98 mod Patch: https://git.openjdk.org/jdk/pull/27158.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27158/head:pull/27158 PR: https://git.openjdk.org/jdk/pull/27158 From iklam at openjdk.org Tue Sep 9 22:12:48 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 9 Sep 2025 22:12:48 GMT Subject: RFR: 8367142: Simplify java mirror handling in JNI methods [v2] In-Reply-To: References: <30w65N-VMzjkn9Tpy6cXrKz2F-gyoGSyCMpzLc2H8HI=.82760ff5-84b2-4adb-897e-ee8f94be6dad@github.com> Message-ID: On Tue, 9 Sep 2025 07:38:03 GMT, David Holmes wrote: > > So I am not sure if we really have that separation anymore. > > I think it is more that there are many bits of code that actually form the "boundary" (prims, services, some runtime, jvmci, interpreter-related). But I guess it is hard to argue this makes it markedly worse. Arguably the translation of Java mirrors to Klasses is also a boundary (from Java representation to VM representation) :-) In reality I think because jobjects are easy to use and are just another kind of handle (like Handle and OopHandle), the leakage from JNI code to other parts of VM just happened naturally. > > The code already assumes that it has an InstanceKlass, and I am not changing that. > > Okay. BTW I removed the JVMTI changes from this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27158#issuecomment-3272437346 From dlong at openjdk.org Tue Sep 9 23:31:01 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 9 Sep 2025 23:31:01 GMT Subject: RFR: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 [v5] In-Reply-To: <-MqvO74Up2R0qmEDtgyGY-yScxZ-v6ZQWxDtSxpKO_g=.56d4eeca-670d-41e4-9e96-ba20b1b44100@github.com> References: <-MqvO74Up2R0qmEDtgyGY-yScxZ-v6ZQWxDtSxpKO_g=.56d4eeca-670d-41e4-9e96-ba20b1b44100@github.com> Message-ID: On Wed, 27 Aug 2025 20:17:07 GMT, Erik ?sterlund wrote: >> @fisk , can I get you to review this? > >> @fisk , can I get you to review this? > > Sure! Based on the symptoms you described, my main comment is that we might be looking at the wrong places. I don't know if this is really about lock contention. Perhaps it is indirectly. But you mention there is still so e regression with ZGC. > > My hypothesis would be that it is the unnecessary incrementing of the global patching epoch that causes the regression when using ZGC. It is only really needed when disarming the nmethod - in orher words when the guard value is set to the good value. > > The point of incrementing the patching epoch is to protect other threads from entering the nmethod without executing an instruction cross modication fence. And all other threads will have to do that. > > Only ZGC uses the mode of nmethod entry barriers that does this due to being the only GC that updates instructions in a concurrent phase on AArch64. We are conservative on AArch64 and ensure the use of appropriate synchronous cross modifying code. But that's not needed when arming, which is what we do when making the bmethod not entrant. Thanks @fisk and @theRealAph . ------------- PR Comment: https://git.openjdk.org/jdk/pull/26399#issuecomment-3272594352 From dlong at openjdk.org Tue Sep 9 23:31:03 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 9 Sep 2025 23:31:03 GMT Subject: Integrated: 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 In-Reply-To: References: Message-ID: On Sat, 19 Jul 2025 01:39:12 GMT, Dean Long wrote: > This PR removes the recently added lock around set_guard_value, using instead Atomic::cmpxchg to atomically update bit-fields of the guard value. Further, it takes a fast-path that uses the previous direct store when at a safepoint. Combined, these changes should get us back to almost where we were before in terms of overhead. If necessary, we could go even further and allow make_not_entrant() to perform a direct byte store, leaving 24 bits for the guard value. This pull request has now been integrated. Changeset: f9640398 Author: Dean Long URL: https://git.openjdk.org/jdk/commit/f96403986b99008593e025c4991ee865fce59bb1 Stats: 240 lines in 15 files changed: 128 ins; 71 del; 41 mod 8361376: Regressions 1-6% in several Renaissance in 26-b4 only MacOSX aarch64 Co-authored-by: Martin Doerr Reviewed-by: mdoerr, aph, eosterlund ------------- PR: https://git.openjdk.org/jdk/pull/26399 From lmesnik at openjdk.org Tue Sep 9 23:53:19 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 9 Sep 2025 23:53:19 GMT Subject: Integrated: 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state In-Reply-To: References: Message-ID: <7xsRH4FlK6fHdOOzXFFeObrcx9MinJOswOtWT6xG8t8=.13dd022d-6118-4af6-9e60-a94be8659a69@github.com> On Fri, 5 Sep 2025 06:22:15 GMT, Leonid Mesnik wrote: > This is the second attempt to fix method `post_meth_exit` to correctly set state and preserve result. > The related fix here: > https://github.com/openjdk/jdk/commit/b7b64bb6c800b45e32ff37b1b92b5927a3b3fb56 > Hope fix became clarere now. > > There 2 problems in this post_meth_exit: > 1) The result is preserved only if `state->is_enabled(JVMTI_EVENT_METHOD_EXIT)` however transition in the JRT_BLOCK_END happens always. So there is a risk of loosing method results in the interp_only mode. > 2) The method `get_jvmti_thread_state` should be called when thread is in vm state only. > > The fix adds `post_method_exit_transition` to have single exit point with oop restoration. This pull request has now been integrated. Changeset: 8cd4e7d8 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/8cd4e7d856dcc68243505f4e771dc8ab87176584 Stats: 55 lines in 1 file changed: 24 ins; 20 del; 11 mod 8365192: post_meth_exit should be in vm state when calling get_jvmti_thread_state Reviewed-by: mdoerr, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/27112 From fyang at openjdk.org Wed Sep 10 00:35:10 2025 From: fyang at openjdk.org (Fei Yang) Date: Wed, 10 Sep 2025 00:35:10 GMT Subject: RFR: 8367066: RISC-V: refine register selection in MacroAssembler:: decode_klass_not_null [v2] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 14:13:16 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> >> Previously, the register selection in MacroAssembler:: decode_klass_not_null is misleading, better to refine it to improve the readability. >> >> Thanks! >> >> Running runtime test tier1/2/3... > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > refine Marked as reviewed by fyang (Reviewer). src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 3423: > 3421: if (CompressedKlassPointers::shift() != 0) { > 3422: // dst = (src << shift) + xbase > 3423: shadd(dst, src, xbase, dst /* temporary, dst != xbase */, CompressedKlassPointers::shift()); Is it safer to turn the code comment into an assertion? It will trigger if people incorrectly sets `xbase`. assert_different_registers(dst, xbase); // dst = (src << shift) + xbase shadd(dst, src, xbase, dst, CompressedKlassPointers::shift()); ------------- PR Review: https://git.openjdk.org/jdk/pull/27138#pullrequestreview-3203851463 PR Review Comment: https://git.openjdk.org/jdk/pull/27138#discussion_r2335153299 From fyang at openjdk.org Wed Sep 10 00:35:12 2025 From: fyang at openjdk.org (Fei Yang) Date: Wed, 10 Sep 2025 00:35:12 GMT Subject: RFR: 8367066: RISC-V: refine register selection in MacroAssembler:: decode_klass_not_null In-Reply-To: <3Xne6ZyEvzrclfVRZbCQf-Hpd7Z09jNTkzAbGrUSAYo=.86349de3-67b2-4358-8ade-717472e4062f@github.com> References: <3Xne6ZyEvzrclfVRZbCQf-Hpd7Z09jNTkzAbGrUSAYo=.86349de3-67b2-4358-8ade-717472e4062f@github.com> Message-ID: <3IR_MQMbCC6ixoANmfLZJl0ZXZVE7hmCvGxb5XP3c0s=.aaeda614-d986-483d-8d5a-756dbbe56441@github.com> On Tue, 9 Sep 2025 14:09:47 GMT, Hamlin Li wrote: > I think we can further simplify the code in `decode_klass_not_null`, pleaes check the latest commit. Test running... Yes, the code now looks more simplified. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27138#issuecomment-3272775297 From fyang at openjdk.org Wed Sep 10 01:03:19 2025 From: fyang at openjdk.org (Fei Yang) Date: Wed, 10 Sep 2025 01:03:19 GMT Subject: RFR: 8367137: RISC-V: Detect Zicboz block size via hwprobe [v3] In-Reply-To: References: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> <23CI4KDVcMCZIYAGe0vznUlPgYHSyTR9W7zDF3UZGbo=.aeeaf1d3-c62c-4d39-af11-032cba41b82f@github.com> Message-ID: <-7659a2pMMXs8Q8X23cVPxmv4QQGOtGV7ZPNuEqaRqk=.56cdd1d6-2ce4-4104-9fb1-f68c0970a616@github.com> On Tue, 9 Sep 2025 14:58:25 GMT, Robbin Ehn wrote: > I checked with kernel/cpu guy, apperently "cache blocks size" is instruction dependent in cmo spec. It have nothing todo with cache line size. (in theory, but in practice to implement these in a high performance way they do) So you could have zic64b, with cboz size of 32 and zicbom size of 128. Ah, that could mean a bug in `MacroAssembler::zero_dcache_blocks` which assumes that CBO.ZERO would zero a cache line instead of a cache block. We should use Zicboz block size detected here instead if it's not zero. (Also note that UseZicboz is experimental for now and it is only enabled in VM_Version::rivos_features()) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27155#issuecomment-3272833150 From dlong at openjdk.org Wed Sep 10 01:07:22 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 10 Sep 2025 01:07:22 GMT Subject: RFR: 8366984: Remove delay slot support [v3] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 16:59:31 GMT, Daniel Jeli?ski wrote: >> SPARC was the only supported architecture that uses a delay slot. The SPARC port was removed in JDK 15, and the code is effectively dead. Let's remove it. >> >> The changes are no-op on all architectures that do not use delay slots. I still tested tier 1-5 on mach5, no related failures. > > Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge remote-tracking branch 'origin/master' into delay-slot > - Revert scope_desc change, breaks macos-aarch64 > - Remove remaining comments > - Update copyright > - Remove commented out code > - Remove unused variables > - Comment out unused _unconditional_delay_slot > - Remove bundle flags > - Remove delay slot support from ADL > - Clean up delay slot remnants from arm32 code > - ... and 4 more: https://git.openjdk.org/jdk/compare/cc6d34b2...fb68b5a8 Marked as reviewed by dlong (Reviewer). src/hotspot/share/runtime/sharedRuntime.cpp line 3505: > 3503: nm = cb->as_nmethod(); > 3504: method = nm->method(); > 3505: for (ScopeDesc *sd = nm->scope_desc_near(fr.pc()); sd != nullptr; sd = sd->sender()) { It's tempting to try to change this to scope_desc_at(), but also slightly risky if SPARC isn't the only reason it was needed. Should we investigate this in a separate RFE? ------------- PR Review: https://git.openjdk.org/jdk/pull/27119#pullrequestreview-3203943528 PR Review Comment: https://git.openjdk.org/jdk/pull/27119#discussion_r2335213805 From dlong at openjdk.org Wed Sep 10 01:09:16 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 10 Sep 2025 01:09:16 GMT Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3] In-Reply-To: <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com> References: <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com> Message-ID: On Tue, 2 Sep 2025 20:52:32 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 three additional commits since the last revision: > > - revert whitespace change > - undo debug changes > - cleanup I need one more review for this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27059#issuecomment-3272844515 From coleenp at openjdk.org Wed Sep 10 02:03:13 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 10 Sep 2025 02:03:13 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v9] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 04:43:46 GMT, Ioi Lam wrote: >> During the assembly phase of the AOT cache, we link and verify all classes that were loaded during the training run. When verifying a class like this: >> >> >> class X { >> A getA() { return new B(); } // Verifier requires B to be a subtype of A. >> } >> >> >> We remember `A` and `B` as the "verification dependencies" of `X`. A class will be excluded from the AOT cache if any of its verification dependencies are excluded. For example, `X` will be excluded if >> >> - `A` fails verification >> - `B` is a signed class, which is always excluded from the AOT cache >> >> Conversely, if both `A` and `B` are included in the AOT cache, in the production run, they will be unconditionally loaded during VM bootstrap. Therefore, we can guarantee that the verification result computed for `X` will remain valid during the production run. >> >> Notes for reviewers: >> >> - The checks for verification dependencies are done inside `SystemDictionaryShared::check_exclusion_for_self_and_dependencies()`. These checks are done for both old and new classes. Since the dependencies can form a cyclic graph, the checks cannot be implemented with a simple recursion. See "Algorithm notes" in this function for details. >> - The verification dependencies for "new" classes are already stored in `DumpTimeClassInfo::_verifier_constraints`. >> - This PR adds code to record the verification dependencies for "old" classes into `DumpTimeClassInfo::_old_verifier_dependencies`, by intercepting `JVM_FindClassFromCaller()`. >> - This new functionality (store old classes in linked state) is available only when using the AOT cache. For simplicity, this functionality is not available with the old CDS workflows. See comments in `CDSConfig::is_preserving_verification_dependencies()`. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > updated comments This is good. Thanks for all the comments and explanations. The tests look good, particularly the descriptive names of the test classes. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26754#pullrequestreview-3204060439 From dzhang at openjdk.org Wed Sep 10 02:06:34 2025 From: dzhang at openjdk.org (Dingli Zhang) Date: Wed, 10 Sep 2025 02:06:34 GMT Subject: RFR: 8367137: RISC-V: Detect Zicboz block size via hwprobe [v4] In-Reply-To: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> References: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> Message-ID: > Hi, > Can you help to review this patch? Thanks! > > We can extends RISC-V hwprobe support to include `RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`. > The probed value is recorded in VM_Version::zicboz_block_size and then used to set the global CacheLineSize. > This ensures correct usage of the Zicboz extension, as block zeroing instructions operate on cache-line granularity. > > FYI: https://docs.kernel.org/arch/riscv/hwprobe.html Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: Replace CacheLineSize with zicboz_block_size in block zeroing logic ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27155/files - new: https://git.openjdk.org/jdk/pull/27155/files/bcb0453b..4fbbedde Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27155&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27155&range=02-03 Stats: 12 lines in 2 files changed: 1 ins; 3 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/27155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27155/head:pull/27155 PR: https://git.openjdk.org/jdk/pull/27155 From dzhang at openjdk.org Wed Sep 10 02:06:36 2025 From: dzhang at openjdk.org (Dingli Zhang) Date: Wed, 10 Sep 2025 02:06:36 GMT Subject: RFR: 8367137: RISC-V: Detect Zicboz block size via hwprobe [v3] In-Reply-To: References: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> <23CI4KDVcMCZIYAGe0vznUlPgYHSyTR9W7zDF3UZGbo=.aeeaf1d3-c62c-4d39-af11-032cba41b82f@github.com> Message-ID: <3Q7yZVmGWuzzOk3E7SlHXYyQ1pbJ_ww4za8SBITxlz8=.bb12c1d8-4438-4946-ac32-e9125486045d@github.com> On Tue, 9 Sep 2025 14:58:25 GMT, Robbin Ehn wrote: >> Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: >> >> fix some assert > > I checked with kernel/cpu guy, apperently "cache blocks size" is instruction dependent in cmo spec. > It have nothing todo with cache line size. (in theory, but in practice to implement these in a high performance way they do) > So you could have zic64b, with cboz size of 32 and zicbom size of 128. Hi @robehn @RealFYang Thanks for the review! Could you please take a look at it again? Thanks in advance. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27155#issuecomment-3272932893 From kbarrett at openjdk.org Wed Sep 10 03:05:56 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 10 Sep 2025 03:05:56 GMT Subject: RFR: 8367282: FORBID_C_FUNCTION needs exception spec consistent with library declaration Message-ID: Please review this change to FORBID_C_FUNCTION to make the exception specs of the forbidding declarations match up with the exception specs of the associated library declarations. This needs to account for different platform libraries either having or not having exception specs. It's needed because, after switching to C++17, some compilers complain about some differences in the exception specs. Also removed the workaround for JDK-8367051, which should no longer be needed after this change. Hoping someone will test the aix-ppc port. @MBaesken or @TheRealMDoerr ? Testing: mach5 tier1, GHA sanity checks (nearly finished) Locally (linux-aarch64) built with clang, which failed without the JDK-8367051 workaround. ------------- Commit messages: - remove JDK-8367051 workaround - add noexcept Changes: https://git.openjdk.org/jdk/pull/27180/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27180&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367282 Stats: 68 lines in 4 files changed: 26 ins; 9 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/27180.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27180/head:pull/27180 PR: https://git.openjdk.org/jdk/pull/27180 From kbarrett at openjdk.org Wed Sep 10 03:30:17 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 10 Sep 2025 03:30:17 GMT Subject: RFR: 8366057: HotSpot Style Guide should permit trailing return types [v2] In-Reply-To: <3BK_mYdIzPe4LIz8ntBVa5Hhph4kHIP1TxtGoAslqYw=.ba18dfad-8046-4e30-b0d4-e3a1ccc4cefe@github.com> References: <3BK_mYdIzPe4LIz8ntBVa5Hhph4kHIP1TxtGoAslqYw=.ba18dfad-8046-4e30-b0d4-e3a1ccc4cefe@github.com> Message-ID: On Tue, 9 Sep 2025 03:00:32 GMT, Kim Barrett wrote: >> Please review this change to the HotSpot Style Guide to permit trailing return >> types for functions. >> >> This is a modification of the Style Guide, so rough consensus among the >> HotSpot Group members is required to make this change. Only Group members >> should vote for approval (via the github PR), though reasoned objections or >> comments from anyone will be considered. A decision on this proposal will not >> be made before Monday 8-September-2025 at 12h00 UTC. >> >> Since we're piggybacking on github PRs here, please use the PR review process >> to approve (click on Review Changes > Approve), rather than sending a "vote: >> yes" email reply that would be normal for a CFV. > > Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' into trailing-return-type > - permit trailing return types Thanks for reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26923#issuecomment-3273139588 From kbarrett at openjdk.org Wed Sep 10 03:33:18 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 10 Sep 2025 03:33:18 GMT Subject: Integrated: 8366057: HotSpot Style Guide should permit trailing return types In-Reply-To: References: Message-ID: <_uJfM3ZcDsiF5Abyq5vbXrfEsMjvRBG403XIPIZswDk=.f690c13c-7fa5-4b8b-8404-d80bc58e5e53@github.com> On Mon, 25 Aug 2025 10:07:00 GMT, Kim Barrett wrote: > Please review this change to the HotSpot Style Guide to permit trailing return > types for functions. > > This is a modification of the Style Guide, so rough consensus among the > HotSpot Group members is required to make this change. Only Group members > should vote for approval (via the github PR), though reasoned objections or > comments from anyone will be considered. A decision on this proposal will not > be made before Monday 8-September-2025 at 12h00 UTC. > > Since we're piggybacking on github PRs here, please use the PR review process > to approve (click on Review Changes > Approve), rather than sending a "vote: > yes" email reply that would be normal for a CFV. This pull request has now been integrated. Changeset: af9b9050 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/af9b9050ec51d0c43690fc42658741bd865b0310 Stats: 85 lines in 2 files changed: 81 ins; 0 del; 4 mod 8366057: HotSpot Style Guide should permit trailing return types Reviewed-by: dholmes, stefank, kvn, adinn, jsjolen ------------- PR: https://git.openjdk.org/jdk/pull/26923 From iklam at openjdk.org Wed Sep 10 04:16:03 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Sep 2025 04:16:03 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v7] In-Reply-To: References: Message-ID: <8G1dsw-1ZWVIFcReoyb2Bt0lo28ObCu6eh-affuYWLU=.f00e92f7-6bea-4cb1-a287-9a18ca0fcee3@github.com> > This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. > > - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. > - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. > - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: - @ashu-mehra review comments - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - @DanHeidinga comments -- added comments and asserts about the handling of enums - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase - @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run - @DanHeidinga comments - tightened SystemDictionary::preload_class() - Fixed bugs found in JCK - added entry in ProblemList-AotJdk.txt due to 8323727 - ... and 12 more: https://git.openjdk.org/jdk/compare/8cd4e7d8...959a2c91 ------------- Changes: https://git.openjdk.org/jdk/pull/26375/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=06 Stats: 716 lines in 44 files changed: 602 ins; 13 del; 101 mod Patch: https://git.openjdk.org/jdk/pull/26375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26375/head:pull/26375 PR: https://git.openjdk.org/jdk/pull/26375 From iklam at openjdk.org Wed Sep 10 04:16:07 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Sep 2025 04:16:07 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v6] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 18:57:16 GMT, Ashutosh Mehra wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: >> >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - @DanHeidinga comments -- added comments and asserts about the handling of enums >> - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase >> - @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run >> - @DanHeidinga comments >> - tightened SystemDictionary::preload_class() >> - Fixed bugs found in JCK >> - added entry in ProblemList-AotJdk.txt due to 8323727 >> - more clean up >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - ... and 10 more: https://git.openjdk.org/jdk/compare/075ddef8...1a8ea501 > > src/hotspot/share/cds/aotOopChecker.cpp line 53: > >> 51: // the production run. >> 52: void AOTOopChecker::check(oop obj) { >> 53: precond(vmClasses::URL_klass()->is_final()); > > `AOTOopChecker::check` is a generic method, so this precond should ideally be inside the next block that explicitly handles URL class objects. I moved this line inside the next block. I also added comments that in the future we may check more types of objects. > src/hotspot/share/cds/aotOopChecker.cpp line 55: > >> 53: precond(vmClasses::URL_klass()->is_final()); >> 54: >> 55: if (obj->klass()->is_subclass_of(vmClasses::URL_klass())) { > > URL is a final class, so shouldn't `obj->klass() == vmClasses::URL_klass()` be sufficient? Since the `precond` is now inside this block, I can't use `==` anymore. Othewise if we had an instance of a subclass of URL then we will never get into the `if` block. > src/hotspot/share/classfile/javaClasses.cpp line 1063: > >> 1061: >> 1062: // Statically allocate fixup lists because they always get created. >> 1063: void java_lang_Class::allocate_fixup_lists() { > > Do we need `fixup_module_field_list` when `is_using_preloaded_classes` is true? I've added comments why fixup_module_field_list is not needed when is_using_preloaded_classes is true? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2335499266 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2335499303 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2335499362 From iklam at openjdk.org Wed Sep 10 04:16:10 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Sep 2025 04:16:10 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v7] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 16:46:13 GMT, Ashutosh Mehra wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: >> >> - @ashu-mehra review comments >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - @DanHeidinga comments -- added comments and asserts about the handling of enums >> - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase >> - @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run >> - @DanHeidinga comments >> - tightened SystemDictionary::preload_class() >> - Fixed bugs found in JCK >> - added entry in ProblemList-AotJdk.txt due to 8323727 >> - ... and 12 more: https://git.openjdk.org/jdk/compare/8cd4e7d8...959a2c91 > > src/hotspot/share/memory/iterator.inline.hpp line 58: > >> 56: ClaimMetadataVisitingOopIterateClosure::do_cld(cld); >> 57: } else { >> 58: assert(AOTLinkedClassBulkLoader::is_pending_aot_linked_class(k), "sanity"); > > Why is the null check and assert not valid anymore? The AOT cache can have heap objects whose class are loaded by the platform/app loaders. These objects usually come from aot-linked Lambda expressions. Before this PR, the platform/app classes are loaded after executing quite a bit of Java code (i.e.,module graph initialization). It's possible for a GC to happen and discover those heap objects, whose classes are not yet loaded (i.e., having a null `cld`). After this PR, all boot/platform/app classes are loaded before GC can happen, so we will never run into such null `cld` anymore. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2335499472 From djelinski at openjdk.org Wed Sep 10 06:08:21 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 10 Sep 2025 06:08:21 GMT Subject: RFR: 8366984: Remove delay slot support [v3] In-Reply-To: References: Message-ID: <_tx-ASKQdoHNnXSOi30eyjBgbDtsMY_WaoRPNuqrX80=.f65d62bd-dd4a-448b-b466-f76ca8d01112@github.com> On Wed, 10 Sep 2025 01:03:57 GMT, Dean Long wrote: >> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: >> >> - Merge remote-tracking branch 'origin/master' into delay-slot >> - Revert scope_desc change, breaks macos-aarch64 >> - Remove remaining comments >> - Update copyright >> - Remove commented out code >> - Remove unused variables >> - Comment out unused _unconditional_delay_slot >> - Remove bundle flags >> - Remove delay slot support from ADL >> - Clean up delay slot remnants from arm32 code >> - ... and 4 more: https://git.openjdk.org/jdk/compare/cc6d34b2...fb68b5a8 > > src/hotspot/share/runtime/sharedRuntime.cpp line 3505: > >> 3503: nm = cb->as_nmethod(); >> 3504: method = nm->method(); >> 3505: for (ScopeDesc *sd = nm->scope_desc_near(fr.pc()); sd != nullptr; sd = sd->sender()) { > > It's tempting to try to change this to scope_desc_at(), but also slightly risky if SPARC isn't the only reason it was needed. Should we investigate this in a separate RFE? [I tried](https://github.com/djelinski/jdk/actions/runs/17495967429) before I posted this PR. Apparently scope_desc_near is also needed on macosx-aarch64: # Internal Error (nmethod.cpp:668), pid=11090, tid=43267 # guarantee(pd != nullptr) failed: scope must be present ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27119#discussion_r2335651132 From djelinski at openjdk.org Wed Sep 10 06:19:29 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 10 Sep 2025 06:19:29 GMT Subject: RFR: 8366984: Remove delay slot support In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 10:56:04 GMT, Emanuel Peter wrote: >> SPARC was the only supported architecture that uses a delay slot. The SPARC port was removed in JDK 15, and the code is effectively dead. Let's remove it. >> >> The changes are no-op on all architectures that do not use delay slots. I still tested tier 1-5 on mach5, no related failures. > > Thanks for the answers! > > You'll of course have to merge the dependency, and get a second review :) Thanks @eme64 and @dean-long for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27119#issuecomment-3273459678 From djelinski at openjdk.org Wed Sep 10 06:19:30 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 10 Sep 2025 06:19:30 GMT Subject: Integrated: 8366984: Remove delay slot support In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 14:24:50 GMT, Daniel Jeli?ski wrote: > SPARC was the only supported architecture that uses a delay slot. The SPARC port was removed in JDK 15, and the code is effectively dead. Let's remove it. > > The changes are no-op on all architectures that do not use delay slots. I still tested tier 1-5 on mach5, no related failures. This pull request has now been integrated. Changeset: b7b01d6f Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/b7b01d6f564ae34e913ae51bd2f8243a32807136 Stats: 456 lines in 19 files changed: 1 ins; 407 del; 48 mod 8366984: Remove delay slot support Reviewed-by: dlong, epeter ------------- PR: https://git.openjdk.org/jdk/pull/27119 From dholmes at openjdk.org Wed Sep 10 07:04:16 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 10 Sep 2025 07:04:16 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands [v3] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 17:19:23 GMT, Kerem Kat wrote: >> Prevents segmentation faults during `gdb` sessions. The crashes were caused by the `ResourceMark` constructor being called on a native thread, which is not supported. This happened when invoking debug commands that require a `Thread` or `JavaThread` context from an incorrect thread type. >> >> ### Solution >> >> This change introduces `onThread()` and `onJavaThread()` helper methods to the `Command` class. These methods validate the thread context and ensure `ResourceMark` is only created when on a valid VM thread. All thread-dependent debug commands now use these guards to validate the context, printing a clear error and exiting gracefully upon failure. >> >> ### Testing >> >> Manually verified using `gdb` by calling the modified commands (`ps`, `universe`, `pns`, etc.) from different thread contexts (native, Java, and non-java threads) to ensure they fail gracefully with an error message instead of crashing the debug session. > > Kerem Kat has updated the pull request incrementally with two additional commits since the last revision: > > - refine comment > - remove redundant proto for findpc Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27033#pullrequestreview-3204700666 From mbaesken at openjdk.org Wed Sep 10 07:14:21 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 10 Sep 2025 07:14:21 GMT Subject: RFR: 8367051: Build failure with clang on linux and AIX after switch to C++17 In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 16:44:45 GMT, Julian Waters wrote: > Seems like a good reminder for me to resume working on that static analyzer as soon as possible. What static analyzer you are referring to ? We support now the gcc static analyzer in OpenJDK ( https://bugs.openjdk.org/browse/JDK-8362516 ) but probably you mean something different. (there is also a static code analyzer in clang named scan-build https://clang.llvm.org/docs/analyzer/user-docs/CommandLineUsage.html#scan-build which has some pros compared to the gcc static analyzer like C++ support and 'nice' html code result generation; but on the other hand it seemed to me that it generates even more false positive findings compared to the GCC static analyzer) . ------------- PR Comment: https://git.openjdk.org/jdk/pull/27154#issuecomment-3273622697 From dholmes at openjdk.org Wed Sep 10 07:22:11 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 10 Sep 2025 07:22:11 GMT Subject: RFR: 8367282: FORBID_C_FUNCTION needs exception spec consistent with library declaration In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 02:58:31 GMT, Kim Barrett wrote: > Please review this change to FORBID_C_FUNCTION to make the exception specs of > the forbidding declarations match up with the exception specs of the > associated library declarations. This needs to account for different platform > libraries either having or not having exception specs. It's needed because, > after switching to C++17, some compilers complain about some differences in > the exception specs. > > Also removed the workaround for JDK-8367051, which should no longer be needed > after this change. > > Hoping someone will test the aix-ppc port. @MBaesken or @TheRealMDoerr ? > > Testing: mach5 tier1, GHA sanity checks (nearly finished) > Locally (linux-aarch64) built with clang, which failed without the JDK-8367051 > workaround. Seems reasonable. Thanks for getting this sorted out. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27180#pullrequestreview-3204782962 From dholmes at openjdk.org Wed Sep 10 07:31:19 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 10 Sep 2025 07:31:19 GMT Subject: RFR: 8367142: Simplify java mirror handling in JNI methods [v2] In-Reply-To: References: <30w65N-VMzjkn9Tpy6cXrKz2F-gyoGSyCMpzLc2H8HI=.82760ff5-84b2-4adb-897e-ee8f94be6dad@github.com> Message-ID: On Tue, 9 Sep 2025 22:10:19 GMT, Ioi Lam wrote: > Arguably the translation of Java mirrors to Klasses is also a boundary (from Java representation to VM representation) :-) The mirror is an oop, both oop and kklass are internal VM representations. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27158#issuecomment-3273683492 From kbarrett at openjdk.org Wed Sep 10 07:34:09 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 10 Sep 2025 07:34:09 GMT Subject: RFR: 8367014: Rename class Atomic to AtomicAccess [v2] In-Reply-To: References: Message-ID: <8HMzxvTwZd1uSZCs528eM4pHsJVeKmFGtplElc8vXpk=.643b3706-7af2-40aa-835c-c3f8a785dd0e@github.com> > Please review this change that renames the all-static class `Atomic` to > `AtomicAccess`. The reason for this name change is to allow the introduction > of the new type `Atomic` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)). > > The PR has several commits, according to the specific category of change being > made. It may be easier to review the PR by studying these individual commits. > > Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose > to not rename the various "atomic_.*" and "atomic__.*" files. > > There are a number of comments containing the word "Atomic" that I didn't > change. They are generically about atomic operations, and will just as well > serve as referring to the future `Atomic`. > > Testing: mach5 tier1, GHA sanity tests. > This is one of those changes where successful builds indicate the change is good. Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - rename recently added Atomic:: => AtomicAccess:: - Merge branch 'master' into atomic-access - fix prefiously missed arg misalignments - rename test_atomic.cpp - update copyrights - misc cleanups - fix indentation from rename - rename Atomic => AtomicAccess in gtests - rename Atomic => AtomicAccess - change includes of atomic.hpp in gtests - ... and 2 more: https://git.openjdk.org/jdk/compare/af9b9050...11007c45 ------------- Changes: https://git.openjdk.org/jdk/pull/27135/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27135&range=01 Stats: 5577 lines in 430 files changed: 1587 ins; 1585 del; 2405 mod Patch: https://git.openjdk.org/jdk/pull/27135.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27135/head:pull/27135 PR: https://git.openjdk.org/jdk/pull/27135 From kbarrett at openjdk.org Wed Sep 10 07:34:11 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 10 Sep 2025 07:34:11 GMT Subject: RFR: 8367014: Rename class Atomic to AtomicAccess [v2] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 11:49:26 GMT, Stefan Karlsson wrote: > > Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose > > to not rename the various "atomic_." and "atomic__." files. > > Could you motivate why you chose to not do that? I thought about it, and waffled back and forth. But I was trying to do as much as possible of this change mechanically. Renaming a file involves multiple steps that weren't all easily scriptable. (And I'd already messed up a part of the renaming of atomic.hpp during patch development.) Also, this change is going to be hard for backports as it is, and I think renamings might make that worse. Renamings can also be annoying for archeology. But if you think it's important... > src/hotspot/os_cpu/bsd_x86/atomic_bsd_x86.hpp line 43: > >> 41: template<> >> 42: template >> 43: inline D AtomicAccess::PlatformAdd<4>::fetch_then_add(D volatile* dest, I add_value, > > This file has multiple alignment issues. Oops, completely missed that file. Will fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27135#issuecomment-3273667707 PR Review Comment: https://git.openjdk.org/jdk/pull/27135#discussion_r2335809380 From kbarrett at openjdk.org Wed Sep 10 07:34:12 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 10 Sep 2025 07:34:12 GMT Subject: RFR: 8367014: Rename class Atomic to AtomicAccess In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 06:26:03 GMT, Kim Barrett wrote: > Please review this change that renames the all-static class `Atomic` to > `AtomicAccess`. The reason for this name change is to allow the introduction > of the new type `Atomic` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)). > > The PR has several commits, according to the specific category of change being > made. It may be easier to review the PR by studying these individual commits. > > Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose > to not rename the various "atomic_.*" and "atomic__.*" files. > > There are a number of comments containing the word "Atomic" that I didn't > change. They are generically about atomic operations, and will just as well > serve as referring to the future `Atomic`. > > Testing: mach5 tier1, GHA sanity tests. > This is one of those changes where successful builds indicate the change is good. Updated for recent commits adding some new uses of `Atomic::` and merge conflicts. Running GHA sanity tests. mach5 tier1 already passed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27135#issuecomment-3273675624 From fyang at openjdk.org Wed Sep 10 07:35:02 2025 From: fyang at openjdk.org (Fei Yang) Date: Wed, 10 Sep 2025 07:35:02 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 09:09:49 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * sort includes Just FYI: My local tier1-tier3 tests on linux-riscv64 platform are still good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3273695581 From aph at openjdk.org Wed Sep 10 07:43:37 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 10 Sep 2025 07:43:37 GMT Subject: RFR: 8367014: Rename class Atomic to AtomicAccess [v2] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 07:23:58 GMT, Kim Barrett wrote: > Also, this change is > going to be hard for backports as it is, and I think renamings might make that > worse. Renamings can also be annoying for archeology. Speaking as an archaeologist and the lead of multiple backport projects, I agree with you, Kim. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27135#issuecomment-3273724381 From mbaesken at openjdk.org Wed Sep 10 07:54:38 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 10 Sep 2025 07:54:38 GMT Subject: RFR: 8367282: FORBID_C_FUNCTION needs exception spec consistent with library declaration In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 02:58:31 GMT, Kim Barrett wrote: > Please review this change to FORBID_C_FUNCTION to make the exception specs of > the forbidding declarations match up with the exception specs of the > associated library declarations. This needs to account for different platform > libraries either having or not having exception specs. It's needed because, > after switching to C++17, some compilers complain about some differences in > the exception specs. > > Also removed the workaround for JDK-8367051, which should no longer be needed > after this change. > > Hoping someone will test the aix-ppc port. @MBaesken or @TheRealMDoerr ? > > Testing: mach5 tier1, GHA sanity checks (nearly finished) > Locally (linux-aarch64) built with clang, which failed without the JDK-8367051 > workaround. src/hotspot/share/utilities/compilerWarnings.hpp line 147: > 145: FORBID_C_FUNCTION(FORBIDDEN_FUNCTION_IMPORT_SPEC Signature, Noexcept, Alternative) > 146: > 147: #define FORBID_NORETURN_C_FUNCTION(Signature, Noexcept, Alternative) \ Is the added whitespace after ')' intended ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27180#discussion_r2335886801 From tschatzl at openjdk.org Wed Sep 10 07:56:42 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 07:56:42 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits: - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * iwalulya: remove confusing comment - * sort includes - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * improve logging for refinement, making it similar to marking logging - * commit merge changes - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * fix merge error - * forgot to actually save the files - Merge branch 'master' into 8342382-card-table-instead-of-dcq - ... and 64 more: https://git.openjdk.org/jdk/compare/9e3fa321...e7c3a067 ------------- Changes: https://git.openjdk.org/jdk/pull/23739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=54 Stats: 7114 lines in 112 files changed: 2590 ins; 3583 del; 941 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From tschatzl at openjdk.org Wed Sep 10 07:56:44 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 07:56:44 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 09:47:10 GMT, Thomas Schatzl wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * sort includes > > We would like to finally wrap up this PR as we are about to Propose To Target [JEP 522](openjdk.org/jeps/522) to JDK 26, so it would be nice to get re-reviews from the reviewers that already signed it off if you think it is useful. > > Nothing much changed actually for months now, particularly in the area of target-specific support, but maybe one more rerun on the more exotic platforms (AIX/PPC, RISC-V) just in case would be fine. > > Internally it went through Oracle's tier1-8 without any issue again (that is revision https://github.com/openjdk/jdk/pull/23739/commits/b3873d66cd43518d5dc71e060fc52a13372dbfa5, but the changes since then were very cosmetic). > Hi @tschatzl : I witnessed some conflicts when applying this on latest jdk head. Maybe you can do another merge and rebase? I can help rerun the tests on RISC-V. (Note that there is one failing test: `test/hotspot/jtreg/gtest/GTestWrapper.java` if I use the same base as in your repo, and that issue has been resolved by [JDK-8366897](https://bugs.openjdk.org/browse/JDK-8366897)) Merged. Thanks for another round of testing (also to @TheRealMDoerr). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3273765120 From aph at openjdk.org Wed Sep 10 07:57:57 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 10 Sep 2025 07:57:57 GMT Subject: RFR: 8365606: Container code should not be using jlong/julong In-Reply-To: References: Message-ID: <9Q0zeMerc02tsMHodwMj4NQmOfBZ3bjk6_3IbZA2OvI=.7b139285-01bd-48cd-9991-26c27360cdbe@github.com> On Tue, 9 Sep 2025 09:49:00 GMT, Severin Gehwolf wrote: > > On some 32-bit systems this PR moves memory sizes from 64 bits, where they can't overflow, to 32 bits, where they can. While I've looked at this carefully, I can't exclude the possibility that overflow may occur. > > While we could pick through every change line by line, wouldn't it be safer simply to stay with 64-bit sizes on all systems? > > I agree. It's a valid concern. But this PR is basically an extension to [JDK-8357086](https://bugs.openjdk.org/browse/JDK-8357086). That one is already in JDK 26. `size_t` isn't a problem because it can't overflow, but `ssize_t` is a problem. Integer overflow is undefined behaviour . >It's also worth noting that 32-bit support is [on its way out](https://mail.openjdk.org/pipermail/jdk-dev/2025-April/009909.html). Sure, but that's no reason to introduce risky code to 32-bit systems. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27125#issuecomment-3273771257 From mbaesken at openjdk.org Wed Sep 10 08:21:45 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 10 Sep 2025 08:21:45 GMT Subject: RFR: 8367282: FORBID_C_FUNCTION needs exception spec consistent with library declaration In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 02:58:31 GMT, Kim Barrett wrote: > Please review this change to FORBID_C_FUNCTION to make the exception specs of > the forbidding declarations match up with the exception specs of the > associated library declarations. This needs to account for different platform > libraries either having or not having exception specs. It's needed because, > after switching to C++17, some compilers complain about some differences in > the exception specs. > > Also removed the workaround for JDK-8367051, which should no longer be needed > after this change. > > Hoping someone will test the aix-ppc port. @MBaesken or @TheRealMDoerr ? > > Testing: mach5 tier1, GHA sanity checks (nearly finished) > Locally (linux-aarch64) built with clang, which failed without the JDK-8367051 > workaround. Bad news from AIX, with this patch included we get build errors like this === Output from failing command(s) repeated here === * For target hotspot_variant-server_libjvm_objs_sharedRuntimeTrans.o: In file included from /jdk/src/hotspot/share/runtime/sharedRuntimeTrans.cpp:26: In file included from /jdk/src/hotspot/share/runtime/interfaceSupport.inline.hpp:31: In file included from /jdk/src/hotspot/share/gc/shared/gc_globals.hpp:28: In file included from /jdk/src/hotspot/share/runtime/globals_shared.hpp:28: In file included from /jdk/src/hotspot/share/utilities/align.hpp:31: In file included from /jdk/src/hotspot/share/utilities/globalDefinitions.hpp:31: /jdk/src/hotspot/share/utilities/forbiddenFunctions.hpp:61:23: error: exception specification in declaration does not match previous declaration 61 | FORBID_C_FUNCTION(int sprintf(char*, const char*, ...), noexcept, "use os::snprintf"); | ^ /usr/include/stdio.h:325:12: note: previous declaration is here 325 | extern int sprintf(char *__restrict__, const char *__restrict__, ...); | ^ ------------- PR Comment: https://git.openjdk.org/jdk/pull/27180#issuecomment-3273852855 From tschatzl at openjdk.org Wed Sep 10 08:21:59 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 08:21:59 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 07:47:00 GMT, Emanuel Peter wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * sort includes > > test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestIRMatching.java line 1489: > >> 1487: @Test >> 1488: @IR(failOn = IRNode.ALLOC) >> 1489: @IR(counts = {IRNode.COUNTED_LOOP, ">1"}) // not fail > > Can you explain what led to the difference? Can you also set an upper bound? With the decreased complexity of the barrier, C2 started unrolling that loop. I do not know how to determine a bound here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2335959266 From mli at openjdk.org Wed Sep 10 08:22:51 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 10 Sep 2025 08:22:51 GMT Subject: RFR: 8367066: RISC-V: refine register selection in MacroAssembler:: decode_klass_not_null In-Reply-To: <3IR_MQMbCC6ixoANmfLZJl0ZXZVE7hmCvGxb5XP3c0s=.aaeda614-d986-483d-8d5a-756dbbe56441@github.com> References: <3Xne6ZyEvzrclfVRZbCQf-Hpd7Z09jNTkzAbGrUSAYo=.86349de3-67b2-4358-8ade-717472e4062f@github.com> <3IR_MQMbCC6ixoANmfLZJl0ZXZVE7hmCvGxb5XP3c0s=.aaeda614-d986-483d-8d5a-756dbbe56441@github.com> Message-ID: On Wed, 10 Sep 2025 00:30:31 GMT, Fei Yang wrote: > > I think we can further simplify the code in `decode_klass_not_null`, pleaes check the latest commit. Test running... > > Yes, the code now looks more simplified. Thanks. Thanks for reviewing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27138#issuecomment-3273855731 From mli at openjdk.org Wed Sep 10 08:22:54 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 10 Sep 2025 08:22:54 GMT Subject: RFR: 8367066: RISC-V: refine register selection in MacroAssembler:: decode_klass_not_null [v2] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 00:24:53 GMT, Fei Yang wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> refine > > src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 3423: > >> 3421: if (CompressedKlassPointers::shift() != 0) { >> 3422: // dst = (src << shift) + xbase >> 3423: shadd(dst, src, xbase, dst /* temporary, dst != xbase */, CompressedKlassPointers::shift()); > > Is it safer to turn the code comment into an assertion? It will trigger if people incorrectly sets `xbase`. > > assert_different_registers(dst, xbase); > // dst = (src << shift) + xbase > shadd(dst, src, xbase, dst, CompressedKlassPointers::shift()); In `shadd` when `tmp` (here we use dst as tmp) is used, there is already an assert there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27138#discussion_r2335956852 From epeter at openjdk.org Wed Sep 10 08:31:57 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 10 Sep 2025 08:31:57 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 08:19:15 GMT, Thomas Schatzl wrote: >> test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestIRMatching.java line 1489: >> >>> 1487: @Test >>> 1488: @IR(failOn = IRNode.ALLOC) >>> 1489: @IR(counts = {IRNode.COUNTED_LOOP, ">1"}) // not fail >> >> Can you explain what led to the difference? Can you also set an upper bound? > > With the decreased complexity of the barrier, C2 started unrolling that loop. I do not know how to determine a bound here. Is this going to be GC independent? What if the VM swaps to another GC ergonomically? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2335985122 From sgehwolf at openjdk.org Wed Sep 10 08:38:37 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 10 Sep 2025 08:38:37 GMT Subject: RFR: 8365606: Container code should not be using jlong/julong In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 17:24:58 GMT, Severin Gehwolf wrote: > Please review this refactoring to the container code in Hotspot to no longer use `jlong` and `julong`. Instead this patch proposes to move to `size_t` and `ssize_t` types. In a similar manner as was done with the `os::xxx` APIs in [JDK-8357086](https://bugs.openjdk.org/browse/JDK-8357086). With this patch the use of `OSCONTAINER_ERROR` (`-2`) is largely gone. It's not terribly useful to have to warrant the many special cases throughout the code. > > In this patch failure handling is being done by returning a boolean for success/failure of reading a value from the interface files. The notion of "not supported" is being folded into `-1` (unlimited for limit values, not supported for usage values). Note that the code already treated `-1` and `-2` similarly. The few cases where `-2` was actually used was in `VM.info` output or `hserr` files. Where `-2` was being treated as "not supported". However, file-reading errors would also fall into the `-2` bucket making the "not supported" case not 100% distinguishable either. The simplification here proposes to do away with `-2` (other than in traces) and fold it into the `-1` (unlimited) bucket as that's how the code has been handling those values (even prior to this patch). > > Testing: > - [x] GHA (tier1) > - [x] cgroup gtests and hotspot container tests on cgroup v1 and cgroup v2 (no regressions noted). > > Thoughts? Thanks. So what's the guidance here, then? Change `julong` usages to `size_t` and keep `jlong`. I could do that and the patch would be much smaller. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27125#issuecomment-3273913418 From jwaters at openjdk.org Wed Sep 10 08:41:43 2025 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 10 Sep 2025 08:41:43 GMT Subject: RFR: 8367051: Build failure with clang on linux and AIX after switch to C++17 In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 07:11:53 GMT, Matthias Baesken wrote: > > Seems like a good reminder for me to resume working on that static analyzer as soon as possible. > > What static analyzer you are referring to ? We support now the gcc static analyzer in OpenJDK ( https://bugs.openjdk.org/browse/JDK-8362516 ) but probably you mean something different. (there is also a static code analyzer in clang named scan-build https://clang.llvm.org/docs/analyzer/user-docs/CommandLineUsage.html#scan-build which has some pros compared to the gcc static analyzer like C++ support and 'nice' html code result generation; but on the other hand it seemed to me that it generates even more false positive findings compared to the GCC static analyzer) . I was halfway through writing a custom C++17 static analyzer for HotSpot that can enforce the HotSpot code style. The existing static analyzers in gcc and clang unfortunately don't seem to support things that we need (Like forbidding functions or the NULL macro). I got stuck on the Lexer and halted work on it for a while, so it'll probably be good if I could continue working on it soon. Another plus is that it might be able to enforce things that the compilers we use cannot (Like prohibiting certain C++ headers or how headers are included with angle brackets or quotes) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27154#issuecomment-3273929148 From aph at openjdk.org Wed Sep 10 08:45:13 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 10 Sep 2025 08:45:13 GMT Subject: RFR: 8365606: Container code should not be using jlong/julong In-Reply-To: References: Message-ID: <5UCZf6wXayokdMhprIaLW1d6rzF-WHIviYQ5rJNJvI4=.bdbe9cc5-5f12-4b36-9796-ae4f298bb496@github.com> On Wed, 10 Sep 2025 08:35:39 GMT, Severin Gehwolf wrote: > Thanks. So what's the guidance here, then? Change `julong` usages to `size_t` and keep `jlong`. I could do that and the patch would be much smaller. That would work well. It might also be possible to use `size_t` everywhere, which would be more internally consistent. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27125#issuecomment-3273943678 From stefank at openjdk.org Wed Sep 10 08:56:25 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 10 Sep 2025 08:56:25 GMT Subject: RFR: 8367014: Rename class Atomic to AtomicAccess [v2] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 07:23:58 GMT, Kim Barrett wrote: > > > Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose > > > to not rename the various "atomic_." and "atomic__." files. > > > > > > Could you motivate why you chose to not do that? > > I thought about it, and waffled back and forth. But I was trying to do as much as possible of this change mechanically. Renaming a file involves multiple steps that weren't all easily scriptable. (And I'd already messed up a part of the renaming of atomic.hpp during patch development.) Also, this change is going to be hard for backports as it is, and I think renamings might make that worse. Renamings can also be annoying for archeology. But if you think it's important... Sure, renames are annoying. I do think that it is bad to leave inconsistent names in a long-lived, evolving code base. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27135#issuecomment-3273979685 From chagedorn at openjdk.org Wed Sep 10 08:58:52 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 10 Sep 2025 08:58:52 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 08:28:26 GMT, Emanuel Peter wrote: >> With the decreased complexity of the barrier, C2 started unrolling that loop. I do not know how to determine a bound here. > > Is this going to be GC independent? What if the VM swaps to another GC ergonomically? The test runs with `vm.flagless`. But I suggest to just go with `>= 1` instead to be on the safe side. The purpose of this IR rule in the context of this test is really just that it does not fail and not about catching real issues/verifying the IR. If we still want to test the improved loop unrolling opportunities, I suggest to create a separate IR test for it, possibly in a separate RFE. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336052099 From stefank at openjdk.org Wed Sep 10 09:05:15 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 10 Sep 2025 09:05:15 GMT Subject: RFR: 8365606: Container code should not be using jlong/julong In-Reply-To: References: Message-ID: <8av3v_CrL40Rl2vJNuNk6WxZOXFNb7KmXVQOOj8fCWk=.41ef3a93-5790-403d-addc-067406202942@github.com> On Fri, 5 Sep 2025 17:24:58 GMT, Severin Gehwolf wrote: > Please review this refactoring to the container code in Hotspot to no longer use `jlong` and `julong`. Instead this patch proposes to move to `size_t` and `ssize_t` types. In a similar manner as was done with the `os::xxx` APIs in [JDK-8357086](https://bugs.openjdk.org/browse/JDK-8357086). With this patch the use of `OSCONTAINER_ERROR` (`-2`) is largely gone. It's not terribly useful to have to warrant the many special cases throughout the code. > > In this patch failure handling is being done by returning a boolean for success/failure of reading a value from the interface files. The notion of "not supported" is being folded into `-1` (unlimited for limit values, not supported for usage values). Note that the code already treated `-1` and `-2` similarly. The few cases where `-2` was actually used was in `VM.info` output or `hserr` files. Where `-2` was being treated as "not supported". However, file-reading errors would also fall into the `-2` bucket making the "not supported" case not 100% distinguishable either. The simplification here proposes to do away with `-2` (other than in traces) and fold it into the `-1` (unlimited) bucket as that's how the code has been handling those values (even prior to this patch). > > Testing: > - [x] GHA (tier1) > - [x] cgroup gtests and hotspot container tests on cgroup v1 and cgroup v2 (no regressions noted). > > Thoughts? Please don't keep jlong. I propose that you follow what was done in 8357086: Instead of returning one value that either holds the size value or the error, split it into two return values and make the error handling explicit. If there are cases where the function should return a limit and the container code imposes no limit, then I "think" returning `SIZE_MAX` is probably better than propagating a error code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27125#issuecomment-3274010496 From kevinw at openjdk.org Wed Sep 10 09:06:23 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 10 Sep 2025 09:06:23 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands [v3] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 17:19:23 GMT, Kerem Kat wrote: >> Prevents segmentation faults during `gdb` sessions. The crashes were caused by the `ResourceMark` constructor being called on a native thread, which is not supported. This happened when invoking debug commands that require a `Thread` or `JavaThread` context from an incorrect thread type. >> >> ### Solution >> >> This change introduces `onThread()` and `onJavaThread()` helper methods to the `Command` class. These methods validate the thread context and ensure `ResourceMark` is only created when on a valid VM thread. All thread-dependent debug commands now use these guards to validate the context, printing a clear error and exiting gracefully upon failure. >> >> ### Testing >> >> Manually verified using `gdb` by calling the modified commands (`ps`, `universe`, `pns`, etc.) from different thread contexts (native, Java, and non-java threads) to ensure they fail gracefully with an error message instead of crashing the debug session. > > Kerem Kat has updated the pull request incrementally with two additional commits since the last revision: > > - refine comment > - remove redundant proto for findpc I made the comment earlier about duplication, it seemed odd not to keep the command implementations simple, by putting the common Thread::active calls and checks in one place. But that doesn't need to hold this up, if everybody is happy, I do like the change. 8-) ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27033#pullrequestreview-3205186030 From ayang at openjdk.org Wed Sep 10 09:07:22 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 10 Sep 2025 09:07:22 GMT Subject: RFR: 8367149: Add ergonomic construction for creating ad-hoc VMErrorCallback In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 06:26:32 GMT, Axel Boldt-Christmas wrote: > Add a class OnVMError which uses the VMErrorCallback mechanism which is an ergonomic construction for creating ad-hoc VMErrorCallback which automatically calls the provided invocable f if a VM crash occurs within its lifetime. Can be used to instrument a build for more detailed contextual information gathering. Especially useful when hunting down intermittent bugs, or issues only reproducible in environments where access to a debugger is not readily available. Example use: > ```C++ > { > // Note the lambda is invoked after an error occurs within this thread, > // and during on_error's lifetime. If state prior to the crash is required, > // capture a copy of it first. > auto important_value = get_the_value(); > > OnVMError on_error([&](outputStream* st) { > // Dump the important bits. > st->print("Prior value: "); > important_value.print_on(st); > st->print("During crash: ") > get_the_value().print_on(st); > // Dump whole the whole state. > this->print_on(st); > }); > > // Sometimes doing a thing will crash the VM. > do_a_thing(); > } > > > C++17 class template argument deduction finally makes these sort of constructions ergonomic to use without the need for auto and helper construction methods. Minor comments/suggestions on the doc. src/hotspot/share/utilities/vmError.hpp line 254: > 252: }; > 253: > 254: // Ergonomic construction for creating ad-hoc VMErrorCallback which automatically Does `Ergonomic construction` have specific meanings in cpp/this context? If not, I wonder if `lightweight` is clearer, as it is less technical. src/hotspot/share/utilities/vmError.hpp line 278: > 276: > 277: // Sometimes doing a thing will crash the VM. > 278: do_a_thing(); // When VM crashes, the above lambda will be invoked and print relevant info. might_cause_vm_crash(); ------------- Marked as reviewed by ayang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27159#pullrequestreview-3205163906 PR Review Comment: https://git.openjdk.org/jdk/pull/27159#discussion_r2336080660 PR Review Comment: https://git.openjdk.org/jdk/pull/27159#discussion_r2336064339 From mli at openjdk.org Wed Sep 10 09:08:24 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 10 Sep 2025 09:08:24 GMT Subject: RFR: 8367137: RISC-V: Detect Zicboz block size via hwprobe [v4] In-Reply-To: References: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> Message-ID: On Wed, 10 Sep 2025 02:06:34 GMT, Dingli Zhang wrote: >> Hi, >> Can you help to review this patch? Thanks! >> >> We can extends RISC-V hwprobe support to include `RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`. >> The probed value is recorded in VM_Version::zicboz_block_size and then used to set the global CacheLineSize. >> This ensures correct usage of the Zicboz extension, as block zeroing instructions operate on cache-line granularity. >> >> FYI: https://docs.kernel.org/arch/riscv/hwprobe.html > > Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: > > Replace CacheLineSize with zicboz_block_size in block zeroing logic Hey, just curious, if you have the performance data comparison on some device before/after this patch, could you share it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27155#issuecomment-3274025077 From mli at openjdk.org Wed Sep 10 09:12:23 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 10 Sep 2025 09:12:23 GMT Subject: RFR: 8367137: RISC-V: Detect Zicboz block size via hwprobe [v4] In-Reply-To: References: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> Message-ID: On Wed, 10 Sep 2025 02:06:34 GMT, Dingli Zhang wrote: >> Hi, >> Can you help to review this patch? Thanks! >> >> We can extends RISC-V hwprobe support to include `RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`. >> The probed value is recorded in VM_Version::zicboz_block_size and then used to set the global CacheLineSize. >> This ensures correct usage of the Zicboz extension, as block zeroing instructions operate on cache-line granularity. >> >> FYI: https://docs.kernel.org/arch/riscv/hwprobe.html > > Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: > > Replace CacheLineSize with zicboz_block_size in block zeroing logic src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp line 91: > 89: #define RISCV_HWPROBE_MISALIGNED_UNSUPPORTED (4 << 0) > 90: #define RISCV_HWPROBE_MISALIGNED_MASK (7 << 0) > 91: #define RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE 6 better to have a new line. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27155#discussion_r2336094630 From mli at openjdk.org Wed Sep 10 09:19:17 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 10 Sep 2025 09:19:17 GMT Subject: RFR: 8367137: RISC-V: Detect Zicboz block size via hwprobe [v4] In-Reply-To: References: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> Message-ID: <9Q3MOfiubAso5aufX1U36IxiADiuDDnXgyyZNXXyw6k=.8ab7a896-0f6c-4bbe-8d05-38515bb4eb12@github.com> On Wed, 10 Sep 2025 02:06:34 GMT, Dingli Zhang wrote: >> Hi, >> Can you help to review this patch? Thanks! >> >> We can extends RISC-V hwprobe support to include `RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`. >> The probed value is recorded in VM_Version::zicboz_block_size and then used to set the global CacheLineSize. >> This ensures correct usage of the Zicboz extension, as block zeroing instructions operate on cache-line granularity. >> >> FYI: https://docs.kernel.org/arch/riscv/hwprobe.html > > Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: > > Replace CacheLineSize with zicboz_block_size in block zeroing logic src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 5877: > 5875: // > 5876: // NOTE: This is intended to be used in the zero_blocks() stub. If > 5877: // you want to use it elsewhere, note that cnt must be no less than zicboz block size. previous style is more readable, like: >= zicboz_block_size ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27155#discussion_r2336115597 From duke at openjdk.org Wed Sep 10 09:22:35 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Wed, 10 Sep 2025 09:22:35 GMT Subject: RFR: 8367320: Sort cpu/x86 includes Message-ID: Sort includes in `cpu/x86` using `SortIncludes.java`. I'm also removing a couple unnecessary ones. Passes `tier1` and `tier2`. ------------- Commit messages: - revert - sort Changes: https://git.openjdk.org/jdk/pull/27189/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27189&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367320 Stats: 107 lines in 40 files changed: 45 ins; 61 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27189.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27189/head:pull/27189 PR: https://git.openjdk.org/jdk/pull/27189 From amitkumar at openjdk.org Wed Sep 10 09:22:33 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 10 Sep 2025 09:22:33 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 07:53:15 GMT, Thomas Schatzl wrote: >> We would like to finally wrap up this PR as we are about to Propose To Target [JEP 522](openjdk.org/jeps/522) to JDK 26, so it would be nice to get re-reviews from the reviewers that already signed it off if you think it is useful. >> >> Nothing much changed actually for months now, particularly in the area of target-specific support, but maybe one more rerun on the more exotic platforms (AIX/PPC, RISC-V) just in case would be fine. >> >> Internally it went through Oracle's tier1-8 without any issue again (that is revision https://github.com/openjdk/jdk/pull/23739/commits/b3873d66cd43518d5dc71e060fc52a13372dbfa5, but the changes since then were very cosmetic). > >> Hi @tschatzl : I witnessed some conflicts when applying this on latest jdk head. Maybe you can do another merge and rebase? I can help rerun the tests on RISC-V. (Note that there is one failing test: `test/hotspot/jtreg/gtest/GTestWrapper.java` if I use the same base as in your repo, and that issue has been resolved by [JDK-8366897](https://bugs.openjdk.org/browse/JDK-8366897)) > > Merged. Thanks for another round of testing (also to @TheRealMDoerr). Hi @tschatzl, I see one build failure on s390x, # # A fatal error has been detected by the Java Runtime Environment: # # SIGILL (0x4) at pc=0x000003ffaad14a42, pid=1801882, tid=1801914 # # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.amit.jdk) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.amit.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-s390x) # Problematic frame: # V [libjvm.so+0x414a46] BarrierSetNMethod::set_guard_value(nmethod*, int, int)+0xfe # # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -F%F -- %E" (or dumping to /home/amit/jdk/make/core.1801882) I am working on this on priority, but just in case you want to merge it, I will open another issue and push the fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3274080889 From krk at openjdk.org Wed Sep 10 09:26:43 2025 From: krk at openjdk.org (Kerem Kat) Date: Wed, 10 Sep 2025 09:26:43 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands [v3] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 17:19:23 GMT, Kerem Kat wrote: >> Prevents segmentation faults during `gdb` sessions. The crashes were caused by the `ResourceMark` constructor being called on a native thread, which is not supported. This happened when invoking debug commands that require a `Thread` or `JavaThread` context from an incorrect thread type. >> >> ### Solution >> >> This change introduces `onThread()` and `onJavaThread()` helper methods to the `Command` class. These methods validate the thread context and ensure `ResourceMark` is only created when on a valid VM thread. All thread-dependent debug commands now use these guards to validate the context, printing a clear error and exiting gracefully upon failure. >> >> ### Testing >> >> Manually verified using `gdb` by calling the modified commands (`ps`, `universe`, `pns`, etc.) from different thread contexts (native, Java, and non-java threads) to ensure they fail gracefully with an error message instead of crashing the debug session. > > Kerem Kat has updated the pull request incrementally with two additional commits since the last revision: > > - refine comment > - remove redundant proto for findpc > TEST RESULT: Error. Program `/Users/runner/work/jdk/jdk/bundles/jdk/jdk-26.jdk/Contents/Home/bin/java' timed out (timeout set to 1200000ms, elapsed time including timeout handling was 1293937ms). unrelated failure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27033#issuecomment-3274097669 From duke at openjdk.org Wed Sep 10 09:30:53 2025 From: duke at openjdk.org (duke) Date: Wed, 10 Sep 2025 09:30:53 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands [v3] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 17:19:23 GMT, Kerem Kat wrote: >> Prevents segmentation faults during `gdb` sessions. The crashes were caused by the `ResourceMark` constructor being called on a native thread, which is not supported. This happened when invoking debug commands that require a `Thread` or `JavaThread` context from an incorrect thread type. >> >> ### Solution >> >> This change introduces `onThread()` and `onJavaThread()` helper methods to the `Command` class. These methods validate the thread context and ensure `ResourceMark` is only created when on a valid VM thread. All thread-dependent debug commands now use these guards to validate the context, printing a clear error and exiting gracefully upon failure. >> >> ### Testing >> >> Manually verified using `gdb` by calling the modified commands (`ps`, `universe`, `pns`, etc.) from different thread contexts (native, Java, and non-java threads) to ensure they fail gracefully with an error message instead of crashing the debug session. > > Kerem Kat has updated the pull request incrementally with two additional commits since the last revision: > > - refine comment > - remove redundant proto for findpc @krk Your change (at version d19470e74dd7d72f2dd7ea0642f11271e69c33ed) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27033#issuecomment-3274109301 From ayang at openjdk.org Wed Sep 10 09:36:37 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 10 Sep 2025 09:36:37 GMT Subject: RFR: 8367320: Sort cpu/x86 includes In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 09:17:07 GMT, Francesco Andreuzzi wrote: > Sort includes in `cpu/x86` using `SortIncludes.java`. I'm also removing a couple unnecessary ones. > > Passes `tier1` and `tier2`. src/hotspot/cpu/x86/continuationEntry_x86.inline.hpp line 29: > 27: > 28: #include "oops/method.inline.hpp" > 29: #include "runtime/continuationEntry.hpp" I believe this is the "corresponding .hpp" in "All .inline.hpp files should include their corresponding .hpp file as the first include line..." from the style-guide, so should be kept at the top. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27189#discussion_r2336167042 From aph at openjdk.org Wed Sep 10 09:36:49 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 10 Sep 2025 09:36:49 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 07:56:42 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits: > > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - * iwalulya: remove confusing comment > - * sort includes > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - * improve logging for refinement, making it similar to marking logging > - * commit merge changes > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - * fix merge error > - * forgot to actually save the files > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - ... and 64 more: https://git.openjdk.org/jdk/compare/9e3fa321...e7c3a067 src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp line 95: > 93: Label loop; > 94: Label next; > 95: const Register end = count; This aliasing of register names is tricky and confusing. A trap for maintainers, of the kind that people have fallen into already. src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp line 104: > 102: __ lsr(start, start, CardTable::card_shift()); > 103: __ lsr(end, end, CardTable::card_shift()); > 104: __ sub(count, end, start); // Number of bytes to mark Because `end` is inclusive, `count` here is the number of bytes to mark - 1. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336167617 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336164656 From stefank at openjdk.org Wed Sep 10 09:41:38 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 10 Sep 2025 09:41:38 GMT Subject: RFR: 8367142: Simplify java mirror handling in JNI methods [v2] In-Reply-To: References: <30w65N-VMzjkn9Tpy6cXrKz2F-gyoGSyCMpzLc2H8HI=.82760ff5-84b2-4adb-897e-ee8f94be6dad@github.com> Message-ID: On Tue, 9 Sep 2025 06:29:51 GMT, Ioi Lam wrote: > There are 54 cases where we call as_Klass(JNIHandles::resolve_non_null(x)), so I think it would be nice to have a way to write less code. I think you should deal with that by adding a helper function inside jni.cpp instead of extending the *Klass functions to take a jobject. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27158#issuecomment-3274150749 From sgehwolf at openjdk.org Wed Sep 10 09:42:36 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 10 Sep 2025 09:42:36 GMT Subject: RFR: 8365606: Container code should not be using jlong/julong In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 17:24:58 GMT, Severin Gehwolf wrote: > Please review this refactoring to the container code in Hotspot to no longer use `jlong` and `julong`. Instead this patch proposes to move to `size_t` and `ssize_t` types. In a similar manner as was done with the `os::xxx` APIs in [JDK-8357086](https://bugs.openjdk.org/browse/JDK-8357086). With this patch the use of `OSCONTAINER_ERROR` (`-2`) is largely gone. It's not terribly useful to have to warrant the many special cases throughout the code. > > In this patch failure handling is being done by returning a boolean for success/failure of reading a value from the interface files. The notion of "not supported" is being folded into `-1` (unlimited for limit values, not supported for usage values). Note that the code already treated `-1` and `-2` similarly. The few cases where `-2` was actually used was in `VM.info` output or `hserr` files. Where `-2` was being treated as "not supported". However, file-reading errors would also fall into the `-2` bucket making the "not supported" case not 100% distinguishable either. The simplification here proposes to do away with `-2` (other than in traces) and fold it into the `-1` (unlimited) bucket as that's how the code has been handling those values (even prior to this patch). > > Testing: > - [x] GHA (tier1) > - [x] cgroup gtests and hotspot container tests on cgroup v1 and cgroup v2 (no regressions noted). > > Thoughts? OK. Back to the drawing board. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27125#issuecomment-3274152867 From duke at openjdk.org Wed Sep 10 09:52:21 2025 From: duke at openjdk.org (snake66) Date: Wed, 10 Sep 2025 09:52:21 GMT Subject: RFR: 8367282: FORBID_C_FUNCTION needs exception spec consistent with library declaration In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 02:58:31 GMT, Kim Barrett wrote: > Please review this change to FORBID_C_FUNCTION to make the exception specs of > the forbidding declarations match up with the exception specs of the > associated library declarations. This needs to account for different platform > libraries either having or not having exception specs. It's needed because, > after switching to C++17, some compilers complain about some differences in > the exception specs. > > Also removed the workaround for JDK-8367051, which should no longer be needed > after this change. > > Hoping someone will test the aix-ppc port. @MBaesken or @TheRealMDoerr ? > > Testing: mach5 tier1, GHA sanity checks (nearly finished) > Locally (linux-aarch64) built with clang, which failed without the JDK-8367051 > workaround. Tested and found to work on FreeBSD Aarch64 (with all my still out-of-tree patches applied.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27180#issuecomment-3274191739 From dnsimon at openjdk.org Wed Sep 10 10:02:25 2025 From: dnsimon at openjdk.org (Doug Simon) Date: Wed, 10 Sep 2025 10:02:25 GMT Subject: RFR: 8292818: replace 96-bit representation for field metadata with variable-sized streams [v7] In-Reply-To: References: Message-ID: On Fri, 17 Mar 2023 15:58:35 GMT, Frederic Parain wrote: >> Please review this change re-implementing the FieldInfo data structure. >> >> The FieldInfo array is an old data structure storing fields metadata. It has poor extension capabilities, a complex management code because of lack of strong typing and semantic overloading, and a poor memory efficiency. >> >> The new implementation uses a compressed stream to store those metadata, achieving better memory density and providing flexible extensibility, while exposing a strongly typed set of data when uncompressed. The stream is compressed using the unsigned5 encoding, which alreay present in the JDK (because of pack200) and the JVM (because JIT compulers use it to comrpess debugging information). >> >> More technical details are available in the CR: https://bugs.openjdk.org/browse/JDK-8292818 >> >> Those changes include a re-organisation of fields' flags, splitting the previous heterogeneous AccessFlags field into three distincts flag categories: immutable flags from the class file, immutable fields defined by the JVM, and finally mutable flags defined by the JVM. >> >> The SA, CI, and JVMCI, which all used to access the old FieldInfo array, have been updated too to deal with the new FieldInfo format. >> >> Tested with mach5, tier 1 to 7. >> >> Thank you. > > Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: > > - Style fixes > - Merge remote-tracking branch 'upstream/master' into fieldinfo_unsigned5 > - Style fixes > - SA and JVMCI fixes > - Fixes includes and style > - SA additional caching from Chris Plummer > - Addressing comments from first reviews > - Merge remote-tracking branch 'upstream/master' into fieldinfo_unsigned5 > - Reimplementation of FieldInfo as an unsigned5 stream One side-effect of this change is that verifying certain old classes (think JCK) can take a long time. For example: Test.java: import java.lang.classfile.ClassFile; import java.lang.constant.ClassDesc; import static java.lang.constant.ConstantDescs.CD_int; public class Test { public static void main(String[] args) throws Exception { int numberOfFields = 65_000; ClassDesc classDesc = ClassDesc.of("ManyFieldsClass"); byte[] classfile = ClassFile.of().build(classDesc, classBuilder -> { int flags = ClassFile.ACC_STATIC | ClassFile.ACC_PUBLIC; classBuilder.withVersion(ClassFile.JAVA_5_VERSION, 0); classBuilder.withField("myField0", CD_int, flags); for (int i = 1; i < numberOfFields; i++) { classBuilder.withField("myField" + i, CD_int, flags); } }); ClassLoader cl = new ClassLoader() { @Override protected Class loadClass(String name, boolean resolve) throws ClassNotFoundException { if (name.equals("ManyFieldsClass")) { return defineClass(name, classfile, 0, classfile.length); } return super.loadClass(name, resolve); } }; long start = System.currentTimeMillis(); var c = Class.forName("ManyFieldsClass", true, cl); System.out.printf("took %,d ms to load %s%n", (System.currentTimeMillis() - start), c); } } > java Test.java took 19,854 ms to load class ManyFieldsClass Probably not worth worrying about - just wanted to point out something I hit while processing the JCK with Native Image. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12855#issuecomment-3274222505 From krk at openjdk.org Wed Sep 10 10:09:46 2025 From: krk at openjdk.org (Kerem Kat) Date: Wed, 10 Sep 2025 10:09:46 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands [v4] In-Reply-To: References: Message-ID: > Prevents segmentation faults during `gdb` sessions. The crashes were caused by the `ResourceMark` constructor being called on a native thread, which is not supported. This happened when invoking debug commands that require a `Thread` or `JavaThread` context from an incorrect thread type. > > ### Solution > > This change introduces `onThread()` and `onJavaThread()` helper methods to the `Command` class. These methods validate the thread context and ensure `ResourceMark` is only created when on a valid VM thread. All thread-dependent debug commands now use these guards to validate the context, printing a clear error and exiting gracefully upon failure. > > ### Testing > > Manually verified using `gdb` by calling the modified commands (`ps`, `universe`, `pns`, etc.) from different thread contexts (native, Java, and non-java threads) to ensure they fail gracefully with an error message instead of crashing the debug session. Kerem Kat 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 'master' into JDK-8366154 - refine comment - remove redundant proto for findpc - add include for global placement new - remove onJavaThread and check JavaThread::active null where needed - Update src/hotspot/share/utilities/debug.cpp Co-authored-by: Francesco Andreuzzi - 8366154: Validate thread type requirements in debug commands Prevent crashes when calling interactive debug commands from native or non-java threads. Add onThread() and onJavaThread() methods to the Command class to validate the current thread type. Update debug commands to use these checks, printing an error and exiting gracefully upon failure. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27033/files - new: https://git.openjdk.org/jdk/pull/27033/files/d19470e7..f75de4bd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27033&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27033&range=02-03 Stats: 23617 lines in 1156 files changed: 11615 ins; 7226 del; 4776 mod Patch: https://git.openjdk.org/jdk/pull/27033.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27033/head:pull/27033 PR: https://git.openjdk.org/jdk/pull/27033 From duke at openjdk.org Wed Sep 10 10:10:49 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Wed, 10 Sep 2025 10:10:49 GMT Subject: RFR: 8367320: Sort cpu/x86 includes In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 09:33:28 GMT, Albert Mingkun Yang wrote: >> Sort includes in `cpu/x86` using `SortIncludes.java`. I'm also removing a couple unnecessary ones. >> >> Passes `tier1` and `tier2`. > > src/hotspot/cpu/x86/continuationEntry_x86.inline.hpp line 29: > >> 27: >> 28: #include "oops/method.inline.hpp" >> 29: #include "runtime/continuationEntry.hpp" > > I believe this is the "corresponding .hpp" in "All .inline.hpp files should include their corresponding .hpp file as the first include line..." from the style-guide, so should be kept at the top. I see. There's already a `continuationEntry_x86.hpp` in `cpu/x86`, maybe the `#include "runtime/continuationEntry.hpp"` should go there instead, and `continuationEntry_x86.inline.hpp` should include `continuationEntry_x86.hpp`? This would solve the problem without requiring changes in `SortIncludes.java`, which is not very flexible in terms of the relation between the names of the `.hpp` file and the corresponding `.inline.hpp` : String nonInlineHpp = pathString.replace(".inline.hpp", ".hpp"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27189#discussion_r2336257257 From iwalulya at openjdk.org Wed Sep 10 10:19:42 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 10 Sep 2025 10:19:42 GMT Subject: RFR: 8366865: G1: Allocation GC Pauses Triggered after JVM has started shutdown Message-ID: Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. Testing: Tier 1-7 ------------- Commit messages: - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - space - remove debug logs - remove debug logs - log_cpu_time - init Changes: https://git.openjdk.org/jdk/pull/27190/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366865 Stats: 164 lines in 15 files changed: 96 ins; 62 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27190.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27190/head:pull/27190 PR: https://git.openjdk.org/jdk/pull/27190 From mdoerr at openjdk.org Wed Sep 10 10:21:30 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 10 Sep 2025 10:21:30 GMT Subject: RFR: 8367282: FORBID_C_FUNCTION needs exception spec consistent with library declaration In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 02:58:31 GMT, Kim Barrett wrote: > Please review this change to FORBID_C_FUNCTION to make the exception specs of > the forbidding declarations match up with the exception specs of the > associated library declarations. This needs to account for different platform > libraries either having or not having exception specs. It's needed because, > after switching to C++17, some compilers complain about some differences in > the exception specs. > > Also removed the workaround for JDK-8367051, which should no longer be needed > after this change. > > Hoping someone will test the aix-ppc port. @MBaesken or @TheRealMDoerr ? > > Testing: mach5 tier1, GHA sanity checks (nearly finished) > Locally (linux-aarch64) built with clang, which failed without the JDK-8367051 > workaround. AIX: forbiddenFunctions.hpp:61:23: error: exception specification in declaration does not match previous declaration 61 | FORBID_C_FUNCTION(int sprintf(char*, const char*, ...), noexcept, "use os::snprintf"); | ^ /usr/include/stdio.h:325:12: note: previous declaration is here 325 | extern int sprintf(char *__restrict__, const char *__restrict__, ...); | ^ ------------- PR Comment: https://git.openjdk.org/jdk/pull/27180#issuecomment-3274289565 From dholmes at openjdk.org Wed Sep 10 10:34:41 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 10 Sep 2025 10:34:41 GMT Subject: RFR: 8367142: Simplify java mirror handling in JNI methods [v2] In-Reply-To: References: Message-ID: <9KIc7fkGt1OyYGBjvqaE4PWdALnulp2hf1zNIT64lHo=.c7dc978f-9e0a-419c-883c-d0cf43ff9155@github.com> On Tue, 9 Sep 2025 22:09:06 GMT, Ioi Lam wrote: >> The purpose of this PR is to simplify JNI code and also to avoid unnecessary `InstanceKlass::cast()` calls. >> >> This PR is intended to be a strict clean-up that preserves existing behaviors. >> >> The following helper functions are added to simplify boilerplate code in JNI methods. >> >> >> static Klass* java_lang_Class::as_Klass(jobject java_class); >> static InstanceKlass* java_lang_Class::as_InstanceKlass(oop java_class); >> static InstanceKlass* java_lang_Class::as_InstanceKlass(jobject java_class); >> >> >> Note: >> >> Before this PR, we have both patterns: >> >> >> java_lang_Class::as_Klass(JNIHandles::resolve(cls)); >> java_lang_Class::as_Klass(JNIHandles::resolve_non_null(cls)); >> >> >> If `cls` is null, we would get an assert in both cases (`as_Klass()` requires a non-null input). Therefore, I am using `resolve_non_null()` in the `jobject` versions of `as_Klass()`. > > Ioi Lam 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 8367142-simplify-java-mirror-handling-in-jni-methods > - @dholmes-ora comments - remove class_to_verify_considering_redefinition() changes, to be done in separate PR > - more fixes > - tmp: Clean up java mirror handling in JNI methods Looks good. A couple of minor nits. Thanks src/hotspot/share/prims/jvm.cpp line 844: > 842: ResourceMark rm; > 843: const char * from_name = java_lang_Class::as_Klass(from)->external_name(); > 844: const char * to_name = java_lang_Class::as_Klass(result)->external_name(); Suggestion: const char* from_name = java_lang_Class::as_Klass(from)->external_name(); const char* to_name = java_lang_Class::as_Klass(result)->external_name(); pre-existing nit src/hotspot/share/prims/jvm.cpp line 910: > 908: > 909: InstanceKlass* lookup_k = java_lang_Class::as_InstanceKlass(lookup); > 910: // Lookup class must not be a primitive class (whose mirror null Klass*) Suggestion: // Lookup class must not be a primitive class (whose mirror is a null Klass*) src/hotspot/share/prims/jvm.cpp line 912: > 910: // Lookup class must not be a primitive class (whose mirror null Klass*) > 911: if (lookup_k == nullptr) { > 912: THROW_MSG_NULL(vmSymbols::java_lang_IllegalArgumentException(), "Lookup class is primitive"); This is a behavioural change. src/hotspot/share/prims/whitebox.cpp line 2166: > 2164: > 2165: WB_ENTRY(void, WB_LinkClass(JNIEnv* env, jobject wb, jclass clazz)) > 2166: Klass *k = java_lang_Class::as_Klass(clazz); Suggestion: Klass* k = java_lang_Class::as_Klass(clazz); src/hotspot/share/prims/whitebox.cpp line 2168: > 2166: Klass *k = java_lang_Class::as_Klass(clazz); > 2167: if (k->is_instance_klass()) { > 2168: InstanceKlass *ik = InstanceKlass::cast(k); Suggestion: InstanceKlass* ik = InstanceKlass::cast(k); ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27158#pullrequestreview-3205473716 PR Review Comment: https://git.openjdk.org/jdk/pull/27158#discussion_r2336277816 PR Review Comment: https://git.openjdk.org/jdk/pull/27158#discussion_r2336280699 PR Review Comment: https://git.openjdk.org/jdk/pull/27158#discussion_r2336282079 PR Review Comment: https://git.openjdk.org/jdk/pull/27158#discussion_r2336308779 PR Review Comment: https://git.openjdk.org/jdk/pull/27158#discussion_r2336309246 From amitkumar at openjdk.org Wed Sep 10 11:10:00 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 10 Sep 2025 11:10:00 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 07:53:15 GMT, Thomas Schatzl wrote: >> We would like to finally wrap up this PR as we are about to Propose To Target [JEP 522](openjdk.org/jeps/522) to JDK 26, so it would be nice to get re-reviews from the reviewers that already signed it off if you think it is useful. >> >> Nothing much changed actually for months now, particularly in the area of target-specific support, but maybe one more rerun on the more exotic platforms (AIX/PPC, RISC-V) just in case would be fine. >> >> Internally it went through Oracle's tier1-8 without any issue again (that is revision https://github.com/openjdk/jdk/pull/23739/commits/b3873d66cd43518d5dc71e060fc52a13372dbfa5, but the changes since then were very cosmetic). > >> Hi @tschatzl : I witnessed some conflicts when applying this on latest jdk head. Maybe you can do another merge and rebase? I can help rerun the tests on RISC-V. (Note that there is one failing test: `test/hotspot/jtreg/gtest/GTestWrapper.java` if I use the same base as in your repo, and that issue has been resolved by [JDK-8366897](https://bugs.openjdk.org/browse/JDK-8366897)) > > Merged. Thanks for another round of testing (also to @TheRealMDoerr). > Hi @tschatzl, I see one build failure on s390x, > > ``` > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGILL (0x4) at pc=0x000003ffaad14a42, pid=1801882, tid=1801914 > # > # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.amit.jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.amit.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-s390x) > # Problematic frame: > # V [libjvm.so+0x414a46] BarrierSetNMethod::set_guard_value(nmethod*, int, int)+0xfe > # > # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -F%F -- %E" (or dumping to /home/amit/jdk/make/core.1801882) > ``` > > I am working on this on priority, but just in case you want to merge it, I will open another issue and push the fix. Seems like build failure came from one change merged yesterday- https://github.com/openjdk/jdk/pull/26399, I am working on it and created https://bugs.openjdk.org/browse/JDK-8367325 ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3274462944 From rehn at openjdk.org Wed Sep 10 11:23:17 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 10 Sep 2025 11:23:17 GMT Subject: RFR: 8367137: RISC-V: Detect Zicboz block size via hwprobe [v4] In-Reply-To: References: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> Message-ID: <0wa_aFP_nZhSVjLlbt8RD6uwoMwzbzFPudKJEzeVBnM=.9bf50498-443d-4b4d-a33d-6942abba36ed@github.com> On Wed, 10 Sep 2025 02:06:34 GMT, Dingli Zhang wrote: >> Hi, >> Can you help to review this patch? Thanks! >> >> We can extends RISC-V hwprobe support to include `RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`. >> The probed value is recorded in VM_Version::zicboz_block_size and then used to set the global CacheLineSize. >> This ensures correct usage of the Zicboz extension, as block zeroing instructions operate on cache-line granularity. >> >> FYI: https://docs.kernel.org/arch/riscv/hwprobe.html > > Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: > > Replace CacheLineSize with zicboz_block_size in block zeroing logic Seems reasonable and better than what we have considering how the specs could be implmented! ------------- Marked as reviewed by rehn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27155#pullrequestreview-3205688521 From tschatzl at openjdk.org Wed Sep 10 11:31:24 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 11:31:24 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 07:53:15 GMT, Thomas Schatzl wrote: >> We would like to finally wrap up this PR as we are about to Propose To Target [JEP 522](openjdk.org/jeps/522) to JDK 26, so it would be nice to get re-reviews from the reviewers that already signed it off if you think it is useful. >> >> Nothing much changed actually for months now, particularly in the area of target-specific support, but maybe one more rerun on the more exotic platforms (AIX/PPC, RISC-V) just in case would be fine. >> >> Internally it went through Oracle's tier1-8 without any issue again (that is revision https://github.com/openjdk/jdk/pull/23739/commits/b3873d66cd43518d5dc71e060fc52a13372dbfa5, but the changes since then were very cosmetic). > >> Hi @tschatzl : I witnessed some conflicts when applying this on latest jdk head. Maybe you can do another merge and rebase? I can help rerun the tests on RISC-V. (Note that there is one failing test: `test/hotspot/jtreg/gtest/GTestWrapper.java` if I use the same base as in your repo, and that issue has been resolved by [JDK-8366897](https://bugs.openjdk.org/browse/JDK-8366897)) > > Merged. Thanks for another round of testing (also to @TheRealMDoerr). > > Hi @tschatzl, I see one build failure on s390x, > > ``` > > # > > # A fatal error has been detected by the Java Runtime Environment: > > # > > # SIGILL (0x4) at pc=0x000003ffaad14a42, pid=1801882, tid=1801914 > > # > > # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.amit.jdk) > > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.amit.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-s390x) > > # Problematic frame: > > # V [libjvm.so+0x414a46] BarrierSetNMethod::set_guard_value(nmethod*, int, int)+0xfe [...] > > > > I am working on this on priority, but just in case you want to merge it, I will open another issue and push the fix. > > Seems like build failure came from one change merged yesterday- #26399, I am working on it and created https://bugs.openjdk.org/browse/JDK-8367325 This should definitely be caused by that other change. Apologies for the trouble. Thank you for working on this. Thomas ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3274535127 From tschatzl at openjdk.org Wed Sep 10 11:36:26 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 11:36:26 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v56] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 75 commits: - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * iwalulya: remove confusing comment - * sort includes - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * improve logging for refinement, making it similar to marking logging - * commit merge changes - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * fix merge error - * forgot to actually save the files - ... and 65 more: https://git.openjdk.org/jdk/compare/edae355e...de1469d6 ------------- Changes: https://git.openjdk.org/jdk/pull/23739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=55 Stats: 7114 lines in 112 files changed: 2590 ins; 3583 del; 941 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From tschatzl at openjdk.org Wed Sep 10 11:36:29 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 11:36:29 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 07:56:42 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits: > > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - * iwalulya: remove confusing comment > - * sort includes > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - * improve logging for refinement, making it similar to marking logging > - * commit merge changes > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - * fix merge error > - * forgot to actually save the files > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - ... and 64 more: https://git.openjdk.org/jdk/compare/9e3fa321...e7c3a067 That windows-x64 failure also seems to be an issue caused by another change merged in today :( Already fixed in [JDK-8367309](https://bugs.openjdk.org/browse/JDK-8367309). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3274545641 From coleenp at openjdk.org Wed Sep 10 11:44:29 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 10 Sep 2025 11:44:29 GMT Subject: RFR: 8367142: Simplify java mirror handling in JNI methods [v2] In-Reply-To: References: <30w65N-VMzjkn9Tpy6cXrKz2F-gyoGSyCMpzLc2H8HI=.82760ff5-84b2-4adb-897e-ee8f94be6dad@github.com> Message-ID: <4YATeT1_12Md5mCSr3ICRHSCfXBu0Ps4ha-rdMz4u_o=.a7bb56a2-b020-49cd-ad25-7618f9ec672e@github.com> On Wed, 10 Sep 2025 09:39:28 GMT, Stefan Karlsson wrote: >> There are 54 cases where we call as_Klass(JNIHandles::resolve_non_null(x)), so I think it would be nice to have a way to write less code. > I think you should deal with that by adding a helper function inside jni.cpp instead of extending the *Klass functions to take a jobject. I agree with this. I don't think you should move any more jobjects into the runtime code. The jobjects should stop at jni/jvm. They don't everywhere but that's something that over time we should fix. For instance, the ci creates jobjects but it should use OopHandles instead, except per-thread OopStorage isn't implemented yet. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27158#issuecomment-3274573970 From tschatzl at openjdk.org Wed Sep 10 11:44:30 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 11:44:30 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v57] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * aph review, fix some comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/de1469d6..d0ca9062 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=56 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=55-56 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From tschatzl at openjdk.org Wed Sep 10 11:44:34 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 11:44:34 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 09:33:42 GMT, Andrew Haley wrote: >> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits: >> >> - Merge branch 'master' into 8342382-card-table-instead-of-dcq >> - * iwalulya: remove confusing comment >> - * sort includes >> - Merge branch 'master' into 8342382-card-table-instead-of-dcq >> - * improve logging for refinement, making it similar to marking logging >> - * commit merge changes >> - Merge branch 'master' into 8342382-card-table-instead-of-dcq >> - * fix merge error >> - * forgot to actually save the files >> - Merge branch 'master' into 8342382-card-table-instead-of-dcq >> - ... and 64 more: https://git.openjdk.org/jdk/compare/9e3fa321...e7c3a067 > > src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp line 95: > >> 93: Label loop; >> 94: Label next; >> 95: const Register end = count; > > This aliasing of register names is tricky and confusing. A trap for maintainers, of the kind that people have fallen into already. I can argue I was following precedence :) I see your point though. What do you suggest to do here? Use `count` throughout instead? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336468727 From coleenp at openjdk.org Wed Sep 10 11:48:37 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 10 Sep 2025 11:48:37 GMT Subject: RFR: 8367142: Simplify java mirror handling in JNI methods [v2] In-Reply-To: References: Message-ID: <3-WDWqpmB2N5SCpzxV0IbpeluWxHBm6RhFE5mkuiiRw=.137799b4-9854-4719-ac9f-85de4937bff4@github.com> On Tue, 9 Sep 2025 22:09:06 GMT, Ioi Lam wrote: >> The purpose of this PR is to simplify JNI code and also to avoid unnecessary `InstanceKlass::cast()` calls. >> >> This PR is intended to be a strict clean-up that preserves existing behaviors. >> >> The following helper functions are added to simplify boilerplate code in JNI methods. >> >> >> static Klass* java_lang_Class::as_Klass(jobject java_class); >> static InstanceKlass* java_lang_Class::as_InstanceKlass(oop java_class); >> static InstanceKlass* java_lang_Class::as_InstanceKlass(jobject java_class); >> >> >> Note: >> >> Before this PR, we have both patterns: >> >> >> java_lang_Class::as_Klass(JNIHandles::resolve(cls)); >> java_lang_Class::as_Klass(JNIHandles::resolve_non_null(cls)); >> >> >> If `cls` is null, we would get an assert in both cases (`as_Klass()` requires a non-null input). Therefore, I am using `resolve_non_null()` in the `jobject` versions of `as_Klass()`. > > Ioi Lam 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 8367142-simplify-java-mirror-handling-in-jni-methods > - @dholmes-ora comments - remove class_to_verify_considering_redefinition() changes, to be done in separate PR > - more fixes > - tmp: Clean up java mirror handling in JNI methods jfr also is a boundary between Java -> Native code. That can have jobjects too, but resolve them before calling javaClasses. src/hotspot/share/classfile/javaClasses.hpp line 1905: > 1903: > 1904: > 1905: InstanceKlass* klass() const { return vmClasses::klass_at(klass_id); } Can you fix the indentation? src/hotspot/share/classfile/javaClasses.inline.hpp line 297: > 295: inline Klass* java_lang_Class::as_Klass(jobject java_class) { > 296: return as_Klass(JNIHandles::resolve_non_null(java_class)); > 297: } The JNIHandles shouldn't be imported to this file. The resolve should happen in the caller. src/hotspot/share/classfile/javaClasses.inline.hpp line 305: > 303: } > 304: > 305: inline InstanceKlass* java_lang_Class::as_InstanceKlass(jobject java_class) { Same here. ------------- Changes requested by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27158#pullrequestreview-3205765862 PR Review Comment: https://git.openjdk.org/jdk/pull/27158#discussion_r2336482267 PR Review Comment: https://git.openjdk.org/jdk/pull/27158#discussion_r2336483940 PR Review Comment: https://git.openjdk.org/jdk/pull/27158#discussion_r2336484858 From iwalulya at openjdk.org Wed Sep 10 12:03:42 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 10 Sep 2025 12:03:42 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v57] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 11:44:30 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * aph review, fix some comment Changes requested by iwalulya (Reviewer). src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp line 154: > 152: void assert_state(State expected); > 153: > 154: static void snapshot_heap_into(G1CardTableClaimTable* sweep_table); Any reason why this is static? Don't need to send `_sweep_table` as an argument if it wasn't static. ------------- PR Review: https://git.openjdk.org/jdk/pull/23739#pullrequestreview-3200132750 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336517161 From iwalulya at openjdk.org Wed Sep 10 12:03:47 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 10 Sep 2025 12:03:47 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 09:09:49 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * sort includes src/hotspot/share/gc/g1/g1Arguments.cpp line 250: > 248: // Verify that the maximum parallelism isn't too high to eventually overflow > 249: // the refcount in G1CardSetContainer. > 250: uint max_parallel_refinement_threads = G1ConcRefinementThreads; Don't need to local variable `max_parallel_refinement_threads` any more, can use G1ConcRefinementThreads directly. src/hotspot/share/gc/g1/g1CardTableClaimTable.inline.hpp line 95: > 93: i_card++; > 94: } > 95: assert(false, "should have early-returned"); maybe use `ShouldNotReachHere();` src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 216: > 214: class G1SwapThreadCardTableClosure : public HandshakeClosure { > 215: public: > 216: G1SwapThreadCardTableClosure() : HandshakeClosure("G1 Swap JT card table") { } Above on L206 we use "Refine Java Thread CT", here we use "Swap JT card table" not sure which is better "Java Thread CT" vs. "JT card table", but lets pick one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2332539864 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2332881834 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2333281435 From iwalulya at openjdk.org Wed Sep 10 12:03:51 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 10 Sep 2025 12:03:51 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 07:56:42 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits: > > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - * iwalulya: remove confusing comment > - * sort includes > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - * improve logging for refinement, making it similar to marking logging > - * commit merge changes > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - * fix merge error > - * forgot to actually save the files > - Merge branch 'master' into 8342382-card-table-instead-of-dcq > - ... and 64 more: https://git.openjdk.org/jdk/compare/9e3fa321...e7c3a067 src/hotspot/share/gc/g1/g1CardTableClaimTable.hpp line 43: > 41: // Claiming works on full region (all cards in region) or a range of contiguous cards > 42: // (chunk). Chunk size is given at construction time. > 43: class G1CardTableClaimTable : public CHeapObj { Do we need the `Table` in the `G1CardTableClaimTable` or can just calling it `G1CardTableClaimer` suffice? src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp line 301: > 299: // Indicate that last refinement adjustment had been deferred due to not > 300: // obtaining the heap lock. > 301: bool wait_for_heap_lock() const { return _heap_was_locked; } `wait_for_heap_lock()` does not do any waiting, maybe just maintain `heap_was_locked` as the method name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336340738 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336332933 From tschatzl at openjdk.org Wed Sep 10 12:21:33 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 12:21:33 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 10:44:20 GMT, Ivan Walulya wrote: >> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits: >> >> - Merge branch 'master' into 8342382-card-table-instead-of-dcq >> - * iwalulya: remove confusing comment >> - * sort includes >> - Merge branch 'master' into 8342382-card-table-instead-of-dcq >> - * improve logging for refinement, making it similar to marking logging >> - * commit merge changes >> - Merge branch 'master' into 8342382-card-table-instead-of-dcq >> - * fix merge error >> - * forgot to actually save the files >> - Merge branch 'master' into 8342382-card-table-instead-of-dcq >> - ... and 64 more: https://git.openjdk.org/jdk/compare/9e3fa321...e7c3a067 > > src/hotspot/share/gc/g1/g1CardTableClaimTable.hpp line 43: > >> 41: // Claiming works on full region (all cards in region) or a range of contiguous cards >> 42: // (chunk). Chunk size is given at construction time. >> 43: class G1CardTableClaimTable : public CHeapObj { > > Do we need the `Table` in the `G1CardTableClaimTable` or can just calling it `G1CardTableClaimer` suffice? This is the table the claimer below works on. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336568870 From mbaesken at openjdk.org Wed Sep 10 12:24:22 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 10 Sep 2025 12:24:22 GMT Subject: RFR: 8367282: FORBID_C_FUNCTION needs exception spec consistent with library declaration In-Reply-To: References: Message-ID: <7sJAFJWdrr4puSCJh8Fp4ihtuAK7q_BCvEy2oaruxNU=.8c94ec16-02af-4084-9364-6d3de0dd9294@github.com> On Wed, 10 Sep 2025 02:58:31 GMT, Kim Barrett wrote: > Please review this change to FORBID_C_FUNCTION to make the exception specs of > the forbidding declarations match up with the exception specs of the > associated library declarations. This needs to account for different platform > libraries either having or not having exception specs. It's needed because, > after switching to C++17, some compilers complain about some differences in > the exception specs. > > Also removed the workaround for JDK-8367051, which should no longer be needed > after this change. > > Hoping someone will test the aix-ppc port. @MBaesken or @TheRealMDoerr ? > > Testing: mach5 tier1, GHA sanity checks (nearly finished) > Locally (linux-aarch64) built with clang, which failed without the JDK-8367051 > workaround. Seems the forbidden sprintf AND snprintf cause the trouble on AIX, if I uncomment those 2 from forbiddenFunctions.hpp on top of this patch /* FORBID_C_FUNCTION(int sprintf(char*, const char*, ...), noexcept, "use os::snprintf"); FORBID_C_FUNCTION(int snprintf(char*, size_t, const char*, ...), noexcept, "use os::snprintf"); */ the rest of forbidden functions causes no trouble on AIX, the build is successful. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27180#issuecomment-3274707930 From eastigeevich at openjdk.org Wed Sep 10 12:37:22 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Wed, 10 Sep 2025 12:37:22 GMT Subject: RFR: 8277444: Data race between JvmtiClassFileReconstituter::copy_bytecodes and class linking [v6] In-Reply-To: <1bLI04thwsSz_j_sbfMJnHjEjQR1Soo6vupBws-vDcU=.6e6b27ee-8830-41c6-9034-652c60bc3179@github.com> References: <1bLI04thwsSz_j_sbfMJnHjEjQR1Soo6vupBws-vDcU=.6e6b27ee-8830-41c6-9034-652c60bc3179@github.com> Message-ID: On Fri, 5 Sep 2025 19:15:33 GMT, Evgeny Astigeevich wrote: >> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. >> >> This PR adds linking a class before the `copy_bytecodes` method is called. >> The PR also adds a regression test. >> >> Tested fastdebug and release builds: Linux x86_64 and arm64 >> - The reproducer from JDK-8277444 passed. >> - The regression test passed. >> - Tier1 - tier3 passed. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments Thank you, everyone, for reviewing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3274751129 From eastigeevich at openjdk.org Wed Sep 10 12:37:24 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Wed, 10 Sep 2025 12:37:24 GMT Subject: Integrated: 8277444: Data race between JvmtiClassFileReconstituter::copy_bytecodes and class linking In-Reply-To: References: Message-ID: <0TsdFhTcwe221khiTvBTl6JREmQdHtX6-usDKZFpIGM=.9904e049-35f5-4bd2-b95e-96d584e8c6d6@github.com> On Wed, 20 Aug 2025 15:36:14 GMT, Evgeny Astigeevich wrote: > There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`. `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode. > > This PR adds linking a class before the `copy_bytecodes` method is called. > The PR also adds a regression test. > > Tested fastdebug and release builds: Linux x86_64 and arm64 > - The reproducer from JDK-8277444 passed. > - The regression test passed. > - Tier1 - tier3 passed. This pull request has now been integrated. Changeset: 46ae1ee8 Author: Evgeny Astigeevich URL: https://git.openjdk.org/jdk/commit/46ae1ee87152742082e6047d0556944d7ae4567d Stats: 187 lines in 3 files changed: 186 ins; 0 del; 1 mod 8277444: Data race between JvmtiClassFileReconstituter::copy_bytecodes and class linking Reviewed-by: dholmes, amenkov, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/26863 From tschatzl at openjdk.org Wed Sep 10 12:40:11 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 12:40:11 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v58] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * walulyai review * tried to remove "logged card" terminology for the current "pending card" one ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/d0ca9062..b47c7b01 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=57 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=56-57 Stats: 55 lines in 11 files changed: 0 ins; 1 del; 54 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From epeter at openjdk.org Wed Sep 10 12:55:29 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 10 Sep 2025 12:55:29 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v54] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 08:53:13 GMT, Christian Hagedorn wrote: >> Is this going to be GC independent? What if the VM swaps to another GC ergonomically? > > The test runs with `vm.flagless`. But I suggest to just go with `>= 1` instead to be on the safe side. The purpose of this IR rule in the context of this test is really just that it does not fail and not about catching real issues/verifying the IR. > > If we still want to test the improved loop unrolling opportunities, I suggest to create a separate IR test for it, possibly in a separate RFE. I suppose that's probably not possible, as far as I know we always run with G1GC, so it should be fine :) We could put an upper bound of 3, maybe 4 here though. Just see what passes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336663260 From mdoerr at openjdk.org Wed Sep 10 13:33:20 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 10 Sep 2025 13:33:20 GMT Subject: RFR: 8334247: [PPC64] Consider trap based nmethod entry barriers [v5] In-Reply-To: References: Message-ID: > We can shrink nmethod entry barriers to 4 instructions (from 8) using conditional trap instructions. Some benchmarks seem to show very small improvements. At least the code size reduction is an advantage. Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier - Move nmethod entry barrier code up in the signal handler. - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier - 8334247: [PPC64] Consider trap based nmethod entry barriers ------------- Changes: https://git.openjdk.org/jdk/pull/24135/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24135&range=04 Stats: 67 lines in 8 files changed: 46 ins; 2 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/24135.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24135/head:pull/24135 PR: https://git.openjdk.org/jdk/pull/24135 From krk at openjdk.org Wed Sep 10 13:54:24 2025 From: krk at openjdk.org (Kerem Kat) Date: Wed, 10 Sep 2025 13:54:24 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands [v4] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 10:09:46 GMT, Kerem Kat wrote: >> Prevents segmentation faults during `gdb` sessions. The crashes were caused by the `ResourceMark` constructor being called on a native thread, which is not supported. This happened when invoking debug commands that require a `Thread` or `JavaThread` context from an incorrect thread type. >> >> ### Solution >> >> This change introduces `onThread()` and `onJavaThread()` helper methods to the `Command` class. These methods validate the thread context and ensure `ResourceMark` is only created when on a valid VM thread. All thread-dependent debug commands now use these guards to validate the context, printing a clear error and exiting gracefully upon failure. >> >> ### Testing >> >> Manually verified using `gdb` by calling the modified commands (`ps`, `universe`, `pns`, etc.) from different thread contexts (native, Java, and non-java threads) to ensure they fail gracefully with an error message instead of crashing the debug session. > > Kerem Kat 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 'master' into JDK-8366154 > - refine comment > - remove redundant proto for findpc > - add include for global placement new > - remove onJavaThread and check JavaThread::active null where needed > - Update src/hotspot/share/utilities/debug.cpp > > Co-authored-by: Francesco Andreuzzi > - 8366154: Validate thread type requirements in debug commands > > Prevent crashes when calling interactive debug commands from native > or non-java threads. > > Add onThread() and onJavaThread() methods to the Command class to > validate the current thread type. Update debug commands to use these > checks, printing an error and exiting gracefully upon failure. Unrelated macos failure: https://github.com/krk/jdk/actions/runs/17610297210/job/50032942937 Unpacking jdk bundle... jdk-26.jdk/Contents/Home/lib/server/libjvm.dylib: truncated gzip input ------------- PR Comment: https://git.openjdk.org/jdk/pull/27033#issuecomment-3275076434 From duke at openjdk.org Wed Sep 10 13:54:25 2025 From: duke at openjdk.org (duke) Date: Wed, 10 Sep 2025 13:54:25 GMT Subject: RFR: 8366154: Validate thread type requirements in debug commands [v4] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 10:09:46 GMT, Kerem Kat wrote: >> Prevents segmentation faults during `gdb` sessions. The crashes were caused by the `ResourceMark` constructor being called on a native thread, which is not supported. This happened when invoking debug commands that require a `Thread` or `JavaThread` context from an incorrect thread type. >> >> ### Solution >> >> This change introduces `onThread()` and `onJavaThread()` helper methods to the `Command` class. These methods validate the thread context and ensure `ResourceMark` is only created when on a valid VM thread. All thread-dependent debug commands now use these guards to validate the context, printing a clear error and exiting gracefully upon failure. >> >> ### Testing >> >> Manually verified using `gdb` by calling the modified commands (`ps`, `universe`, `pns`, etc.) from different thread contexts (native, Java, and non-java threads) to ensure they fail gracefully with an error message instead of crashing the debug session. > > Kerem Kat 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 'master' into JDK-8366154 > - refine comment > - remove redundant proto for findpc > - add include for global placement new > - remove onJavaThread and check JavaThread::active null where needed > - Update src/hotspot/share/utilities/debug.cpp > > Co-authored-by: Francesco Andreuzzi > - 8366154: Validate thread type requirements in debug commands > > Prevent crashes when calling interactive debug commands from native > or non-java threads. > > Add onThread() and onJavaThread() methods to the Command class to > validate the current thread type. Update debug commands to use these > checks, printing an error and exiting gracefully upon failure. @krk Your change (at version f75de4bd527da15b85d6ed4ecbabd7238410d148) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27033#issuecomment-3275082797 From ayang at openjdk.org Wed Sep 10 13:59:57 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 10 Sep 2025 13:59:57 GMT Subject: RFR: 8366865: G1: Allocation GC Pauses Triggered after JVM has started shutdown In-Reply-To: References: Message-ID: <04Lru322UkYz11DPPFo3alqoYCd7pSEsPSkpW4Z0_bQ=.d536246e-a5bb-4594-8966-52936927e117@github.com> On Wed, 10 Sep 2025 09:57:18 GMT, Ivan Walulya wrote: > Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. > > Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. > > Testing: Tier 1-7 The PR title shouldn't have `G1:` prefix, as it changes other GCs as well. src/hotspot/share/gc/shared/collectedHeap.cpp line 617: > 615: // To avoid returning nullptr (which could cause premature OOME), we stall > 616: // allocation requests here until the VM shutdown is complete. > 617: MonitorLocker ml(VMExit_lock); I wonder if an always-zero-`Semaphore` works. src/hotspot/share/gc/shared/gcVMOperations.cpp line 115: > 113: > 114: // Check invocations > 115: if (skip_operation() || Universe::heap()->is_shutting_down()) { Can the new condition be inlined inside `skip_operation()`? ------------- PR Review: https://git.openjdk.org/jdk/pull/27190#pullrequestreview-3206275122 PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2336838170 PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2336842785 From iwalulya at openjdk.org Wed Sep 10 13:59:58 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 10 Sep 2025 13:59:58 GMT Subject: RFR: 8366865: G1: Allocation GC Pauses Triggered after JVM has started shutdown In-Reply-To: <04Lru322UkYz11DPPFo3alqoYCd7pSEsPSkpW4Z0_bQ=.d536246e-a5bb-4594-8966-52936927e117@github.com> References: <04Lru322UkYz11DPPFo3alqoYCd7pSEsPSkpW4Z0_bQ=.d536246e-a5bb-4594-8966-52936927e117@github.com> Message-ID: On Wed, 10 Sep 2025 13:51:50 GMT, Albert Mingkun Yang wrote: >> Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. >> >> Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. >> >> Testing: Tier 1-7 > > src/hotspot/share/gc/shared/gcVMOperations.cpp line 115: > >> 113: >> 114: // Check invocations >> 115: if (skip_operation() || Universe::heap()->is_shutting_down()) { > > Can the new condition be inlined inside `skip_operation()`? In the first iteration I had it inlined, but then decided to make it more explicit. I can change it back if you prefer ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2336854910 From asteiner at openjdk.org Wed Sep 10 14:04:24 2025 From: asteiner at openjdk.org (Andreas Steiner) Date: Wed, 10 Sep 2025 14:04:24 GMT Subject: RFR: 8359104: gc/TestAlwaysPreTouchBehavior.java# fails on Linux Message-ID: Get accurate RSS, from smaps_rollup if available(Linux >= 4.14), because the RSS from status is inaccurate especially on systems with more than 32 CPUs. Not sure if all the additional meminfos like the Pss, Pss_dirty, Pss_Anon, Pss_File, Pss_Shmem, Swap and SwapPss are really needed too. But can be perhaps helpful too. As the inaccurate memory infos are still used in other methods: - [print_process_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2393) - [jfr_report_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2686) - [trim_native_heap()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L5376) one can think about to use the accurate values there too. ------------- Commit messages: - add accurate rss Changes: https://git.openjdk.org/jdk/pull/27192/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27192&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359104 Stats: 59 lines in 3 files changed: 55 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27192.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27192/head:pull/27192 PR: https://git.openjdk.org/jdk/pull/27192 From aboldtch at openjdk.org Wed Sep 10 14:17:42 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 10 Sep 2025 14:17:42 GMT Subject: RFR: 8367149: Add ergonomic construction for creating ad-hoc VMErrorCallback [v2] In-Reply-To: References: Message-ID: > Add a class OnVMError which uses the VMErrorCallback mechanism which is an ergonomic construction for creating ad-hoc VMErrorCallback which automatically calls the provided invocable f if a VM crash occurs within its lifetime. Can be used to instrument a build for more detailed contextual information gathering. Especially useful when hunting down intermittent bugs, or issues only reproducible in environments where access to a debugger is not readily available. Example use: > ```C++ > { > // Note the lambda is invoked after an error occurs within this thread, > // and during on_error's lifetime. If state prior to the crash is required, > // capture a copy of it first. > auto important_value = get_the_value(); > > OnVMError on_error([&](outputStream* st) { > // Dump the important bits. > st->print("Prior value: "); > important_value.print_on(st); > st->print("During crash: ") > get_the_value().print_on(st); > // Dump whole the whole state. > this->print_on(st); > }); > > // Sometimes doing a thing will crash the VM. > do_a_thing(); > } > > > C++17 class template argument deduction finally makes these sort of constructions ergonomic to use without the need for auto and helper construction methods. Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision: - Add a comment explaining the deduction rules - Skip multiple inheritance and allow more than lambda like callables. - Update doc example ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27159/files - new: https://git.openjdk.org/jdk/pull/27159/files/a4ab0e3e..a4fb3397 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27159&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27159&range=00-01 Stats: 18 lines in 1 file changed: 11 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27159.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27159/head:pull/27159 PR: https://git.openjdk.org/jdk/pull/27159 From asmehra at openjdk.org Wed Sep 10 14:22:44 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 10 Sep 2025 14:22:44 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v6] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 04:12:04 GMT, Ioi Lam wrote: >> src/hotspot/share/classfile/javaClasses.cpp line 1063: >> >>> 1061: >>> 1062: // Statically allocate fixup lists because they always get created. >>> 1063: void java_lang_Class::allocate_fixup_lists() { >> >> Do we need `fixup_module_field_list` when `is_using_preloaded_classes` is true? > > I've added comments why fixup_module_field_list is not needed when is_using_preloaded_classes is true? I was referring to `fixup_module_field_list`, but the comments are for `fixup_mirror_list`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2336936776 From duke at openjdk.org Wed Sep 10 14:35:42 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Wed, 10 Sep 2025 14:35:42 GMT Subject: RFR: 8359104: gc/TestAlwaysPreTouchBehavior.java# fails on Linux In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 13:55:59 GMT, Andreas Steiner wrote: > Get accurate RSS, from smaps_rollup if available(Linux >= 4.14), because the RSS from status is inaccurate especially on systems with more than 32 CPUs. > > Not sure if all the additional meminfos like the Pss, Pss_dirty, Pss_Anon, Pss_File, Pss_Shmem, Swap and SwapPss are really needed too. But can be perhaps helpful too. > > As the inaccurate memory infos are still used in other methods: > - [print_process_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2393) > - [jfr_report_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2686) > - [trim_native_heap()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L5376) > > one can think about to use the accurate values there too. src/hotspot/os/linux/os_linux.cpp line 2377: > 2375: bool os::Linux::query_accurate_process_memory_info(os::Linux::accurate_meminfo_t* info) { > 2376: FILE* f = os::fopen("/proc/self/smaps_rollup", "r"); > 2377: const int num_values = sizeof(os::Linux::accurate_meminfo_t) / sizeof(size_t); Should this and `num_found` be `size_t`? src/hotspot/os/linux/os_linux.cpp line 2382: > 2380: info->rss = info->pss = info->pssdirty = info->pssanon = > 2381: info->pssfile = info->pssshmem = info->swap = info->swappss = -1; > 2382: if (f != nullptr) { You could consider inverting this check, and early-return `false` if `f==nullptr`. That would spare one indentation level ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27192#discussion_r2336978504 PR Review Comment: https://git.openjdk.org/jdk/pull/27192#discussion_r2336975956 From krk at openjdk.org Wed Sep 10 14:39:07 2025 From: krk at openjdk.org (Kerem Kat) Date: Wed, 10 Sep 2025 14:39:07 GMT Subject: Integrated: 8366154: Validate thread type requirements in debug commands In-Reply-To: References: Message-ID: On Mon, 1 Sep 2025 11:36:21 GMT, Kerem Kat wrote: > Prevents segmentation faults during `gdb` sessions. The crashes were caused by the `ResourceMark` constructor being called on a native thread, which is not supported. This happened when invoking debug commands that require a `Thread` or `JavaThread` context from an incorrect thread type. > > ### Solution > > This change introduces `onThread()` and `onJavaThread()` helper methods to the `Command` class. These methods validate the thread context and ensure `ResourceMark` is only created when on a valid VM thread. All thread-dependent debug commands now use these guards to validate the context, printing a clear error and exiting gracefully upon failure. > > ### Testing > > Manually verified using `gdb` by calling the modified commands (`ps`, `universe`, `pns`, etc.) from different thread contexts (native, Java, and non-java threads) to ensure they fail gracefully with an error message instead of crashing the debug session. This pull request has now been integrated. Changeset: 5cd7721a Author: Kerem Kat Committer: Kevin Walls URL: https://git.openjdk.org/jdk/commit/5cd7721ad448cc4bdac37b0456252335f6b9d9f5 Stats: 70 lines in 1 file changed: 48 ins; 7 del; 15 mod 8366154: Validate thread type requirements in debug commands Reviewed-by: dholmes, simonis, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/27033 From mbaesken at openjdk.org Wed Sep 10 14:47:56 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 10 Sep 2025 14:47:56 GMT Subject: RFR: 8359104: gc/TestAlwaysPreTouchBehavior.java# fails on Linux In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 13:55:59 GMT, Andreas Steiner wrote: > Get accurate RSS, from smaps_rollup if available(Linux >= 4.14), because the RSS from status is inaccurate especially on systems with more than 32 CPUs. > > Not sure if all the additional meminfos like the Pss, Pss_dirty, Pss_Anon, Pss_File, Pss_Shmem, Swap and SwapPss are really needed too. But can be perhaps helpful too. > > As the inaccurate memory infos are still used in other methods: > - [print_process_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2393) > - [jfr_report_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2686) > - [trim_native_heap()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L5376) > > one can think about to use the accurate values there too. we use `size = info.rss * K;` for the calculation in `os::rss()` . But `os::Linux::query_accurate_process_memory_info ` returns true just in case the file could be opened , probably should we better check in a more detailed way e.g. at least that rss was found in /proc ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27192#issuecomment-3275309554 From duke at openjdk.org Wed Sep 10 14:50:21 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Wed, 10 Sep 2025 14:50:21 GMT Subject: RFR: 8367320: Sort cpu/x86 includes [v2] In-Reply-To: References: Message-ID: > Sort includes in `cpu/x86` using `SortIncludes.java`. I'm also removing a couple unnecessary ones. > > Passes `tier1` and `tier2`. Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: inline stuff ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27189/files - new: https://git.openjdk.org/jdk/pull/27189/files/30263b81..d7204d8f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27189&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27189&range=00-01 Stats: 5 lines in 2 files changed: 4 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27189.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27189/head:pull/27189 PR: https://git.openjdk.org/jdk/pull/27189 From duke at openjdk.org Wed Sep 10 14:50:23 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Wed, 10 Sep 2025 14:50:23 GMT Subject: RFR: 8367320: Sort cpu/x86 includes [v2] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 10:08:31 GMT, Francesco Andreuzzi wrote: >> src/hotspot/cpu/x86/continuationEntry_x86.inline.hpp line 29: >> >>> 27: >>> 28: #include "oops/method.inline.hpp" >>> 29: #include "runtime/continuationEntry.hpp" >> >> I believe this is the "corresponding .hpp" in "All .inline.hpp files should include their corresponding .hpp file as the first include line..." from the style-guide, so should be kept at the top. > > I see. There's already a `continuationEntry_x86.hpp` in `cpu/x86`, maybe the `#include "runtime/continuationEntry.hpp"` should go there instead, and `continuationEntry_x86.inline.hpp` should include `continuationEntry_x86.hpp`? > > This would solve the problem without requiring changes in `SortIncludes.java`, which is not very flexible in terms of the relation between the names of the `.hpp` file and the corresponding `.inline.hpp` : > > String nonInlineHpp = pathString.replace(".inline.hpp", ".hpp"); d7204d8f32399c9b437fbf83d9f66f068cc0a171 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27189#discussion_r2337020701 From asmehra at openjdk.org Wed Sep 10 14:52:31 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 10 Sep 2025 14:52:31 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v7] In-Reply-To: <8G1dsw-1ZWVIFcReoyb2Bt0lo28ObCu6eh-affuYWLU=.f00e92f7-6bea-4cb1-a287-9a18ca0fcee3@github.com> References: <8G1dsw-1ZWVIFcReoyb2Bt0lo28ObCu6eh-affuYWLU=.f00e92f7-6bea-4cb1-a287-9a18ca0fcee3@github.com> Message-ID: On Wed, 10 Sep 2025 04:16:03 GMT, Ioi Lam wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: > > - @ashu-mehra review comments > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - @DanHeidinga comments -- added comments and asserts about the handling of enums > - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase > - @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run > - @DanHeidinga comments > - tightened SystemDictionary::preload_class() > - Fixed bugs found in JCK > - added entry in ProblemList-AotJdk.txt due to 8323727 > - ... and 12 more: https://git.openjdk.org/jdk/compare/8cd4e7d8...959a2c91 src/hotspot/share/cds/filemap.cpp line 1861: > 1859: const char* archive_type = CDSConfig::type_of_archive_being_loaded(); > 1860: CDSConfig::set_has_aot_linked_classes(true); > 1861: if (is_static()) { `CDSConfig` is a global configuration, not specific to static or dynamic archive, and IIUC it is not possible to just load a dynamic archive, without loading a static archive. So it seems `is_static()` check is redundant here. Continuing with this line of thought, it seems if `has_aot_linked_classes` is true then `is_using_preloaded_classes` will also be true. Then why do we even need this additional flag to indicate preloading of classes? This is going to be the default behavior when `has_aot_linked_classes` is true. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2337020552 From asmehra at openjdk.org Wed Sep 10 14:52:33 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 10 Sep 2025 14:52:33 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v7] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 04:12:08 GMT, Ioi Lam wrote: >> src/hotspot/share/memory/iterator.inline.hpp line 58: >> >>> 56: ClaimMetadataVisitingOopIterateClosure::do_cld(cld); >>> 57: } else { >>> 58: assert(AOTLinkedClassBulkLoader::is_pending_aot_linked_class(k), "sanity"); >> >> Why is the null check and assert not valid anymore? > > The AOT cache can have heap objects whose class are loaded by the platform/app loaders. These objects usually come from aot-linked Lambda expressions. > > Before this PR, the platform/app classes are loaded after executing quite a bit of Java code (i.e.,module graph initialization). It's possible for a GC to happen and discover those heap objects, whose classes are not yet loaded (i.e., having a null `cld`). > > After this PR, all boot/platform/app classes are loaded before GC can happen, so we will never run into such null `cld` anymore. That makes `is_pending_aot_linked_class` dead code. Can it be removed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2337025501 From iwalulya at openjdk.org Wed Sep 10 14:54:29 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 10 Sep 2025 14:54:29 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v58] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 12:40:11 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * walulyai review > * tried to remove "logged card" terminology for the current "pending card" one src/hotspot/share/gc/g1/g1ConcurrentRefineThread.hpp line 36: > 34: class G1ConcurrentRefine; > 35: > 36: // Concurrent refinement control thread watching card mark accrual on the card Suggestion: // Concurrent refinement control thread watching card mark accrual on the card table src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp line 182: > 180: double _cur_optional_merge_heap_roots_time_ms; > 181: // Included in above merge and optional-merge time. > 182: double _cur_distribute_log_buffers_time_ms; No longer used. src/hotspot/share/gc/g1/g1HeapRegion.hpp line 41: > 39: class G1CardSet; > 40: class G1CardSetConfiguration; > 41: class G1CardTable; Do we need the Forward declaration here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336962845 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2336992289 PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2337004685 From tschatzl at openjdk.org Wed Sep 10 15:28:39 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 10 Sep 2025 15:28:39 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v59] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * walulyai review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/b47c7b01..c469c137 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=58 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=57-58 Stats: 9 lines in 3 files changed: 0 ins; 8 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From matsaave at openjdk.org Wed Sep 10 15:46:46 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 10 Sep 2025 15:46:46 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v9] In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 04:43:46 GMT, Ioi Lam wrote: >> During the assembly phase of the AOT cache, we link and verify all classes that were loaded during the training run. When verifying a class like this: >> >> >> class X { >> A getA() { return new B(); } // Verifier requires B to be a subtype of A. >> } >> >> >> We remember `A` and `B` as the "verification dependencies" of `X`. A class will be excluded from the AOT cache if any of its verification dependencies are excluded. For example, `X` will be excluded if >> >> - `A` fails verification >> - `B` is a signed class, which is always excluded from the AOT cache >> >> Conversely, if both `A` and `B` are included in the AOT cache, in the production run, they will be unconditionally loaded during VM bootstrap. Therefore, we can guarantee that the verification result computed for `X` will remain valid during the production run. >> >> Notes for reviewers: >> >> - The checks for verification dependencies are done inside `SystemDictionaryShared::check_exclusion_for_self_and_dependencies()`. These checks are done for both old and new classes. Since the dependencies can form a cyclic graph, the checks cannot be implemented with a simple recursion. See "Algorithm notes" in this function for details. >> - The verification dependencies for "new" classes are already stored in `DumpTimeClassInfo::_verifier_constraints`. >> - This PR adds code to record the verification dependencies for "old" classes into `DumpTimeClassInfo::_old_verifier_dependencies`, by intercepting `JVM_FindClassFromCaller()`. >> - This new functionality (store old classes in linked state) is available only when using the AOT cache. For simplicity, this functionality is not available with the old CDS workflows. See comments in `CDSConfig::is_preserving_verification_dependencies()`. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > updated comments The fixes and new comments look good! Thanks ------------- Marked as reviewed by matsaave (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26754#pullrequestreview-3206777458 From ayang at openjdk.org Wed Sep 10 15:50:38 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 10 Sep 2025 15:50:38 GMT Subject: RFR: 8367320: Sort cpu/x86 includes [v2] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 14:50:21 GMT, Francesco Andreuzzi wrote: >> Sort includes in `cpu/x86` using `SortIncludes.java`. I'm also removing a couple unnecessary ones. >> >> Passes `tier1` and `tier2`. > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > inline stuff src/hotspot/cpu/x86/continuationHelper_x86.inline.hpp line 29: > 27: > 28: #include "runtime/continuationEntry.inline.hpp" > 29: #include "runtime/continuationHelper.hpp" I think this is another case where the intention was that `continuationHelper.hpp` is the corresponding hpp and should be placed at the top. I wonder if the script should/can be revised a bit to recognize this pattern. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27189#discussion_r2337196317 From duke at openjdk.org Wed Sep 10 16:12:24 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Wed, 10 Sep 2025 16:12:24 GMT Subject: RFR: 8367320: Sort cpu/x86 includes [v2] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 15:47:59 GMT, Albert Mingkun Yang wrote: >> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: >> >> inline stuff > > src/hotspot/cpu/x86/continuationHelper_x86.inline.hpp line 29: > >> 27: >> 28: #include "runtime/continuationEntry.inline.hpp" >> 29: #include "runtime/continuationHelper.hpp" > > I think this is another case where the intention was that `continuationHelper.hpp` is the corresponding hpp and should be placed at the top. > > I wonder if the script should/can be revised a bit to recognize this pattern. I think the style guide should be changed too if we want to make this change: All .inline.hpp files should include their corresponding .hpp file as the first include line with a blank line separating it from the rest of the include lines. There should be some more details about what constitutes the "corresponding .hpp file". In the case of your [comment above](https://github.com/openjdk/jdk/pull/27189#discussion_r2336167042) in this PR, the `.inline.hpp` file had a clear "corresponding `.hpp` file", namely `continuationEntry_x86.hpp`. Should the style guide state something like "the corresponding `.hpp` file for a `inline.hpp` whose name contains some compilation flag-dependent qualifier, is either the `.hpp` file with the qualifier (if present) or the `.hpp` file without the qualifier as a fallback" ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27189#discussion_r2337246309 From stuefe at openjdk.org Wed Sep 10 16:15:37 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 10 Sep 2025 16:15:37 GMT Subject: RFR: 8360651: Create OSContainer API for memory limit [v2] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 17:54:10 GMT, Severin Gehwolf wrote: >> Please review this small addition to add a new `OSContainer::has_memory_limit()` API (Linux only - as with the entire OSContainer API) in preparation for [JDK-8350596](https://bugs.openjdk.org/browse/JDK-8350596) which proposes to increase the default `MaxRAMPercentage` when this new API returns true. The patch is pretty trivial. It's only the testing which amounts to the most lines in this patch. >> >> Testing: >> - [x] GHA >> - [x] Hotspot container tests on x86_64 Linux on cgroup v1 and cgroup v2 (including the new tests). >> >> Thoughts? > > Severin Gehwolf 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 four additional commits since the last revision: > > - Merge branch 'master' into jdk-8360651-mem-limit-api > - MemoryLimitTest whitespace fixes. > - TestContainerMemory whitespace fixes. > - 8360651: Create OSContainer API for memory limit Looks good to me. Is the copyright still correct? test/hotspot/jtreg/containers/docker/TestContainerMemory.java line 62: > 60: try { > 61: testWithMemoryLimit(); > 62: testWithoutMemoryLimit(); Just a remark, if you do these as separate tests (separate `@test` blocks), you can parallelize their execution and start them separately via jtreg command line if needed. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26020#pullrequestreview-3206870866 PR Review Comment: https://git.openjdk.org/jdk/pull/26020#discussion_r2337253290 From vaivanov at openjdk.org Wed Sep 10 16:19:33 2025 From: vaivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 10 Sep 2025 16:19:33 GMT Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays [v5] In-Reply-To: References: Message-ID: > On the SRF platform for runs with intrinsic scores for the ArrayFill test reports ~2x drop for several sizes due to a lot of the 'MEM_UOPS_RETIRED.SPLIT_STORES' events. The 'good' case for the ArraysFill.testCharFill with size=8195 reports numbers like > MEM_UOPS_RETIRED.SPLIT_LOADS | 22.6711 > MEM_UOPS_RETIRED.SPLIT_STORES | 4.0859 > while for 'bad' case these metrics are > MEM_UOPS_RETIRED.SPLIT_LOADS | 69.1785 > MEM_UOPS_RETIRED.SPLIT_STORES | 259200.3659 > > With alignment on the cache size no score drops due to split_stores but small reduction may be reported due to extra > SRF 6740E | Size | orig | pathed | pO/orig > -- | -- | -- | -- | -- > ArraysFill.testByteFill | 16 | 152031.2 | 157001.2 | 1.03 > ArraysFill.testByteFill | 31 | 125795.9 | 177399.2 | 1.41 > ArraysFill.testByteFill | 250 | 57961.69 | 120981.9 | 2.09 > ArraysFill.testByteFill | 266 | 44900.15 | 147893.8 | 3.29 > ArraysFill.testByteFill | 511 | 61908.17 | 129830.1 | 2.10 > ArraysFill.testByteFill | 2047 | 32255.51 | 41986.6 | 1.30 > ArraysFill.testByteFill | 2048 | 31928.97 | 42154.3 | 1.32 > ArraysFill.testByteFill | 8195 | 10690.15 | 11036.3 | 1.03 > ArraysFill.testIntFill | 16 | 145030.7 | 318796.9 | 2.20 > ArraysFill.testIntFill | 31 | 134138.4 | 212487 | 1.58 > ArraysFill.testIntFill | 250 | 74179.23 | 79522.66 | 1.07 > ArraysFill.testIntFill | 266 | 68112.72 | 60116.49 | 0.88 > ArraysFill.testIntFill | 511 | 39693.28 | 36225.09 | 0.91 > ArraysFill.testIntFill | 2047 | 11504.14 | 10616.91 | 0.92 > ArraysFill.testIntFill | 2048 | 11244.71 | 10969.14 | 0.98 > ArraysFill.testIntFill | 8195 | 2751.289 | 2692.216 | 0.98 > ArraysFill.testLongFill | 16 | 212532.5 | 212526 | 1.00 > ArraysFill.testLongFill | 31 | 137432.4 | 137283.3 | 1.00 > ArraysFill.testLongFill | 250 | 43185 | 43159.78 | 1.00 > ArraysFill.testLongFill | 266 | 42172.22 | 42170.5 | 1.00 > ArraysFill.testLongFill | 511 | 23370.15 | 23370.86 | 1.00 > ArraysFill.testLongFill | 2047 | 6123.008 | 6122.73 | 1.00 > ArraysFill.testLongFill | 2048 | 5793.722 | 5792.855 | 1.00 > ArraysFill.testLongFill | 8195 | 616.552 | 616.585 | 1.00 > ArraysFill.testShortFill | 16 | 152088.6 | 265646.1 | 1.75 > ArraysFill.testShortFill | 31 | 137369.8 | 185596.4 | 1.35 > ArraysFill.testShortFill | 250 | 58872.03 | 99621.15 | 1.69 > ArraysFill.testShortFill | 266 | 91085.31 | 93746.62 | 1.03 > ArraysFill.testShortFill | 511 | 65331.96 | 78003.83 | 1.19 > ArraysFill.testShortFill | 2047 | 21716.32 | 21216.81 | 0.98 > ArraysFill.testShortFill | 2048 | 21664.91 | 21328.72 | 0.98 > ArraysFill.testShortFill | 8195 | 5922.547 | ... Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26747/files - new: https://git.openjdk.org/jdk/pull/26747/files/a428899b..13c0fef6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26747&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26747&range=03-04 Stats: 22 lines in 1 file changed: 11 ins; 2 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/26747.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26747/head:pull/26747 PR: https://git.openjdk.org/jdk/pull/26747 From vaivanov at openjdk.org Wed Sep 10 16:25:19 2025 From: vaivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 10 Sep 2025 16:25:19 GMT Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays [v5] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 16:19:33 GMT, Vladimir Ivanov wrote: >> On the SRF platform for runs with intrinsic scores for the ArrayFill test reports ~2x drop for several sizes due to a lot of the 'MEM_UOPS_RETIRED.SPLIT_STORES' events. The 'good' case for the ArraysFill.testCharFill with size=8195 reports numbers like >> MEM_UOPS_RETIRED.SPLIT_LOADS | 22.6711 >> MEM_UOPS_RETIRED.SPLIT_STORES | 4.0859 >> while for 'bad' case these metrics are >> MEM_UOPS_RETIRED.SPLIT_LOADS | 69.1785 >> MEM_UOPS_RETIRED.SPLIT_STORES | 259200.3659 >> >> With alignment on the cache size no score drops due to split_stores but small reduction may be reported due to extra >> SRF 6740E | Size | orig | pathed | pO/orig >> -- | -- | -- | -- | -- >> ArraysFill.testByteFill | 16 | 152031.2 | 157001.2 | 1.03 >> ArraysFill.testByteFill | 31 | 125795.9 | 177399.2 | 1.41 >> ArraysFill.testByteFill | 250 | 57961.69 | 120981.9 | 2.09 >> ArraysFill.testByteFill | 266 | 44900.15 | 147893.8 | 3.29 >> ArraysFill.testByteFill | 511 | 61908.17 | 129830.1 | 2.10 >> ArraysFill.testByteFill | 2047 | 32255.51 | 41986.6 | 1.30 >> ArraysFill.testByteFill | 2048 | 31928.97 | 42154.3 | 1.32 >> ArraysFill.testByteFill | 8195 | 10690.15 | 11036.3 | 1.03 >> ArraysFill.testIntFill | 16 | 145030.7 | 318796.9 | 2.20 >> ArraysFill.testIntFill | 31 | 134138.4 | 212487 | 1.58 >> ArraysFill.testIntFill | 250 | 74179.23 | 79522.66 | 1.07 >> ArraysFill.testIntFill | 266 | 68112.72 | 60116.49 | 0.88 >> ArraysFill.testIntFill | 511 | 39693.28 | 36225.09 | 0.91 >> ArraysFill.testIntFill | 2047 | 11504.14 | 10616.91 | 0.92 >> ArraysFill.testIntFill | 2048 | 11244.71 | 10969.14 | 0.98 >> ArraysFill.testIntFill | 8195 | 2751.289 | 2692.216 | 0.98 >> ArraysFill.testLongFill | 16 | 212532.5 | 212526 | 1.00 >> ArraysFill.testLongFill | 31 | 137432.4 | 137283.3 | 1.00 >> ArraysFill.testLongFill | 250 | 43185 | 43159.78 | 1.00 >> ArraysFill.testLongFill | 266 | 42172.22 | 42170.5 | 1.00 >> ArraysFill.testLongFill | 511 | 23370.15 | 23370.86 | 1.00 >> ArraysFill.testLongFill | 2047 | 6123.008 | 6122.73 | 1.00 >> ArraysFill.testLongFill | 2048 | 5793.722 | 5792.855 | 1.00 >> ArraysFill.testLongFill | 8195 | 616.552 | 616.585 | 1.00 >> ArraysFill.testShortFill | 16 | 152088.6 | 265646.1 | 1.75 >> ArraysFill.testShortFill | 31 | 137369.8 | 185596.4 | 1.35 >> ArraysFill.testShortFill | 250 | 58872.03 | 99621.15 | 1.69 >> ArraysFill.testShortFill | 266 | 91085.31 | 93746.62 | 1.03 >> ArraysFill.testShortFill | 511 | 65331.96 | 78003.83 | 1.19 >> ArraysFill.testShortFill | 2047 | 21716.32 | 21216.81 | 0.98 >> ArraysFill.testShortFill... > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays The align cycle was updated to counted loop with alignment for 32 bytes (The main loop operates by 32 bytes values and 32bytes alignment enough to have no split_stores). Reported scores on the Xeon 6740E for the compiled version vs intrinsic are: SRF | size | jdk26, comp | patched | p/jdk_comp -- | -- | -- | -- | -- ArraysFill.testByteFill | 16 | 152077.563 | 168535.8 | 1.11 ArraysFill.testByteFill | 31 | 125702.057 | 212504.2 | 1.69 ArraysFill.testByteFill | 250 | 57965.263 | 127806.6 | 2.20 ArraysFill.testByteFill | 266 | 44901.157 | 145742 | 3.25 ArraysFill.testByteFill | 511 | 61918.237 | 109917.3 | 1.78 ArraysFill.testByteFill | 2047 | 32222.184 | 40348.55 | 1.25 ArraysFill.testByteFill | 2048 | 31930.607 | 35773.5 | 1.12 ArraysFill.testByteFill | 8195 | 10690.434 | 10709.71 | 1.00 ArraysFill.testIntFill | 16 | 144979.804 | 289781.8 | 2.00 ArraysFill.testIntFill | 31 | 133495.302 | 212475.7 | 1.59 ArraysFill.testIntFill | 250 | 74178.893 | 80775.39 | 1.09 ArraysFill.testIntFill | 266 | 68009.933 | 78090.68 | 1.15 ArraysFill.testIntFill | 511 | 39688.805 | 45553.15 | 1.15 ArraysFill.testIntFill | 2047 | 11504.203 | 11282.22 | 0.98 ArraysFill.testIntFill | 2048 | 11245.331 | 11512.12 | 1.02 ArraysFill.testIntFill | 8195 | 2692.649 | 2654.157 | 0.99 ArraysFill.testLongFill | 16 | 212541.769 | 212508.9 | 1.00 ArraysFill.testLongFill | 31 | 137729.599 | 137624.3 | 1.00 ArraysFill.testLongFill | 250 | 43162.979 | 43155.4 | 1.00 ArraysFill.testLongFill | 266 | 42173.88 | 42156.26 | 1.00 ArraysFill.testLongFill | 511 | 23364.859 | 23367.6 | 1.00 ArraysFill.testLongFill | 2047 | 6122.745 | 6123.296 | 1.00 ArraysFill.testLongFill | 2048 | 5792.552 | 5772.727 | 1.00 ArraysFill.testLongFill | 8195 | 616.62 | 616.257 | 1.00 ArraysFill.testShortFill | 16 | 152176.336 | 354182.7 | 2.33 ArraysFill.testShortFill | 31 | 137527.651 | 227688.8 | 1.66 ArraysFill.testShortFill | 250 | 58930.645 | 99614.52 | 1.69 ArraysFill.testShortFill | 266 | 91088.72 | 93755.19 | 1.03 ArraysFill.testShortFill | 511 | 65332.79 | 70824.73 | 1.08 ArraysFill.testShortFill | 2047 | 21713.296 | 22289.87 | 1.03 ArraysFill.testShortFill | 2048 | 21667.468 | 21021.92 | 0.97 ArraysFill.testShortFill | 8195 | 5922.318 | 5886.738 | 0.99 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26747#issuecomment-3275659629 From jsjolen at openjdk.org Wed Sep 10 16:41:05 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 10 Sep 2025 16:41:05 GMT Subject: RFR: 8367249: [REDO] MemBaseline accesses VMT without using lock In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 11:53:41 GMT, Johan Sj?len wrote: > Hi, > > This is a REDO, as the previous attempt caused build failures when merged with latest master. > The only difference is that the copy ctr for the RBTRee had been integrated with a different PR, but it never should have been. I deleted the copy ctr. > > Thanks. It's really weird that the linux-x64-static tests fail. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27170#issuecomment-3275707583 From iklam at openjdk.org Wed Sep 10 18:30:57 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Sep 2025 18:30:57 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v7] In-Reply-To: References: <8G1dsw-1ZWVIFcReoyb2Bt0lo28ObCu6eh-affuYWLU=.f00e92f7-6bea-4cb1-a287-9a18ca0fcee3@github.com> Message-ID: On Wed, 10 Sep 2025 14:47:19 GMT, Ashutosh Mehra wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: >> >> - @ashu-mehra review comments >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - @DanHeidinga comments -- added comments and asserts about the handling of enums >> - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase >> - @DanHeidinga comment -- assembly phase should check if URLStreamHandler might be overridden in the production run >> - @DanHeidinga comments >> - tightened SystemDictionary::preload_class() >> - Fixed bugs found in JCK >> - added entry in ProblemList-AotJdk.txt due to 8323727 >> - ... and 12 more: https://git.openjdk.org/jdk/compare/8cd4e7d8...959a2c91 > > src/hotspot/share/cds/filemap.cpp line 1861: > >> 1859: const char* archive_type = CDSConfig::type_of_archive_being_loaded(); >> 1860: CDSConfig::set_has_aot_linked_classes(true); >> 1861: if (is_static()) { > > `CDSConfig` is a global configuration, not specific to static or dynamic archive, and IIUC it is not possible to just load a dynamic archive, without loading a static archive. So it seems `is_static()` check is redundant here. > Continuing with this line of thought, it seems if `has_aot_linked_classes` is true then `is_using_preloaded_classes` will also be true. Then why do we even need this additional flag to indicate preloading of classes? This is going to be the default behavior when `has_aot_linked_classes` is true. There is actually a tricky situation -- static archive doesn't have `-XX:+AOTClassLinking` but the dynamic archive was created with `-XX:+AOTClassLinking`. I have created [JDK-8367366](https://bugs.openjdk.org/browse/JDK-8367366) to remove support for `-XX:+AOTClassLinking` for the dynamic archive. If that gets reviewed and integrated, then I will update this PR to remove `is_using_preloaded_classes()` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2337574998 From iklam at openjdk.org Wed Sep 10 18:30:58 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Sep 2025 18:30:58 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v6] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 14:19:33 GMT, Ashutosh Mehra wrote: >> I've added comments why fixup_module_field_list is not needed when is_using_preloaded_classes is true? > > I was referring to `fixup_module_field_list`, but the comments are for `fixup_mirror_list`. It's needed because of `-XX:+AOTClassLinking` in the dynamic archive. I will update this after removing `-XX:+AOTClassLinking` support for the dynamic archive in [JDK-8367366](https://bugs.openjdk.org/browse/JDK-8367366) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2337579397 From iklam at openjdk.org Wed Sep 10 19:24:12 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Sep 2025 19:24:12 GMT Subject: RFR: 8317269: Store old classes in linked state in AOT cache [v9] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 02:00:57 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> updated comments > > This is good. Thanks for all the comments and explanations. The tests look good, particularly the descriptive names of the test classes. Thanks @coleenp @matias9927 for the review I merged the repos locally and reran tiers 1-4, build tier 5 and AOT-JCK tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26754#issuecomment-3276226574 From iklam at openjdk.org Wed Sep 10 19:24:14 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Sep 2025 19:24:14 GMT Subject: Integrated: 8317269: Store old classes in linked state in AOT cache In-Reply-To: References: Message-ID: On Tue, 12 Aug 2025 23:55:19 GMT, Ioi Lam wrote: > During the assembly phase of the AOT cache, we link and verify all classes that were loaded during the training run. When verifying a class like this: > > > class X { > A getA() { return new B(); } // Verifier requires B to be a subtype of A. > } > > > We remember `A` and `B` as the "verification dependencies" of `X`. A class will be excluded from the AOT cache if any of its verification dependencies are excluded. For example, `X` will be excluded if > > - `A` fails verification > - `B` is a signed class, which is always excluded from the AOT cache > > Conversely, if both `A` and `B` are included in the AOT cache, in the production run, they will be unconditionally loaded during VM bootstrap. Therefore, we can guarantee that the verification result computed for `X` will remain valid during the production run. > > Notes for reviewers: > > - The checks for verification dependencies are done inside `SystemDictionaryShared::check_exclusion_for_self_and_dependencies()`. These checks are done for both old and new classes. Since the dependencies can form a cyclic graph, the checks cannot be implemented with a simple recursion. See "Algorithm notes" in this function for details. > - The verification dependencies for "new" classes are already stored in `DumpTimeClassInfo::_verifier_constraints`. > - This PR adds code to record the verification dependencies for "old" classes into `DumpTimeClassInfo::_old_verifier_dependencies`, by intercepting `JVM_FindClassFromCaller()`. > - This new functionality (store old classes in linked state) is available only when using the AOT cache. For simplicity, this functionality is not available with the old CDS workflows. See comments in `CDSConfig::is_preserving_verification_dependencies()`. This pull request has now been integrated. Changeset: 85715e10 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/85715e1050fa774c3267dbbe2f749717aeeec8ff Stats: 1405 lines in 35 files changed: 1311 ins; 22 del; 72 mod 8317269: Store old classes in linked state in AOT cache Reviewed-by: coleenp, matsaave ------------- PR: https://git.openjdk.org/jdk/pull/26754 From kbarrett at openjdk.org Wed Sep 10 20:22:26 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 10 Sep 2025 20:22:26 GMT Subject: RFR: 8367282: FORBID_C_FUNCTION needs exception spec consistent with library declaration In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 09:49:54 GMT, snake66 wrote: > Tested and found to work on FreeBSD Aarch64 (with all my still out-of-tree patches applied.) Thanks for checking that! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27180#issuecomment-3276371358 From kbarrett at openjdk.org Wed Sep 10 20:22:27 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 10 Sep 2025 20:22:27 GMT Subject: RFR: 8367282: FORBID_C_FUNCTION needs exception spec consistent with library declaration In-Reply-To: References: Message-ID: <7EWjV35Ol5rk_qd_5e2wGEV7d57EktFw-TxINe0AGvU=.f7224229-85fe-4de9-960a-7bc285a0a54a@github.com> On Wed, 10 Sep 2025 02:58:31 GMT, Kim Barrett wrote: > Please review this change to FORBID_C_FUNCTION to make the exception specs of > the forbidding declarations match up with the exception specs of the > associated library declarations. This needs to account for different platform > libraries either having or not having exception specs. It's needed because, > after switching to C++17, some compilers complain about some differences in > the exception specs. > > Also removed the workaround for JDK-8367051, which should no longer be needed > after this change. > > Hoping someone will test the aix-ppc port. @MBaesken or @TheRealMDoerr ? > > Testing: mach5 tier1, GHA sanity checks (nearly finished) > Locally (linux-aarch64) built with clang, which failed without the JDK-8367051 > workaround. > Seems the forbidden sprintf AND snprintf cause the trouble on AIX, [...] the rest of forbidden functions causes > no trouble on AIX, the build is successful. I was afraid something like this might turn up. I can hack around the sprintf/snprintf AIX issue. But I think the only reliable long-term solution might be to generate the forbidding declarations as part of the build process. That's more work than I want to do for this right now though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27180#issuecomment-3276379059 From kbarrett at openjdk.org Wed Sep 10 20:22:29 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 10 Sep 2025 20:22:29 GMT Subject: RFR: 8367282: FORBID_C_FUNCTION needs exception spec consistent with library declaration In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 07:52:01 GMT, Matthias Baesken wrote: >> Please review this change to FORBID_C_FUNCTION to make the exception specs of >> the forbidding declarations match up with the exception specs of the >> associated library declarations. This needs to account for different platform >> libraries either having or not having exception specs. It's needed because, >> after switching to C++17, some compilers complain about some differences in >> the exception specs. >> >> Also removed the workaround for JDK-8367051, which should no longer be needed >> after this change. >> >> Hoping someone will test the aix-ppc port. @MBaesken or @TheRealMDoerr ? >> >> Testing: mach5 tier1, GHA sanity checks (nearly finished) >> Locally (linux-aarch64) built with clang, which failed without the JDK-8367051 >> workaround. > > src/hotspot/share/utilities/compilerWarnings.hpp line 147: > >> 145: FORBID_C_FUNCTION(FORBIDDEN_FUNCTION_IMPORT_SPEC Signature, Noexcept, Alternative) >> 146: >> 147: #define FORBID_NORETURN_C_FUNCTION(Signature, Noexcept, Alternative) \ > > Is the added whitespace after ')' intended ? Thanks for noticing. Will fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27180#discussion_r2337805744 From coleenp at openjdk.org Wed Sep 10 21:56:25 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 10 Sep 2025 21:56:25 GMT Subject: RFR: 8367368: Add message for verify_legal_class_modifiers for inner classes Message-ID: This adds the inner class name (or unnamed) to the error message for invalid inner class modifiers. Testing with tier1-4. ------------- Commit messages: - Add message for verify_legal_class_modifiers for nested classes. - Add message for verify_legal_class_modifiers for nested classes. Changes: https://git.openjdk.org/jdk/pull/27201/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27201&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367368 Stats: 368 lines in 6 files changed: 358 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/27201.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27201/head:pull/27201 PR: https://git.openjdk.org/jdk/pull/27201 From iklam at openjdk.org Wed Sep 10 22:46:00 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Sep 2025 22:46:00 GMT Subject: RFR: 8367142: Simplify java mirror handling in JNI methods [v3] In-Reply-To: References: Message-ID: <3Xh3sS0I7pp0fslgQndt4CLqddxga7W8c11tuZkNgd8=.b5a28dba-05f1-49d9-80f8-6260a9772287@github.com> > The purpose of this PR is to simplify JNI code and also to avoid unnecessary `InstanceKlass::cast()` calls by adding a new function: > > > static InstanceKlass* java_lang_Class::as_InstanceKlass(oop java_class); > > > This PR is intended to be a strict clean-up that preserves existing behaviors. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Removed the (jobject) version of as_Klass/as_InstanceKlass ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27158/files - new: https://git.openjdk.org/jdk/pull/27158/files/d943d2fe..f8634eff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27158&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27158&range=01-02 Stats: 70 lines in 9 files changed: 4 ins; 13 del; 53 mod Patch: https://git.openjdk.org/jdk/pull/27158.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27158/head:pull/27158 PR: https://git.openjdk.org/jdk/pull/27158 From iklam at openjdk.org Wed Sep 10 22:50:30 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Sep 2025 22:50:30 GMT Subject: RFR: 8367142: Avoid InstanceKlass::cast when converting java mirror to InstanceKlass [v3] In-Reply-To: <3Xh3sS0I7pp0fslgQndt4CLqddxga7W8c11tuZkNgd8=.b5a28dba-05f1-49d9-80f8-6260a9772287@github.com> References: <3Xh3sS0I7pp0fslgQndt4CLqddxga7W8c11tuZkNgd8=.b5a28dba-05f1-49d9-80f8-6260a9772287@github.com> Message-ID: On Wed, 10 Sep 2025 22:46:00 GMT, Ioi Lam wrote: >> The purpose of this PR is to simplify JNI code and also to avoid unnecessary `InstanceKlass::cast()` calls by adding a new function: >> >> >> static InstanceKlass* java_lang_Class::as_InstanceKlass(oop java_class); >> >> >> This PR is intended to be a strict clean-up that preserves existing behaviors. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Removed the (jobject) version of as_Klass/as_InstanceKlass I didn't realize that my attempt to remove the `JNIHandles::resolve()` boilerplate can be conversional. I can't put a helper function in jni.cpp because this pattern is used in several files. I've reverted to the old code that makes the explicit calls to `JNIHandles::resolve()`. I updated the JBS issue text as this PR is now only for reducing the number of InstanceKlass::cast() calls. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27158#issuecomment-3276767203 From iklam at openjdk.org Wed Sep 10 22:50:33 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Sep 2025 22:50:33 GMT Subject: RFR: 8367142: Avoid InstanceKlass::cast when converting java mirror to InstanceKlass [v2] In-Reply-To: <3-WDWqpmB2N5SCpzxV0IbpeluWxHBm6RhFE5mkuiiRw=.137799b4-9854-4719-ac9f-85de4937bff4@github.com> References: <3-WDWqpmB2N5SCpzxV0IbpeluWxHBm6RhFE5mkuiiRw=.137799b4-9854-4719-ac9f-85de4937bff4@github.com> Message-ID: On Wed, 10 Sep 2025 11:43:33 GMT, Coleen Phillimore wrote: >> Ioi Lam 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 8367142-simplify-java-mirror-handling-in-jni-methods >> - @dholmes-ora comments - remove class_to_verify_considering_redefinition() changes, to be done in separate PR >> - more fixes >> - tmp: Clean up java mirror handling in JNI methods > > src/hotspot/share/classfile/javaClasses.hpp line 1905: > >> 1903: >> 1904: >> 1905: InstanceKlass* klass() const { return vmClasses::klass_at(klass_id); } > > Can you fix the indentation? I removed all indentation alignments from this class, as they no longer seem warranted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27158#discussion_r2338071887 From iklam at openjdk.org Wed Sep 10 22:54:44 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Sep 2025 22:54:44 GMT Subject: RFR: 8367142: Avoid InstanceKlass::cast when converting java mirror to InstanceKlass [v2] In-Reply-To: <9KIc7fkGt1OyYGBjvqaE4PWdALnulp2hf1zNIT64lHo=.c7dc978f-9e0a-419c-883c-d0cf43ff9155@github.com> References: <9KIc7fkGt1OyYGBjvqaE4PWdALnulp2hf1zNIT64lHo=.c7dc978f-9e0a-419c-883c-d0cf43ff9155@github.com> Message-ID: On Wed, 10 Sep 2025 10:18:45 GMT, David Holmes wrote: >> Ioi Lam 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 8367142-simplify-java-mirror-handling-in-jni-methods >> - @dholmes-ora comments - remove class_to_verify_considering_redefinition() changes, to be done in separate PR >> - more fixes >> - tmp: Clean up java mirror handling in JNI methods > > src/hotspot/share/prims/jvm.cpp line 912: > >> 910: // Lookup class must not be a primitive class (whose mirror null Klass*) >> 911: if (lookup_k == nullptr) { >> 912: THROW_MSG_NULL(vmSymbols::java_lang_IllegalArgumentException(), "Lookup class is primitive"); > > This is a behavioural change. I reverted the change to the error message. I don't know how we will ever get a primitive class in there and who would be reading the error message. I added a comment saying the error message is wrong, so people reading this code will not get confused. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27158#discussion_r2338076531 From dzhang at openjdk.org Thu Sep 11 00:04:13 2025 From: dzhang at openjdk.org (Dingli Zhang) Date: Thu, 11 Sep 2025 00:04:13 GMT Subject: RFR: 8367137: RISC-V: Detect Zicboz block size via hwprobe [v4] In-Reply-To: References: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> Message-ID: <_4riqp4f0YgofgxEDocHrCY_MoFeeiZCVD2yMu170nE=.f2610544-568c-4ecf-a7b0-9ac6723a98bc@github.com> On Wed, 10 Sep 2025 09:05:45 GMT, Hamlin Li wrote: > Hey, just curious, if you have the performance data comparison on some device before/after this patch, could you share it? Thanks for the review! Unfortunately, I don't have any performance data comparison. However, the latest change is a bugfix, not a performance optimization. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27155#issuecomment-3276917609 From dzhang at openjdk.org Thu Sep 11 00:11:34 2025 From: dzhang at openjdk.org (Dingli Zhang) Date: Thu, 11 Sep 2025 00:11:34 GMT Subject: RFR: 8367137: RISC-V: Detect Zicboz block size via hwprobe [v5] In-Reply-To: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> References: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> Message-ID: > Hi, > Can you help to review this patch? Thanks! > > We can extends RISC-V hwprobe support to include `RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`. > The probed value is recorded in VM_Version::zicboz_block_size and then used to set the global CacheLineSize. > This ensures correct usage of the Zicboz extension, as block zeroing instructions operate on cache-line granularity. > > FYI: https://docs.kernel.org/arch/riscv/hwprobe.html Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: Refine comments and formatting ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27155/files - new: https://git.openjdk.org/jdk/pull/27155/files/4fbbedde..5a167d6b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27155&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27155&range=03-04 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27155/head:pull/27155 PR: https://git.openjdk.org/jdk/pull/27155 From dzhang at openjdk.org Thu Sep 11 00:11:36 2025 From: dzhang at openjdk.org (Dingli Zhang) Date: Thu, 11 Sep 2025 00:11:36 GMT Subject: RFR: 8367137: RISC-V: Detect Zicboz block size via hwprobe [v4] In-Reply-To: <9Q3MOfiubAso5aufX1U36IxiADiuDDnXgyyZNXXyw6k=.8ab7a896-0f6c-4bbe-8d05-38515bb4eb12@github.com> References: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> <9Q3MOfiubAso5aufX1U36IxiADiuDDnXgyyZNXXyw6k=.8ab7a896-0f6c-4bbe-8d05-38515bb4eb12@github.com> Message-ID: On Wed, 10 Sep 2025 09:16:19 GMT, Hamlin Li wrote: >> Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: >> >> Replace CacheLineSize with zicboz_block_size in block zeroing logic > > src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 5877: > >> 5875: // >> 5876: // NOTE: This is intended to be used in the zero_blocks() stub. If >> 5877: // you want to use it elsewhere, note that cnt must be no less than zicboz block size. > > previous style is more readable, like: > >>= zicboz_block_size Fixed. > src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp line 91: > >> 89: #define RISCV_HWPROBE_MISALIGNED_UNSUPPORTED (4 << 0) >> 90: #define RISCV_HWPROBE_MISALIGNED_MASK (7 << 0) >> 91: #define RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE 6 > > better to have a new line. Thanks for the review! Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27155#discussion_r2338203476 PR Review Comment: https://git.openjdk.org/jdk/pull/27155#discussion_r2338203353 From fyang at openjdk.org Thu Sep 11 00:35:15 2025 From: fyang at openjdk.org (Fei Yang) Date: Thu, 11 Sep 2025 00:35:15 GMT Subject: RFR: 8367137: RISC-V: Detect Zicboz block size via hwprobe [v5] In-Reply-To: References: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> Message-ID: On Thu, 11 Sep 2025 00:11:34 GMT, Dingli Zhang wrote: >> Hi, >> Can you help to review this patch? Thanks! >> >> We can extends RISC-V hwprobe support to include `RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`. >> The probed value is recorded in VM_Version::zicboz_block_size and then used to set the global CacheLineSize. >> This ensures correct usage of the Zicboz extension, as block zeroing instructions operate on cache-line granularity. >> >> FYI: https://docs.kernel.org/arch/riscv/hwprobe.html > > Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: > > Refine comments and formatting src/hotspot/cpu/riscv/vm_version_riscv.cpp line 190: > 188: } > 189: if (FLAG_IS_DEFAULT(BlockZeroingLowLimit)) { > 190: FLAG_SET_DEFAULT(BlockZeroingLowLimit, 2 * zicboz_block_size.value()); Seems to me some extra change is needed at the use of `zero_dcache_blocks` in file stubGenerator_riscv.cpp: diff --git a/src/hotspot/cpu/riscv/stubGenerator_riscv.cpp b/src/hotspot/cpu/riscv/stubGenerator_riscv.cpp index 7db426327ee..9ab16dea39b 100644 --- a/src/hotspot/cpu/riscv/stubGenerator_riscv.cpp +++ b/src/hotspot/cpu/riscv/stubGenerator_riscv.cpp @@ -683,10 +683,11 @@ class StubGenerator: public StubCodeGenerator { address start = __ pc(); if (UseBlockZeroing) { - // Ensure count >= 2*CacheLineSize so that it still deserves a cbo.zero - // after alignment. + int zicboz_blk_size = VM_Version::zicboz_block_size.value(); + // Ensure count >= 2 * zicboz_block_size so that it still deserves + // a cbo.zero after alignment. Label small; - int low_limit = MAX2(2 * CacheLineSize, BlockZeroingLowLimit) / wordSize; + int low_limit = MAX2(2 * zicboz_blk_size, BlockZeroingLowLimit) / wordSize; __ mv(tmp1, low_limit); __ blt(cnt, tmp1, small); __ zero_dcache_blocks(base, cnt, tmp1, tmp2); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27155#discussion_r2338227450 From liach at openjdk.org Thu Sep 11 00:40:15 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 11 Sep 2025 00:40:15 GMT Subject: RFR: 8367368: Add message for verify_legal_class_modifiers for inner classes In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 18:38:56 GMT, Coleen Phillimore wrote: > This adds the inner class name (or unnamed) to the error message for invalid inner class modifiers. > Testing with tier1-4. test/hotspot/jtreg/runtime/InnerClassesAttr/TestInnerClassAccessFlagErrorMessage.java line 58: > 56: } catch (ClassFormatError err) { > 57: System.out.println(err.getMessage()); > 58: assertEquals(err.getMessage(), msg2); I recommend testing against message fragment to ensure the class name is included without asserting the whole message, to allow more freedom in error messages while retaining desired info. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27201#discussion_r2338233277 From dholmes at openjdk.org Thu Sep 11 00:41:22 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 11 Sep 2025 00:41:22 GMT Subject: RFR: 8367142: Avoid InstanceKlass::cast when converting java mirror to InstanceKlass [v3] In-Reply-To: <3Xh3sS0I7pp0fslgQndt4CLqddxga7W8c11tuZkNgd8=.b5a28dba-05f1-49d9-80f8-6260a9772287@github.com> References: <3Xh3sS0I7pp0fslgQndt4CLqddxga7W8c11tuZkNgd8=.b5a28dba-05f1-49d9-80f8-6260a9772287@github.com> Message-ID: On Wed, 10 Sep 2025 22:46:00 GMT, Ioi Lam wrote: >> The purpose of this PR is to simplify JNI code and also to avoid unnecessary `InstanceKlass::cast()` calls by adding a new function: >> >> >> static InstanceKlass* java_lang_Class::as_InstanceKlass(oop java_class); >> >> >> This PR is intended to be a strict clean-up that preserves existing behaviors. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Removed the (jobject) version of as_Klass/as_InstanceKlass Reduced set of changes still looks good. I was prepared to be accommodating on the broader change, but seems others agreed with my initial position. :) ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27158#pullrequestreview-3208294346 From liach at openjdk.org Thu Sep 11 00:49:20 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 11 Sep 2025 00:49:20 GMT Subject: RFR: 8367368: Add message for verify_legal_class_modifiers for inner classes In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 18:38:56 GMT, Coleen Phillimore wrote: > This adds the inner class name (or unnamed) to the error message for invalid inner class modifiers. > Testing with tier1-4. I think for inner class errors, instead of reporting inner simple name, we should report: 1. offending class file 2. the inner class class constant. It is the only identification part that must be present. 3. the offending data, such as bad flags What do you think? The inner class constant is universal because outer class is absent for anonymous/local classes and simple name is absent for anonymous classes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27201#issuecomment-3276994512 From dzhang at openjdk.org Thu Sep 11 00:49:42 2025 From: dzhang at openjdk.org (Dingli Zhang) Date: Thu, 11 Sep 2025 00:49:42 GMT Subject: RFR: 8367137: RISC-V: Detect Zicboz block size via hwprobe [v6] In-Reply-To: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> References: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> Message-ID: > Hi, > Can you help to review this patch? Thanks! > > We can extends RISC-V hwprobe support to include `RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`. > The probed value is recorded in VM_Version::zicboz_block_size and then used to set the zicboz_block_size. > This ensures correct usage of the Zicboz extension, as block zeroing instructions operate on cache-line granularity. > > FYI: https://docs.kernel.org/arch/riscv/hwprobe.html Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: Add some extra change at the use of zero_dcache_blocks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27155/files - new: https://git.openjdk.org/jdk/pull/27155/files/5a167d6b..e8694344 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27155&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27155&range=04-05 Stats: 5 lines in 2 files changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27155/head:pull/27155 PR: https://git.openjdk.org/jdk/pull/27155 From dzhang at openjdk.org Thu Sep 11 00:49:45 2025 From: dzhang at openjdk.org (Dingli Zhang) Date: Thu, 11 Sep 2025 00:49:45 GMT Subject: RFR: 8367137: RISC-V: Detect Zicboz block size via hwprobe [v5] In-Reply-To: References: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> Message-ID: On Thu, 11 Sep 2025 00:31:27 GMT, Fei Yang wrote: >> Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: >> >> Refine comments and formatting > > src/hotspot/cpu/riscv/vm_version_riscv.cpp line 190: > >> 188: } >> 189: if (FLAG_IS_DEFAULT(BlockZeroingLowLimit)) { >> 190: FLAG_SET_DEFAULT(BlockZeroingLowLimit, 2 * zicboz_block_size.value()); > > Seems to me some extra change is needed at the use of `zero_dcache_blocks` in file stubGenerator_riscv.cpp: > > diff --git a/src/hotspot/cpu/riscv/stubGenerator_riscv.cpp b/src/hotspot/cpu/riscv/stubGenerator_riscv.cpp > index 7db426327ee..9ab16dea39b 100644 > --- a/src/hotspot/cpu/riscv/stubGenerator_riscv.cpp > +++ b/src/hotspot/cpu/riscv/stubGenerator_riscv.cpp > @@ -683,10 +683,11 @@ class StubGenerator: public StubCodeGenerator { > address start = __ pc(); > > if (UseBlockZeroing) { > - // Ensure count >= 2*CacheLineSize so that it still deserves a cbo.zero > - // after alignment. > + int zicboz_blk_size = VM_Version::zicboz_block_size.value(); > + // Ensure count >= 2 * zicboz_block_size so that it still deserves > + // a cbo.zero after alignment. > Label small; > - int low_limit = MAX2(2 * CacheLineSize, BlockZeroingLowLimit) / wordSize; > + int low_limit = MAX2(2 * zicboz_blk_size, BlockZeroingLowLimit) / wordSize; > __ mv(tmp1, low_limit); > __ blt(cnt, tmp1, small); > __ zero_dcache_blocks(base, cnt, tmp1, tmp2); Thanks! Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27155#discussion_r2338242027 From dzhang at openjdk.org Thu Sep 11 01:28:33 2025 From: dzhang at openjdk.org (Dingli Zhang) Date: Thu, 11 Sep 2025 01:28:33 GMT Subject: RFR: 8367137: RISC-V: Detect Zicboz block size via hwprobe [v7] In-Reply-To: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> References: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> Message-ID: > Hi, > Can you help to review this patch? Thanks! > > We can extends RISC-V hwprobe support to include `RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`. > The probed value is recorded in VM_Version::zicboz_block_size and then used to set the zicboz_block_size. > This ensures correct usage of the Zicboz extension, as block zeroing instructions operate on cache-line granularity. > > FYI: https://docs.kernel.org/arch/riscv/hwprobe.html Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: Unify variable names to correspond with comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27155/files - new: https://git.openjdk.org/jdk/pull/27155/files/e8694344..4f6a75b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27155&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27155&range=05-06 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27155/head:pull/27155 PR: https://git.openjdk.org/jdk/pull/27155 From dholmes at openjdk.org Thu Sep 11 01:47:11 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 11 Sep 2025 01:47:11 GMT Subject: RFR: 8366865: G1: Allocation GC Pauses Triggered after JVM has started shutdown In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 09:57:18 GMT, Ivan Walulya wrote: > Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. > > Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. > > Testing: Tier 1-7 src/hotspot/share/gc/shared/collectedHeap.cpp line 616: > 614: // If the VM is shutting down, we may have skipped VM_CollectForAllocation. > 615: // To avoid returning nullptr (which could cause premature OOME), we stall > 616: // allocation requests here until the VM shutdown is complete. If I understand the shutdown sequence correctly, I don't think you can do this without risking a hang. The thread doing the shutdown can potentially execute code that requires allocation after `is_shutting_down()` returns true. This is due to the JVMTI events posted from `before_exit`: if (JvmtiExport::should_post_thread_life()) { JvmtiExport::post_thread_end(thread); } // Always call even when there are not JVMTI environments yet, since environments // may be attached late and JVMTI must track phases of VM execution JvmtiExport::post_vm_death(); I think if you can't GC during shutdown then you have to simply let the allocation fail. src/hotspot/share/runtime/mutexLocker.cpp line 85: > 83: Monitor* InitCompleted_lock = nullptr; > 84: Monitor* BeforeExit_lock = nullptr; > 85: Monitor* VMExit_lock = nullptr; It is unfortunate that we need yet-another exit related mutex. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2338299593 PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2338286600 From dholmes at openjdk.org Thu Sep 11 02:03:11 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 11 Sep 2025 02:03:11 GMT Subject: RFR: 8367249: [REDO] MemBaseline accesses VMT without using lock In-Reply-To: References: Message-ID: <2KczGzhaSQQJn5SfvB1EmkMnNlsH21VvhK193Wu7xas=.98253339-60cc-4d74-a48d-623b3472f0c0@github.com> On Wed, 10 Sep 2025 16:38:45 GMT, Johan Sj?len wrote: > It's really weird that the linux-x64-static tests fail. It just an infra issue: Unable to download artifact(s): Artifact not found for name: bundles-jtreg-7.5.2+1 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27170#issuecomment-3277099694 From fjiang at openjdk.org Thu Sep 11 02:11:09 2025 From: fjiang at openjdk.org (Feilong Jiang) Date: Thu, 11 Sep 2025 02:11:09 GMT Subject: RFR: 8367066: RISC-V: refine register selection in MacroAssembler:: decode_klass_not_null [v2] In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 14:13:16 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> >> Previously, the register selection in MacroAssembler:: decode_klass_not_null is misleading, better to refine it to improve the readability. >> >> Thanks! >> >> Running runtime test tier1/2/3... > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > refine Thanks! ------------- Marked as reviewed by fjiang (Committer). PR Review: https://git.openjdk.org/jdk/pull/27138#pullrequestreview-3208415074 From dholmes at openjdk.org Thu Sep 11 02:21:24 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 11 Sep 2025 02:21:24 GMT Subject: RFR: 8367368: Add message for verify_legal_class_modifiers for inner classes In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 18:38:56 GMT, Coleen Phillimore wrote: > This adds the inner class name (or unnamed) to the error message for invalid inner class modifiers. > Testing with tier1-4. Overall seems fine, but a few minor nits/suggestions. Thanks src/hotspot/share/classfile/classFileParser.cpp line 4277: > 4275: // utility methods for format checking > 4276: > 4277: void ClassFileParser::verify_legal_class_modifiers(jint flags, Symbol* inner_name, TRAPS) const { Suggestion: // Verify the class modifiers for the current class, or an inner class if inner_name is non-null. void ClassFileParser::verify_legal_class_modifiers(jint flags, Symbol* inner_name, TRAPS) const { src/hotspot/share/classfile/vmSymbols.hpp line 515: > 513: template(lockStackSize_name, "lockStackSize") \ > 514: template(objectWaiter_name, "objectWaiter") \ > 515: template(unnamed_name, "unnamed") \ Shouldn't this use "anonymous" rather than "unnamed"? test/hotspot/jtreg/runtime/InnerClassesAttr/OuterTest1.jcod line 109: > 107: Attr(#16) { // InnerClasses > 108: [] { // classes > 109: #14 #7 #17 0x0fff; Is this where the invalid part is? Please add a comment test/hotspot/jtreg/runtime/InnerClassesAttr/OuterTest2.jcod line 164: > 162: Attr(#26) { // InnerClasses > 163: [] { // classes > 164: #7 #0 #0 0x0fff; Again, explanatory comment please. ------------- PR Review: https://git.openjdk.org/jdk/pull/27201#pullrequestreview-3208421103 PR Review Comment: https://git.openjdk.org/jdk/pull/27201#discussion_r2338331347 PR Review Comment: https://git.openjdk.org/jdk/pull/27201#discussion_r2338333068 PR Review Comment: https://git.openjdk.org/jdk/pull/27201#discussion_r2338334162 PR Review Comment: https://git.openjdk.org/jdk/pull/27201#discussion_r2338335010 From fyang at openjdk.org Thu Sep 11 02:23:12 2025 From: fyang at openjdk.org (Fei Yang) Date: Thu, 11 Sep 2025 02:23:12 GMT Subject: RFR: 8367137: RISC-V: Detect Zicboz block size via hwprobe [v7] In-Reply-To: References: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> Message-ID: On Thu, 11 Sep 2025 01:28:33 GMT, Dingli Zhang wrote: >> Hi, >> Can you help to review this patch? Thanks! >> >> We can extends RISC-V hwprobe support to include `RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`. >> The probed value is recorded in VM_Version::zicboz_block_size and then used to set the zicboz_block_size. >> This ensures correct usage of the Zicboz extension, as block zeroing instructions operate on cache-line granularity. >> >> FYI: https://docs.kernel.org/arch/riscv/hwprobe.html > > Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: > > Unify variable names to correspond with comments LGTM. Thanks. ------------- Marked as reviewed by fyang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27155#pullrequestreview-3208430542 From dholmes at openjdk.org Thu Sep 11 02:27:09 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 11 Sep 2025 02:27:09 GMT Subject: RFR: 8367368: Add message for verify_legal_class_modifiers for inner classes In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 00:46:42 GMT, Chen Liang wrote: > I think for inner class errors, instead of reporting inner simple name, we should report: > > 1. offending class file > 2. the inner class class constant. It is the only identification part that must be present. > 3. the offending data, such as bad flags > > What do you think? The inner class constant is universal because outer class is absent for anonymous/local classes and simple name is absent for anonymous classes. Generally speaking we try not to "tutorialize" these kinds of errors. They should only arise from people using specially crafted , invalid, bytecode, and we expect the originators of that code to be able to understand what they did wrong. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27201#issuecomment-3277140270 From kbarrett at openjdk.org Thu Sep 11 04:11:29 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 11 Sep 2025 04:11:29 GMT Subject: RFR: 8367282: FORBID_C_FUNCTION needs exception spec consistent with library declaration [v2] In-Reply-To: References: Message-ID: > Please review this change to FORBID_C_FUNCTION to make the exception specs of > the forbidding declarations match up with the exception specs of the > associated library declarations. This needs to account for different platform > libraries either having or not having exception specs. It's needed because, > after switching to C++17, some compilers complain about some differences in > the exception specs. > > Also removed the workaround for JDK-8367051, which should no longer be needed > after this change. > > Hoping someone will test the aix-ppc port. @MBaesken or @TheRealMDoerr ? > > Testing: mach5 tier1, GHA sanity checks (nearly finished) > Locally (linux-aarch64) built with clang, which failed without the JDK-8367051 > workaround. Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: work around AIX noexcept inconsistencies ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27180/files - new: https://git.openjdk.org/jdk/pull/27180/files/0fcb5f53..52f28437 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27180&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27180&range=00-01 Stats: 10 lines in 2 files changed: 5 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27180.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27180/head:pull/27180 PR: https://git.openjdk.org/jdk/pull/27180 From kbarrett at openjdk.org Thu Sep 11 04:23:16 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 11 Sep 2025 04:23:16 GMT Subject: RFR: 8367014: Rename class Atomic to AtomicAccess [v2] In-Reply-To: <8HMzxvTwZd1uSZCs528eM4pHsJVeKmFGtplElc8vXpk=.643b3706-7af2-40aa-835c-c3f8a785dd0e@github.com> References: <8HMzxvTwZd1uSZCs528eM4pHsJVeKmFGtplElc8vXpk=.643b3706-7af2-40aa-835c-c3f8a785dd0e@github.com> Message-ID: On Wed, 10 Sep 2025 07:34:09 GMT, Kim Barrett wrote: >> Please review this change that renames the all-static class `Atomic` to >> `AtomicAccess`. The reason for this name change is to allow the introduction >> of the new type `Atomic` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)). >> >> The PR has several commits, according to the specific category of change being >> made. It may be easier to review the PR by studying these individual commits. >> >> Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose >> to not rename the various "atomic_.*" and "atomic__.*" files. >> >> There are a number of comments containing the word "Atomic" that I didn't >> change. They are generically about atomic operations, and will just as well >> serve as referring to the future `Atomic`. >> >> Testing: mach5 tier1, GHA sanity tests. >> This is one of those changes where successful builds indicate the change is good. > > Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - rename recently added Atomic:: => AtomicAccess:: > - Merge branch 'master' into atomic-access > - fix prefiously missed arg misalignments > - rename test_atomic.cpp > - update copyrights > - misc cleanups > - fix indentation from rename > - rename Atomic => AtomicAccess in gtests > - rename Atomic => AtomicAccess > - change includes of atomic.hpp in gtests > - ... and 2 more: https://git.openjdk.org/jdk/compare/af9b9050...11007c45 Needs re-review because of updates to deal with merge conflicts and to update newly merged code that needed the renamings applied. @stefank @theRealAph @dholmes-ora Hm, now says there is a new merge conflict. Guess you folks should hold off on re-review. src/hotspot/cpu/aarch64/gc/shared/barrierSetNMethod_aarch64.cpp line 118: > 116: } > 117: > 118: void set_value(int value, int bit_mask) { This and similar changes for arm and riscv came from a merged changeset. I took that new version and updated it for `Atomic::` => `AtomicAccess::` renaming. src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 394: > 392: last_recompute_check = os::javaTimeNanos(); > 393: } > 394: DEBUG_ONLY(if (AtomicAccess::load_acquire(&_out_of_stack_walking_enabled)) {) Another case of taking a merge update and then adjusting for `Atomic::` => `AtomicAccess::`. src/hotspot/share/runtime/basicLock.inline.hpp line 32: > 30: #include "runtime/objectMonitor.inline.hpp" > 31: > 32: inline markWord BasicLock::displaced_header() const { These functions were removed by a merge update. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27135#issuecomment-3277397927 PR Comment: https://git.openjdk.org/jdk/pull/27135#issuecomment-3277401578 PR Review Comment: https://git.openjdk.org/jdk/pull/27135#discussion_r2338471419 PR Review Comment: https://git.openjdk.org/jdk/pull/27135#discussion_r2338472405 PR Review Comment: https://git.openjdk.org/jdk/pull/27135#discussion_r2338473094 From iklam at openjdk.org Thu Sep 11 04:43:48 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 11 Sep 2025 04:43:48 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation Message-ID: This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. This PR annotates a single class, `jdk.internal.math.MathUtils`. More classes will be added in future PRs. If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to - All of `K`'s super classes - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). This annotation is awfully similar to `@AOTSafeAnnotation`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. ------------- Commit messages: - Added javadoc; added test case; code clean up - Merge branch 'master' into aot-initialize-math-utils - cleanup - Merge branch 'master' into aot-initialize-math-utils - Merge branch '8366477-refactor-aot-related-flag-bits-in-klass-hpp' into aot-initialize-math-utils - Merge branch 'master' into 8366477-refactor-aot-related-flag-bits-in-klass-hpp - @liach and @ashu-mehra comment: Renamed Klass::_is_generated_shared_class -> _is_aot_generated_class - Merge branch 'master' into 8366477-refactor-aot-related-flag-bits-in-klass-hpp.saved - Move annotation validation to AOTClassInitializer::check_aot_annotations() - Force AOT initialization of MathUtils in assembly phase - ... and 8 more: https://git.openjdk.org/jdk/compare/134c3ef4...5b71ce80 Changes: https://git.openjdk.org/jdk/pull/27024/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27024&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367387 Stats: 316 lines in 10 files changed: 263 ins; 49 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27024.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27024/head:pull/27024 PR: https://git.openjdk.org/jdk/pull/27024 From kbarrett at openjdk.org Thu Sep 11 05:30:11 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 11 Sep 2025 05:30:11 GMT Subject: RFR: 8367014: Rename class Atomic to AtomicAccess [v3] In-Reply-To: References: Message-ID: <2uwnMiCfWvw9BT15Us6UZqTE_JD4-OGNIsjjzZotu9Y=.7efc037c-5d91-4b7b-88be-c48adb659ff6@github.com> > Please review this change that renames the all-static class `Atomic` to > `AtomicAccess`. The reason for this name change is to allow the introduction > of the new type `Atomic` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)). > > The PR has several commits, according to the specific category of change being > made. It may be easier to review the PR by studying these individual commits. > > Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose > to not rename the various "atomic_.*" and "atomic__.*" files. > > There are a number of comments containing the word "Atomic" that I didn't > change. They are generically about atomic operations, and will just as well > serve as referring to the future `Atomic`. > > Testing: mach5 tier1, GHA sanity tests. > This is one of those changes where successful builds indicate the change is good. Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - Merge branch 'master' into atomic-access - rename recently added Atomic:: => AtomicAccess:: - Merge branch 'master' into atomic-access - fix prefiously missed arg misalignments - rename test_atomic.cpp - update copyrights - misc cleanups - fix indentation from rename - rename Atomic => AtomicAccess in gtests - rename Atomic => AtomicAccess - ... and 3 more: https://git.openjdk.org/jdk/compare/134c3ef4...00ecd55c ------------- Changes: https://git.openjdk.org/jdk/pull/27135/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27135&range=02 Stats: 5577 lines in 430 files changed: 1587 ins; 1585 del; 2405 mod Patch: https://git.openjdk.org/jdk/pull/27135.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27135/head:pull/27135 PR: https://git.openjdk.org/jdk/pull/27135 From aboldtch at openjdk.org Thu Sep 11 05:31:11 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 11 Sep 2025 05:31:11 GMT Subject: RFR: 8367149: Add ergonomic construction for creating ad-hoc VMErrorCallback [v2] In-Reply-To: References: Message-ID: <_bJ3HsDv9gOmupLxERZ9K-rG5mchQD7exetGKv-XiJs=.5cbf1fad-5a1d-4731-84cc-267d1103363a@github.com> On Wed, 10 Sep 2025 09:03:40 GMT, Albert Mingkun Yang wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision: >> >> - Add a comment explaining the deduction rules >> - Skip multiple inheritance and allow more than lambda like callables. >> - Update doc example > > src/hotspot/share/utilities/vmError.hpp line 254: > >> 252: }; >> 253: >> 254: // Ergonomic construction for creating ad-hoc VMErrorCallback which automatically > > Does `Ergonomic construction` have specific meanings in cpp/this context? If not, I wonder if `lightweight` is clearer, as it is less technical. Not that I know of. I ment it to mean that this is type with makes it ergonomic (as in, efficient and comfortable) to create an ad-hoc VMErrorCallback. So rather than having to do something like: ```C++ struct AdHocVMErrorCallback : public VMErrorCallback { ThisType& _instance; ValueType _value; AdHocVMErrorCallback(ThisType& instance) : _instance(instance), _value(_instance.get_important_value) {} void call(outputStream* st) final { // Dump the important bits. st->print("Prior value: "); _value.print_on(st); st->print("During crash: ") _instance.get_the_value().print_on(st); // Dump whole the whole state. _instance.print_on(st); } } on_error(*this); you can use this construction with a lambda. Not sure if lightweight capture I intended to convey, but it also seems like `Ergonomic construction` missed the mark. Maybe just call it `A construction for creating ad-hoc VMErrorCallback` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27159#discussion_r2338631227 From aboldtch at openjdk.org Thu Sep 11 05:37:20 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 11 Sep 2025 05:37:20 GMT Subject: RFR: 8367149: Add ergonomic construction for creating ad-hoc VMErrorCallback [v2] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 14:17:42 GMT, Axel Boldt-Christmas wrote: >> Add a class OnVMError which uses the VMErrorCallback mechanism which is an ergonomic construction for creating ad-hoc VMErrorCallback which automatically calls the provided invocable f if a VM crash occurs within its lifetime. Can be used to instrument a build for more detailed contextual information gathering. Especially useful when hunting down intermittent bugs, or issues only reproducible in environments where access to a debugger is not readily available. Example use: >> ```C++ >> { >> // Note the lambda is invoked after an error occurs within this thread, >> // and during on_error's lifetime. If state prior to the crash is required, >> // capture a copy of it first. >> auto important_value = get_the_value(); >> >> OnVMError on_error([&](outputStream* st) { >> // Dump the important bits. >> st->print("Prior value: "); >> important_value.print_on(st); >> st->print("During crash: ") >> get_the_value().print_on(st); >> // Dump whole the whole state. >> this->print_on(st); >> }); >> >> // Sometimes doing a thing will crash the VM. >> do_a_thing(); >> } >> >> >> C++17 class template argument deduction finally makes these sort of constructions ergonomic to use without the need for auto and helper construction methods. > > Axel Boldt-Christmas has updated the pull request incrementally with three additional commits since the last revision: > > - Add a comment explaining the deduction rules > - Skip multiple inheritance and allow more than lambda like callables. > - Update doc example I initially intended for this to just be allowed to take a lambda like temporary and just use that. But after looking at it some more and using it a bit I think it is fine to extend this to anything which behaves like a callable (via operator()(outputStream*)) and can be move/copy constructed. So you can now also use a lvalue lambda or function pointer. Felt like it would be the least surprising outcome when trying to use this class. Even though using it as `OnVMError(&&)` is the expected use case (as presented in the example). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27159#issuecomment-3277907074 From dholmes at openjdk.org Thu Sep 11 05:57:19 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 11 Sep 2025 05:57:19 GMT Subject: RFR: 8367282: FORBID_C_FUNCTION needs exception spec consistent with library declaration [v2] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 04:11:29 GMT, Kim Barrett wrote: >> Please review this change to FORBID_C_FUNCTION to make the exception specs of >> the forbidding declarations match up with the exception specs of the >> associated library declarations. This needs to account for different platform >> libraries either having or not having exception specs. It's needed because, >> after switching to C++17, some compilers complain about some differences in >> the exception specs. >> >> Also removed the workaround for JDK-8367051, which should no longer be needed >> after this change. >> >> Hoping someone will test the aix-ppc port. @MBaesken or @TheRealMDoerr ? >> >> Testing: mach5 tier1, GHA sanity checks (nearly finished) >> Locally (linux-aarch64) built with clang, which failed without the JDK-8367051 >> workaround. > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > work around AIX noexcept inconsistencies src/hotspot/share/utilities/compilerWarnings.hpp line 122: > 120: [[deprecated(Alternative)]] \ > 121: Signature \ > 122: /* 2-step pasting to avoid expansion of FFCN => nothing. */ \ Was this an issue with AIX or is this just a "better" way? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27180#discussion_r2338695490 From dholmes at openjdk.org Thu Sep 11 06:00:20 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 11 Sep 2025 06:00:20 GMT Subject: RFR: 8367014: Rename class Atomic to AtomicAccess [v3] In-Reply-To: <2uwnMiCfWvw9BT15Us6UZqTE_JD4-OGNIsjjzZotu9Y=.7efc037c-5d91-4b7b-88be-c48adb659ff6@github.com> References: <2uwnMiCfWvw9BT15Us6UZqTE_JD4-OGNIsjjzZotu9Y=.7efc037c-5d91-4b7b-88be-c48adb659ff6@github.com> Message-ID: On Thu, 11 Sep 2025 05:30:11 GMT, Kim Barrett wrote: >> Please review this change that renames the all-static class `Atomic` to >> `AtomicAccess`. The reason for this name change is to allow the introduction >> of the new type `Atomic` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)). >> >> The PR has several commits, according to the specific category of change being >> made. It may be easier to review the PR by studying these individual commits. >> >> Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose >> to not rename the various "atomic_.*" and "atomic__.*" files. >> >> There are a number of comments containing the word "Atomic" that I didn't >> change. They are generically about atomic operations, and will just as well >> serve as referring to the future `Atomic`. >> >> Testing: mach5 tier1, GHA sanity tests. >> This is one of those changes where successful builds indicate the change is good. > > Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Merge branch 'master' into atomic-access > - rename recently added Atomic:: => AtomicAccess:: > - Merge branch 'master' into atomic-access > - fix prefiously missed arg misalignments > - rename test_atomic.cpp > - update copyrights > - misc cleanups > - fix indentation from rename > - rename Atomic => AtomicAccess in gtests > - rename Atomic => AtomicAccess > - ... and 3 more: https://git.openjdk.org/jdk/compare/134c3ef4...00ecd55c Still good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27135#pullrequestreview-3208979512 From asteiner at openjdk.org Thu Sep 11 06:47:01 2025 From: asteiner at openjdk.org (Andreas Steiner) Date: Thu, 11 Sep 2025 06:47:01 GMT Subject: RFR: 8359104: gc/TestAlwaysPreTouchBehavior.java# fails on Linux [v2] In-Reply-To: References: Message-ID: > Get accurate RSS, from smaps_rollup if available(Linux >= 4.14), because the RSS from status is inaccurate especially on systems with more than 32 CPUs. > > Not sure if all the additional meminfos like the Pss, Pss_dirty, Pss_Anon, Pss_File, Pss_Shmem, Swap and SwapPss are really needed too. But can be perhaps helpful too. > > As the inaccurate memory infos are still used in other methods: > - [print_process_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2393) > - [jfr_report_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2686) > - [trim_native_heap()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L5376) > > one can think about to use the accurate values there too. Andreas Steiner has updated the pull request incrementally with one additional commit since the last revision: extend the accurate rss check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27192/files - new: https://git.openjdk.org/jdk/pull/27192/files/c819368b..97d88b64 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27192&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27192&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27192.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27192/head:pull/27192 PR: https://git.openjdk.org/jdk/pull/27192 From stefank at openjdk.org Thu Sep 11 06:47:16 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 11 Sep 2025 06:47:16 GMT Subject: RFR: 8367142: Avoid InstanceKlass::cast when converting java mirror to InstanceKlass [v3] In-Reply-To: References: <3Xh3sS0I7pp0fslgQndt4CLqddxga7W8c11tuZkNgd8=.b5a28dba-05f1-49d9-80f8-6260a9772287@github.com> Message-ID: <5c8zxQ36O0VJk5X7lu5QRuh7LhM49ZdpUTmDV-qc2l4=.9a4c2d95-9a0a-4ba6-8f73-b05e90030f6e@github.com> On Wed, 10 Sep 2025 22:47:27 GMT, Ioi Lam wrote: > I didn't realize that my attempt to remove the JNIHandles::resolve() boilerplate can be conversional. Removing boilerplate wasn't controversial. Spreading the j* types can be seen as controversial give that we have various efforts to push those types out to the boundaries of the JVM. Adding new convenience functions that accept j* goes in the opposite direction. > I can't put a helper function in jni.cpp because this pattern is used in several files. But almost all are in jni.cpp and jvm.cpp and you can get rid of most of the boilerplate code by adding local helpers there. The handfulish of other places could keep their explicit usage of JNIHandles::resolve* calls. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27158#issuecomment-3278518160 From asteiner at openjdk.org Thu Sep 11 06:50:12 2025 From: asteiner at openjdk.org (Andreas Steiner) Date: Thu, 11 Sep 2025 06:50:12 GMT Subject: RFR: 8359104: gc/TestAlwaysPreTouchBehavior.java# fails on Linux In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 14:44:27 GMT, Matthias Baesken wrote: > we use `size = info.rss * K;` for the calculation in `os::rss()` . But `os::Linux::query_accurate_process_memory_info ` returns true just in case the file could be opened , probably should we better check in a more detailed way e.g. at least that rss was found in /proc ? Thanks for the hint. I extended the check. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27192#issuecomment-3278527717 From stefank at openjdk.org Thu Sep 11 06:51:18 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 11 Sep 2025 06:51:18 GMT Subject: RFR: 8367149: Add ergonomic construction for creating ad-hoc VMErrorCallback [v2] In-Reply-To: <_bJ3HsDv9gOmupLxERZ9K-rG5mchQD7exetGKv-XiJs=.5cbf1fad-5a1d-4731-84cc-267d1103363a@github.com> References: <_bJ3HsDv9gOmupLxERZ9K-rG5mchQD7exetGKv-XiJs=.5cbf1fad-5a1d-4731-84cc-267d1103363a@github.com> Message-ID: On Thu, 11 Sep 2025 05:27:53 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/share/utilities/vmError.hpp line 254: >> >>> 252: }; >>> 253: >>> 254: // Ergonomic construction for creating ad-hoc VMErrorCallback which automatically >> >> Does `Ergonomic construction` have specific meanings in cpp/this context? If not, I wonder if `lightweight` is clearer, as it is less technical. > > Not that I know of. > > I ment it to mean that this is type with makes it ergonomic (as in, efficient and comfortable) to create an ad-hoc VMErrorCallback. So rather than having to do something like: > ```C++ > struct AdHocVMErrorCallback : public VMErrorCallback { > ThisType& _instance; > ValueType _value; > > AdHocVMErrorCallback(ThisType& instance) > : _instance(instance), > _value(_instance.get_important_value) {} > > void call(outputStream* st) final { > // Dump the important bits. > st->print("Prior value: "); > _value.print_on(st); > st->print("During crash: ") > _instance.get_the_value().print_on(st); > // Dump whole the whole state. > _instance.print_on(st); > } > } on_error(*this); > > you can use this construction with a lambda. > > Not sure if lightweight capture I intended to convey, but it also seems like `Ergonomic construction` missed the mark. Maybe just call it `A construction for creating ad-hoc VMErrorCallback` Maybe `convenient` would be an apt word here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27159#discussion_r2338932845 From kbarrett at openjdk.org Thu Sep 11 06:55:24 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 11 Sep 2025 06:55:24 GMT Subject: RFR: 8367282: FORBID_C_FUNCTION needs exception spec consistent with library declaration [v2] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 05:54:14 GMT, David Holmes wrote: >> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >> >> work around AIX noexcept inconsistencies > > src/hotspot/share/utilities/compilerWarnings.hpp line 122: > >> 120: [[deprecated(Alternative)]] \ >> 121: Signature \ >> 122: /* 2-step pasting to avoid expansion of FFCN => nothing. */ \ > > Was this an issue with AIX or is this just a "better" way? This is needed in order to allow `NOT_AIX(noexcept)` for the `Noexcept` argument. We need pasting of the expansion, not direct pasting. Just using direct `##` as before results in making something like `FORBIDDEN_FUNCTION_COND_NOEXCEPT_NOT_AIX(noexcept)` which isn't what we want here. And doing a single paste, e.g. `PASTE_TOKENS(FORBIDDEN_FUNCTION_COND_NOEXCEPT_, Noexcept)` expands the first argument to nothing, so we just get `noexcept`, which isn't what we want and doesn't work on platforms that don't declare their library functions noexcept. The joys of macros... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27180#discussion_r2338954298 From tschatzl at openjdk.org Thu Sep 11 07:26:25 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 11 Sep 2025 07:26:25 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v59] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 15:28:39 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * walulyai review That test failure in windows-x64 is a shenandoah timeout that looks unrelated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3278828076 From mbaesken at openjdk.org Thu Sep 11 07:39:31 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 11 Sep 2025 07:39:31 GMT Subject: RFR: 8359104: gc/TestAlwaysPreTouchBehavior.java# fails on Linux [v2] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 06:47:01 GMT, Andreas Steiner wrote: >> Get accurate RSS, from smaps_rollup if available(Linux >= 4.14), because the RSS from status is inaccurate especially on systems with more than 32 CPUs. >> >> Not sure if all the additional meminfos like the Pss, Pss_dirty, Pss_Anon, Pss_File, Pss_Shmem, Swap and SwapPss are really needed too. But can be perhaps helpful too. >> >> As the inaccurate memory infos are still used in other methods: >> - [print_process_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2393) >> - [jfr_report_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2686) >> - [trim_native_heap()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L5376) >> >> one can think about to use the accurate values there too. > > Andreas Steiner has updated the pull request incrementally with one additional commit since the last revision: > > extend the accurate rss check Marked as reviewed by mbaesken (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27192#pullrequestreview-3209492708 From jsjolen at openjdk.org Thu Sep 11 07:45:17 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 11 Sep 2025 07:45:17 GMT Subject: RFR: 8367249: [REDO] MemBaseline accesses VMT without using lock In-Reply-To: <2KczGzhaSQQJn5SfvB1EmkMnNlsH21VvhK193Wu7xas=.98253339-60cc-4d74-a48d-623b3472f0c0@github.com> References: <2KczGzhaSQQJn5SfvB1EmkMnNlsH21VvhK193Wu7xas=.98253339-60cc-4d74-a48d-623b3472f0c0@github.com> Message-ID: On Thu, 11 Sep 2025 02:00:43 GMT, David Holmes wrote: > > It's really weird that the linux-x64-static tests fail. > > It just an infra issue: > > Unable to download artifact(s): Artifact not found for name: bundles-jtreg-7.5.2+1 Last time I ran it, it actually did fail on a Whitebox NMT test related to exactly this change. The logs were gone, so I re-ran the test, and this time infra failed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27170#issuecomment-3278931579 From mli at openjdk.org Thu Sep 11 08:10:09 2025 From: mli at openjdk.org (Hamlin Li) Date: Thu, 11 Sep 2025 08:10:09 GMT Subject: RFR: 8367137: RISC-V: Detect Zicboz block size via hwprobe [v7] In-Reply-To: References: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> Message-ID: On Thu, 11 Sep 2025 01:28:33 GMT, Dingli Zhang wrote: >> Hi, >> Can you help to review this patch? Thanks! >> >> We can extends RISC-V hwprobe support to include `RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`. >> The probed value is recorded in VM_Version::zicboz_block_size and then used to set the zicboz_block_size. >> This ensures correct usage of the Zicboz extension, as block zeroing instructions operate on cache-line granularity. >> >> FYI: https://docs.kernel.org/arch/riscv/hwprobe.html > > Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: > > Unify variable names to correspond with comments Marked as reviewed by mli (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27155#pullrequestreview-3209683990 From mli at openjdk.org Thu Sep 11 08:10:17 2025 From: mli at openjdk.org (Hamlin Li) Date: Thu, 11 Sep 2025 08:10:17 GMT Subject: RFR: 8367066: RISC-V: refine register selection in MacroAssembler:: decode_klass_not_null In-Reply-To: References: <3Xne6ZyEvzrclfVRZbCQf-Hpd7Z09jNTkzAbGrUSAYo=.86349de3-67b2-4358-8ade-717472e4062f@github.com> <3IR_MQMbCC6ixoANmfLZJl0ZXZVE7hmCvGxb5XP3c0s=.aaeda614-d986-483d-8d5a-756dbbe56441@github.com> Message-ID: On Wed, 10 Sep 2025 08:19:46 GMT, Hamlin Li wrote: > Thanks! Thank you for reviewing! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27138#issuecomment-3279053965 From mli at openjdk.org Thu Sep 11 08:10:10 2025 From: mli at openjdk.org (Hamlin Li) Date: Thu, 11 Sep 2025 08:10:10 GMT Subject: RFR: 8367137: RISC-V: Detect Zicboz block size via hwprobe [v4] In-Reply-To: <_4riqp4f0YgofgxEDocHrCY_MoFeeiZCVD2yMu170nE=.f2610544-568c-4ecf-a7b0-9ac6723a98bc@github.com> References: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> <_4riqp4f0YgofgxEDocHrCY_MoFeeiZCVD2yMu170nE=.f2610544-568c-4ecf-a7b0-9ac6723a98bc@github.com> Message-ID: On Thu, 11 Sep 2025 00:01:27 GMT, Dingli Zhang wrote: > > Hey, just curious, if you have the performance data comparison on some device before/after this patch, could you share it? > > Thanks for the review! Unfortunately, I don't have any performance data comparison. However, the latest change is a bugfix, not a performance optimization. Thank you! Looks good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27155#issuecomment-3279063154 From mli at openjdk.org Thu Sep 11 08:10:18 2025 From: mli at openjdk.org (Hamlin Li) Date: Thu, 11 Sep 2025 08:10:18 GMT Subject: Integrated: 8367066: RISC-V: refine register selection in MacroAssembler:: decode_klass_not_null In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 08:57:15 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > > Previously, the register selection in MacroAssembler:: decode_klass_not_null is misleading, better to refine it to improve the readability. > > Thanks! > > Running runtime test tier1/2/3... This pull request has now been integrated. Changeset: 0b3a3030 Author: Hamlin Li URL: https://git.openjdk.org/jdk/commit/0b3a303053d0eb5a98ed3d9df42c659db148b470 Stats: 11 lines in 2 files changed: 2 ins; 5 del; 4 mod 8367066: RISC-V: refine register selection in MacroAssembler:: decode_klass_not_null Reviewed-by: fyang, fjiang ------------- PR: https://git.openjdk.org/jdk/pull/27138 From iwalulya at openjdk.org Thu Sep 11 08:22:52 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 11 Sep 2025 08:22:52 GMT Subject: RFR: 8366865: G1: Allocation GC Pauses Triggered after JVM has started shutdown In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 01:41:46 GMT, David Holmes wrote: >> Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. >> >> Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. >> >> Testing: Tier 1-7 > > src/hotspot/share/gc/shared/collectedHeap.cpp line 616: > >> 614: // If the VM is shutting down, we may have skipped VM_CollectForAllocation. >> 615: // To avoid returning nullptr (which could cause premature OOME), we stall >> 616: // allocation requests here until the VM shutdown is complete. > > If I understand the shutdown sequence correctly, I don't think you can do this without risking a hang. The thread doing the shutdown can potentially execute code that requires allocation after `is_shutting_down()` returns true. This is due to the JVMTI events posted from `before_exit`: > > if (JvmtiExport::should_post_thread_life()) { > JvmtiExport::post_thread_end(thread); > } > > // Always call even when there are not JVMTI environments yet, since environments > // may be attached late and JVMTI must track phases of VM execution > JvmtiExport::post_vm_death(); > > I think if you can't GC during shutdown then you have to simply let the allocation fail. Thanks, I completely overlooked the JVMTI callbacks. It?s probably better to stall with a timeout and then return an allocation failure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2339377413 From aboldtch at openjdk.org Thu Sep 11 08:32:46 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 11 Sep 2025 08:32:46 GMT Subject: RFR: 8367149: Add ergonomic construction for creating ad-hoc VMErrorCallback [v3] In-Reply-To: References: Message-ID: > Add a class OnVMError which uses the VMErrorCallback mechanism which is an ergonomic construction for creating ad-hoc VMErrorCallback which automatically calls the provided invocable f if a VM crash occurs within its lifetime. Can be used to instrument a build for more detailed contextual information gathering. Especially useful when hunting down intermittent bugs, or issues only reproducible in environments where access to a debugger is not readily available. Example use: > ```C++ > { > // Note the lambda is invoked after an error occurs within this thread, > // and during on_error's lifetime. If state prior to the crash is required, > // capture a copy of it first. > auto important_value = get_the_value(); > > OnVMError on_error([&](outputStream* st) { > // Dump the important bits. > st->print("Prior value: "); > important_value.print_on(st); > st->print("During crash: ") > get_the_value().print_on(st); > // Dump whole the whole state. > this->print_on(st); > }); > > // Sometimes doing a thing will crash the VM. > do_a_thing(); > } > > > C++17 class template argument deduction finally makes these sort of constructions ergonomic to use without the need for auto and helper construction methods. Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Replace ergonomic with convenient ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27159/files - new: https://git.openjdk.org/jdk/pull/27159/files/a4fb3397..c6e6ce91 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27159&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27159&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27159.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27159/head:pull/27159 PR: https://git.openjdk.org/jdk/pull/27159 From amitkumar at openjdk.org Thu Sep 11 10:17:54 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 11 Sep 2025 10:17:54 GMT Subject: RFR: 8367325: [s390x] build failure due to JDK-8361376 Message-ID: Fixes the SIGLL caused after [JDK-8361376](https://bugs.openjdk.org/browse/JDK-8361376). Issue was with `cs` instruction, which requires the address to be aligned. And after this change address at which operating was not aligned. Wisdom from Principle of Z Operations: Sytax: CS R1,R3,D2(B2) Sytax: CSY R1,R3,D2(B2) ` The second operand of COMPARE AND SWAP (CS, CSY) must be designated on a word boundary. ` => 0x3fffc3149ba <_ZN17BarrierSetNMethod15set_guard_valueEP7nmethodii+266>: cs %r1,%r4,0(%r3) (gdb) i r r3 r3 0x3ffe500017a 4397593526650 (gdb) p ($r3 % 8) $5 = 2 (gdb) si Thread 16 "C1 CompilerThre" received signal SIGILL, Illegal instruction. NativeMethodBarrier::set_guard_value (bit_mask=2147483647, value=1, this=0x3ffe5000166) at /home/amit/jdk/src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp:74 74 if (v == old_value) break; ------------- Commit messages: - build fix Changes: https://git.openjdk.org/jdk/pull/27213/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27213&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367325 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27213.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27213/head:pull/27213 PR: https://git.openjdk.org/jdk/pull/27213 From aph at openjdk.org Thu Sep 11 10:28:16 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 11 Sep 2025 10:28:16 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 11:38:38 GMT, Thomas Schatzl wrote: > I can argue I was following precedent :) You were, but it's a precedent that needs to die. > I see your point though. What do you suggest to do here? Use `count` throughout instead? Yes, although it might need a couple more comments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2340016401 From mdoerr at openjdk.org Thu Sep 11 10:43:38 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 11 Sep 2025 10:43:38 GMT Subject: RFR: 8367325: [s390x] build failure due to JDK-8361376 In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 09:51:29 GMT, Amit Kumar wrote: > Fixes the SIGLL caused after [JDK-8361376](https://bugs.openjdk.org/browse/JDK-8361376). > > Issue was with `cs` instruction, which requires the address to be aligned. And after this change address at which operating was not aligned. > > Wisdom from Principle of Z Operations: > > Sytax: CS R1,R3,D2(B2) > > Sytax: CSY R1,R3,D2(B2) > > ` > The second operand of COMPARE AND SWAP (CS, CSY) must be designated on a word boundary. > ` > > > > => 0x3fffc3149ba <_ZN17BarrierSetNMethod15set_guard_valueEP7nmethodii+266>: cs %r1,%r4,0(%r3) > (gdb) i r r3 > r3 0x3ffe500017a 4397593526650 > (gdb) p ($r3 % 8) > $5 = 2 > (gdb) si > > Thread 16 "C1 CompilerThre" received signal SIGILL, Illegal instruction. > NativeMethodBarrier::set_guard_value (bit_mask=2147483647, value=1, this=0x3ffe5000166) > at /home/amit/jdk/src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp:74 > 74 if (v == old_value) break; I think `align(4)` would be sufficient. The offset of the immediate field of `cfi` is 3*6+2 = 20 which is already a multiple of 4. Aligning the start of the sequence to 4 should be the right thing. Please add a comment explaining that the immediate field of `cfi` needs to be 4-Byte aligned! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27213#issuecomment-3279845043 From ayang at openjdk.org Thu Sep 11 10:49:38 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 11 Sep 2025 10:49:38 GMT Subject: RFR: 8367149: Add ergonomic construction for creating ad-hoc VMErrorCallback [v3] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 08:32:46 GMT, Axel Boldt-Christmas wrote: >> Add a class OnVMError which uses the VMErrorCallback mechanism which is an ergonomic construction for creating ad-hoc VMErrorCallback which automatically calls the provided invocable f if a VM crash occurs within its lifetime. Can be used to instrument a build for more detailed contextual information gathering. Especially useful when hunting down intermittent bugs, or issues only reproducible in environments where access to a debugger is not readily available. Example use: >> ```C++ >> { >> // Note the lambda is invoked after an error occurs within this thread, >> // and during on_error's lifetime. If state prior to the crash is required, >> // capture a copy of it first. >> auto important_value = get_the_value(); >> >> OnVMError on_error([&](outputStream* st) { >> // Dump the important bits. >> st->print("Prior value: "); >> important_value.print_on(st); >> st->print("During crash: ") >> get_the_value().print_on(st); >> // Dump whole the whole state. >> this->print_on(st); >> }); >> >> // Sometimes doing a thing will crash the VM. >> do_a_thing(); >> } >> >> >> C++17 class template argument deduction finally makes these sort of constructions ergonomic to use without the need for auto and helper construction methods. > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Replace ergonomic with convenient Maybe the title can use "convenient" as well. ------------- Marked as reviewed by ayang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27159#pullrequestreview-3210658042 From coleenp at openjdk.org Thu Sep 11 12:28:03 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 11 Sep 2025 12:28:03 GMT Subject: RFR: 8367368: Add message for verify_legal_class_modifiers for inner classes [v2] In-Reply-To: References: Message-ID: > This adds the inner class name (or unnamed) to the error message for invalid inner class modifiers. > Testing with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/classfile/classFileParser.cpp Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27201/files - new: https://git.openjdk.org/jdk/pull/27201/files/bacb5010..12c5bde8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27201&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27201&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27201.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27201/head:pull/27201 PR: https://git.openjdk.org/jdk/pull/27201 From coleenp at openjdk.org Thu Sep 11 12:34:15 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 11 Sep 2025 12:34:15 GMT Subject: RFR: 8367368: Add message for verify_legal_class_modifiers for inner classes In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 00:46:42 GMT, Chen Liang wrote: >> This adds the inner class name (or unnamed) to the error message for invalid inner class modifiers. >> Testing with tier1-4. > > I think for inner class errors, instead of reporting inner simple name, we should report: > 1. offending class file > 2. the inner class class constant. It is the only identification part that must be present. > 3. the offending data, such as bad flags > > What do you think? The inner class constant is universal because outer class is absent for anonymous/local classes and simple name is absent for anonymous classes. @liach Most of this information is in the message now, except class file name but we don't usually print that. $ java Outer Error: LinkageError occurred while loading main class Outer java.lang.ClassFormatError: Illegal class modifiers in inner class Inner of class Outer: 0x63F ------------- PR Comment: https://git.openjdk.org/jdk/pull/27201#issuecomment-3280379642 From coleenp at openjdk.org Thu Sep 11 12:54:37 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 11 Sep 2025 12:54:37 GMT Subject: RFR: 8367368: Add message for verify_legal_class_modifiers for inner classes [v3] In-Reply-To: References: Message-ID: > This adds the inner class name (or unnamed) to the error message for invalid inner class modifiers. > Testing with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Add comment about illegal modifier flags. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27201/files - new: https://git.openjdk.org/jdk/pull/27201/files/12c5bde8..79a9abe9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27201&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27201&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27201.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27201/head:pull/27201 PR: https://git.openjdk.org/jdk/pull/27201 From coleenp at openjdk.org Thu Sep 11 12:57:50 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 11 Sep 2025 12:57:50 GMT Subject: RFR: 8367368: Add message for verify_legal_class_modifiers for inner classes [v3] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 02:15:06 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add comment about illegal modifier flags. > > src/hotspot/share/classfile/vmSymbols.hpp line 515: > >> 513: template(lockStackSize_name, "lockStackSize") \ >> 514: template(objectWaiter_name, "objectWaiter") \ >> 515: template(unnamed_name, "unnamed") \ > > Shouldn't this use "anonymous" rather than "unnamed"? static String msg2 = "Illegal class modifiers in inner class anonymous of class OuterTest2: 0x63F"; Maybe it needs some brackets or notations or something like [anonymous] or {anonymous}. It probably would be good to have all names in hotspot error messages have '`' notation but I'm not going to change that here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27201#discussion_r2340721984 From ayang at openjdk.org Thu Sep 11 13:02:06 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 11 Sep 2025 13:02:06 GMT Subject: RFR: 8359104: gc/TestAlwaysPreTouchBehavior.java# fails on Linux [v2] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 06:47:01 GMT, Andreas Steiner wrote: >> Get accurate RSS, from smaps_rollup if available(Linux >= 4.14), because the RSS from status is inaccurate especially on systems with more than 32 CPUs. >> >> Not sure if all the additional meminfos like the Pss, Pss_dirty, Pss_Anon, Pss_File, Pss_Shmem, Swap and SwapPss are really needed too. But can be perhaps helpful too. >> >> As the inaccurate memory infos are still used in other methods: >> - [print_process_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2393) >> - [jfr_report_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2686) >> - [trim_native_heap()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L5376) >> >> one can think about to use the accurate values there too. > > Andreas Steiner has updated the pull request incrementally with one additional commit since the last revision: > > extend the accurate rss check Changes requested by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27192#pullrequestreview-3211420343 From ayang at openjdk.org Thu Sep 11 13:02:08 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 11 Sep 2025 13:02:08 GMT Subject: RFR: 8359104: gc/TestAlwaysPreTouchBehavior.java# fails on Linux [v2] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 14:32:01 GMT, Francesco Andreuzzi wrote: >> Andreas Steiner has updated the pull request incrementally with one additional commit since the last revision: >> >> extend the accurate rss check > > src/hotspot/os/linux/os_linux.cpp line 2382: > >> 2380: info->rss = info->pss = info->pssdirty = info->pssanon = >> 2381: info->pssfile = info->pssshmem = info->swap = info->swappss = -1; >> 2382: if (f != nullptr) { > > You could consider inverting this check, and early-return `false` if `f==nullptr`. That would spare one indentation level I agree; the null-check should be done right after `fopen` to early-return if sth is wrong. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27192#discussion_r2340739739 From VicWang at zhaoxin.com Thu Sep 11 13:33:36 2025 From: VicWang at zhaoxin.com (Vic Wang(BJ-RD)) Date: Thu, 11 Sep 2025 13:33:36 +0000 Subject: Improve UseAVX setting and add cpu descriptions for zhaoxin processors. Message-ID: Hi All Here is the patch that improving the UseAVX setting and add cpu descriptions for zhaoxin processors. Can you help to review the patch and assign a number for a pull request? Thank you! Patch in my fork repository: https://github.com/Double-Minds-JV/jdk/commit/06498b42ed54021b3ed14a9ccc9adf52e9360c9c >diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp b/src/hotspot/cpu/x86/vm_version_x86.cpp >index 094ab370190..4043b29f18c 100644 >--- a/src/hotspot/cpu/x86/vm_version_x86.cpp >+++ b/src/hotspot/cpu/x86/vm_version_x86.cpp >@@ -931,9 +931,17 @@ void VM_Version::get_processor_features() { > if (UseSSE < 1) > _features.clear_feature(CPU_SSE); > >- //since AVX instructions is slower than SSE in some ZX cpus, force USEAVX=0. >- if (is_zx() && ((cpu_family() == 6) || (cpu_family() == 7))) { >- UseAVX = 0; >+ // ZX cpus specific settings >+ if (is_zx() && FLAG_IS_DEFAULT(UseAVX)) { >+ if (cpu_family() == 7) { >+ if (extended_cpu_model() == 0x5B || extended_cpu_model() == 0x6B) { >+ UseAVX = 1; >+ } else if (extended_cpu_model() == 0x1B || extended_cpu_model() == 0x3B) { >+ UseAVX = 0; >+ } >+ } else if (cpu_family() == 6) { >+ UseAVX = 0; >+ } > } > > // UseSSE is set to the smaller of what hardware supports and what >@@ -2592,6 +2600,7 @@ void VM_Version::resolve_cpu_information_details(void) { > > const char* VM_Version::cpu_family_description(void) { > int cpu_family_id = extended_cpu_family(); >+ int cpu_model_id = extended_cpu_model(); > if (is_amd()) { > if (cpu_family_id < ExtendedFamilyIdLength_AMD) { > return _family_id_amd[cpu_family_id]; >@@ -2605,6 +2614,22 @@ const char* VM_Version::cpu_family_description(void) { > return _family_id_intel[cpu_family_id]; > } > } >+ if (is_zx()) { >+ if (cpu_family_id == 7) { >+ switch (cpu_model_id) { >+ case 0x1B: >+ return "wudaokou"; >+ case 0x3B: >+ return "lujiazui"; >+ case 0x5B: >+ return "yongfeng"; >+ case 0x6B: >+ return "shijidadao"; >+ } >+ } else if (cpu_family_id == 6) { >+ return "zhangjiang"; >+ } >+ } > if (is_hygon()) { > return "Dhyana"; > } >@@ -2624,6 +2649,9 @@ int VM_Version::cpu_type_description(char* const buf, size_t buf_len) { > } else if (is_amd()) { > cpu_type = "AMD"; > x64 = cpu_is_em64t() ? " AMD64" : ""; >+ } else if (is_zx()) { >+ cpu_type = "Zhaoxin"; >+ x64 = cpu_is_em64t() ? " x86_64" : ""; > } else if (is_hygon()) { > cpu_type = "Hygon"; > x64 = cpu_is_em64t() ? " AMD64" : ""; >@@ -3236,6 +3264,12 @@ int VM_Version::allocate_prefetch_distance(bool use_watermark_prefetch) { > } else { > return 128; // Athlon > } >+ } else if (is_zx()) { >+ if (supports_sse2()) { >+ return 256; >+ } else { >+ return 128; >+ } > } else { // Intel > if (supports_sse3() && is_intel_server_family()) { > if (supports_sse4_2() && supports_ht()) { // Nehalem based cpus I have run the jtreg tests after applying the patch, the test-summary shows follows: >============================== >Test summary >============================== > TEST TOTAL PASS FAIL ERROR SKIP > jtreg:test/hotspot/jtreg:tier1 3107 2797 0 0 310 > jtreg:test/jdk:tier1 2513 2472 0 0 41 > jtreg:test/langtools:tier1 4668 4656 0 0 12 > jtreg:test/jaxp:tier1 0 0 0 0 0 > jtreg:test/lib-test:tier1 38 38 0 0 0 >============================== >TEST SUCCESS Best Regards! Vic Wang ????? ????????????????????????????????????????????????????? CONFIDENTIAL NOTE: This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited. From coleenp at openjdk.org Thu Sep 11 13:43:51 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 11 Sep 2025 13:43:51 GMT Subject: RFR: 8367368: Add message for verify_legal_class_modifiers for inner classes [v4] In-Reply-To: References: Message-ID: > This adds the inner class name (or unnamed) to the error message for invalid inner class modifiers. > Testing with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Reworded error message for anonymous inner classes to make more sense. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27201/files - new: https://git.openjdk.org/jdk/pull/27201/files/79a9abe9..a8e655a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27201&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27201&range=02-03 Stats: 24 lines in 4 files changed: 10 ins; 1 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/27201.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27201/head:pull/27201 PR: https://git.openjdk.org/jdk/pull/27201 From asteiner at openjdk.org Thu Sep 11 14:32:19 2025 From: asteiner at openjdk.org (Andreas Steiner) Date: Thu, 11 Sep 2025 14:32:19 GMT Subject: RFR: 8359104: gc/TestAlwaysPreTouchBehavior.java# fails on Linux [v3] In-Reply-To: References: Message-ID: > Get accurate RSS, from smaps_rollup if available(Linux >= 4.14), because the RSS from status is inaccurate especially on systems with more than 32 CPUs. > > Not sure if all the additional meminfos like the Pss, Pss_dirty, Pss_Anon, Pss_File, Pss_Shmem, Swap and SwapPss are really needed too. But can be perhaps helpful too. > > As the inaccurate memory infos are still used in other methods: > - [print_process_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2393) > - [jfr_report_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2686) > - [trim_native_heap()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L5376) > > one can think about to use the accurate values there too. Andreas Steiner has updated the pull request incrementally with one additional commit since the last revision: Changed num_found and num_values to size_t, do the null-check right after the fopen and return early, eliminated the variable shadowing of info ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27192/files - new: https://git.openjdk.org/jdk/pull/27192/files/97d88b64..6c6fc40e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27192&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27192&range=01-02 Stats: 27 lines in 1 file changed: 5 ins; 3 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/27192.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27192/head:pull/27192 PR: https://git.openjdk.org/jdk/pull/27192 From mbaesken at openjdk.org Thu Sep 11 14:32:19 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 11 Sep 2025 14:32:19 GMT Subject: RFR: 8359104: gc/TestAlwaysPreTouchBehavior.java# fails on Linux [v3] In-Reply-To: References: Message-ID: <5xaY_spQIDWHvpTxxS-aSIezGRG6X6980W9qCZUXvzg=.07b03913-d7a5-46ad-a41e-f77d1d2299e5@github.com> On Thu, 11 Sep 2025 14:29:27 GMT, Andreas Steiner wrote: >> Get accurate RSS, from smaps_rollup if available(Linux >= 4.14), because the RSS from status is inaccurate especially on systems with more than 32 CPUs. >> >> Not sure if all the additional meminfos like the Pss, Pss_dirty, Pss_Anon, Pss_File, Pss_Shmem, Swap and SwapPss are really needed too. But can be perhaps helpful too. >> >> As the inaccurate memory infos are still used in other methods: >> - [print_process_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2393) >> - [jfr_report_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2686) >> - [trim_native_heap()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L5376) >> >> one can think about to use the accurate values there too. > > Andreas Steiner has updated the pull request incrementally with one additional commit since the last revision: > > Changed num_found and num_values to size_t, do the null-check right after the fopen and return early, eliminated the variable shadowing of info Looks still good (and even better than before) ! ------------- Marked as reviewed by mbaesken (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27192#pullrequestreview-3211973683 From asteiner at openjdk.org Thu Sep 11 14:32:22 2025 From: asteiner at openjdk.org (Andreas Steiner) Date: Thu, 11 Sep 2025 14:32:22 GMT Subject: RFR: 8359104: gc/TestAlwaysPreTouchBehavior.java# fails on Linux [v3] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 14:32:54 GMT, Francesco Andreuzzi wrote: >> Andreas Steiner has updated the pull request incrementally with one additional commit since the last revision: >> >> Changed num_found and num_values to size_t, do the null-check right after the fopen and return early, eliminated the variable shadowing of info > > src/hotspot/os/linux/os_linux.cpp line 2377: > >> 2375: bool os::Linux::query_accurate_process_memory_info(os::Linux::accurate_meminfo_t* info) { >> 2376: FILE* f = os::fopen("/proc/self/smaps_rollup", "r"); >> 2377: const int num_values = sizeof(os::Linux::accurate_meminfo_t) / sizeof(size_t); > > Should this and `num_found` be `size_t`? Even this was copied from the existing query_process_memory_info I adapted this now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27192#discussion_r2341147963 From asteiner at openjdk.org Thu Sep 11 14:32:23 2025 From: asteiner at openjdk.org (Andreas Steiner) Date: Thu, 11 Sep 2025 14:32:23 GMT Subject: RFR: 8359104: gc/TestAlwaysPreTouchBehavior.java# fails on Linux [v3] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 12:58:55 GMT, Albert Mingkun Yang wrote: >> src/hotspot/os/linux/os_linux.cpp line 2382: >> >>> 2380: info->rss = info->pss = info->pssdirty = info->pssanon = >>> 2381: info->pssfile = info->pssshmem = info->swap = info->swappss = -1; >>> 2382: if (f != nullptr) { >> >> You could consider inverting this check, and early-return `false` if `f==nullptr`. That would spare one indentation level > > I agree; the null-check should be done right after `fopen` to early-return if sth is wrong. Even this was copied from the existing query_process_memory_info I adapted this now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27192#discussion_r2341149494 From ayang at openjdk.org Thu Sep 11 14:48:01 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 11 Sep 2025 14:48:01 GMT Subject: RFR: 8359104: gc/TestAlwaysPreTouchBehavior.java# fails on Linux [v3] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 14:32:19 GMT, Andreas Steiner wrote: >> Get accurate RSS, from smaps_rollup if available(Linux >= 4.14), because the RSS from status is inaccurate especially on systems with more than 32 CPUs. >> >> Not sure if all the additional meminfos like the Pss, Pss_dirty, Pss_Anon, Pss_File, Pss_Shmem, Swap and SwapPss are really needed too. But can be perhaps helpful too. >> >> As the inaccurate memory infos are still used in other methods: >> - [print_process_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2393) >> - [jfr_report_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2686) >> - [trim_native_heap()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L5376) >> >> one can think about to use the accurate values there too. > > Andreas Steiner has updated the pull request incrementally with one additional commit since the last revision: > > Changed num_found and num_values to size_t, do the null-check right after the fopen and return early, eliminated the variable shadowing of info Marked as reviewed by ayang (Reviewer). src/hotspot/os/linux/os_linux.cpp line 2395: > 2393: (info->pssshmem == -1 && sscanf(buf, "Pss_Shmem: %zd kB", &info->pssshmem) == 1) || > 2394: (info->swap == -1 && sscanf(buf, "Swap: %zd kB", &info->swap) == 1) || > 2395: (info->swappss == -1 && sscanf(buf, "SwapPss: %zd kB", &info->swappss) == 1) I'd probably align `== -1 &&` and `==1)`. ------------- PR Review: https://git.openjdk.org/jdk/pull/27192#pullrequestreview-3212076914 PR Review Comment: https://git.openjdk.org/jdk/pull/27192#discussion_r2341228607 From coleenp at openjdk.org Thu Sep 11 18:14:57 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 11 Sep 2025 18:14:57 GMT Subject: RFR: 8367368: Add message for verify_legal_class_modifiers for inner classes [v5] In-Reply-To: References: Message-ID: <2IsSbuyOwrA9e4E47_sbgNaYledCEI4aFwdLL3IpH90=.c70ccf22-c964-472f-bc24-f14da9fc475d@github.com> > This adds the inner class name (or unnamed) to the error message for invalid inner class modifiers. > Testing with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Only test for message fragments - Chen's comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27201/files - new: https://git.openjdk.org/jdk/pull/27201/files/a8e655a4..c6467742 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27201&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27201&range=03-04 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27201.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27201/head:pull/27201 PR: https://git.openjdk.org/jdk/pull/27201 From iklam at openjdk.org Thu Sep 11 18:34:06 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 11 Sep 2025 18:34:06 GMT Subject: RFR: 8367142: Avoid InstanceKlass::cast when converting java mirror to InstanceKlass [v3] In-Reply-To: <5c8zxQ36O0VJk5X7lu5QRuh7LhM49ZdpUTmDV-qc2l4=.9a4c2d95-9a0a-4ba6-8f73-b05e90030f6e@github.com> References: <3Xh3sS0I7pp0fslgQndt4CLqddxga7W8c11tuZkNgd8=.b5a28dba-05f1-49d9-80f8-6260a9772287@github.com> <5c8zxQ36O0VJk5X7lu5QRuh7LhM49ZdpUTmDV-qc2l4=.9a4c2d95-9a0a-4ba6-8f73-b05e90030f6e@github.com> Message-ID: On Thu, 11 Sep 2025 06:44:51 GMT, Stefan Karlsson wrote: > > I didn't realize that my attempt to remove the JNIHandles::resolve() boilerplate can be conversional. > > Removing boilerplate wasn't controversial. Spreading the j* types can be seen as controversial give that we have various efforts to push those types out to the boundaries of the JVM. Adding new convenience functions that accept j* goes in the opposite direction. > > > I can't put a helper function in jni.cpp because this pattern is used in several files. > > But almost all are in jni.cpp and jvm.cpp and you can get rid of most of the boilerplate code by adding local helpers there. The handfulish of other places could keep their explicit usage of JNIHandles::resolve* calls. Maybe in a different PR. I want to keep the current PR simple. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27158#issuecomment-3282181436 From dlong at openjdk.org Thu Sep 11 20:20:25 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 11 Sep 2025 20:20:25 GMT Subject: RFR: 8367325: [s390x] build failure due to JDK-8361376 In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 09:51:29 GMT, Amit Kumar wrote: > Fixes the SIGLL caused after [JDK-8361376](https://bugs.openjdk.org/browse/JDK-8361376). > > Issue was with `cs` instruction, which requires the address to be aligned. And after this change address at which operating was not aligned. > > Wisdom from Principle of Z Operations: > > Sytax: CS R1,R3,D2(B2) > > Sytax: CSY R1,R3,D2(B2) > > ` > The second operand of COMPARE AND SWAP (CS, CSY) must be designated on a word boundary. > ` > > > > => 0x3fffc3149ba <_ZN17BarrierSetNMethod15set_guard_valueEP7nmethodii+266>: cs %r1,%r4,0(%r3) > (gdb) i r r3 > r3 0x3ffe500017a 4397593526650 > (gdb) p ($r3 % 8) > $5 = 2 > (gdb) si > > Thread 16 "C1 CompilerThre" received signal SIGILL, Illegal instruction. > NativeMethodBarrier::set_guard_value (bit_mask=2147483647, value=1, this=0x3ffe5000166) > at /home/amit/jdk/src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp:74 > 74 if (v == old_value) break; src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp line 174: > 172: void BarrierSetAssembler::nmethod_entry_barrier(MacroAssembler* masm) { > 173: BarrierSetNMethod* bs_nm = BarrierSet::barrier_set()->barrier_set_nmethod(); > 174: __ align(8); // must align the following block which requires atomic updates Thanks for fixing this. Rather than aligning at the start, wouldn't it be more maintainable to do `__ align(4, offset() + 2);` before the z_cfi? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27213#discussion_r2342239302 From dholmes at openjdk.org Thu Sep 11 21:35:20 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 11 Sep 2025 21:35:20 GMT Subject: RFR: 8367368: Add message for verify_legal_class_modifiers for inner classes [v5] In-Reply-To: <2IsSbuyOwrA9e4E47_sbgNaYledCEI4aFwdLL3IpH90=.c70ccf22-c964-472f-bc24-f14da9fc475d@github.com> References: <2IsSbuyOwrA9e4E47_sbgNaYledCEI4aFwdLL3IpH90=.c70ccf22-c964-472f-bc24-f14da9fc475d@github.com> Message-ID: On Thu, 11 Sep 2025 18:14:57 GMT, Coleen Phillimore wrote: >> This adds the inner class name (or unnamed) to the error message for invalid inner class modifiers. >> Testing with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Only test for message fragments - Chen's comments. src/hotspot/share/classfile/classFileParser.cpp line 4316: > 4314: ); > 4315: } else { > 4316: if (is_anonymous_inner_class) { I think you could have just defined "" as a default name to use here rather then explicitly passing in the parameter. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27201#discussion_r2342385187 From mdoerr at openjdk.org Thu Sep 11 22:16:09 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 11 Sep 2025 22:16:09 GMT Subject: RFR: 8367325: [s390x] build failure due to JDK-8361376 In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 20:17:24 GMT, Dean Long wrote: >> Fixes the SIGLL caused after [JDK-8361376](https://bugs.openjdk.org/browse/JDK-8361376). >> >> Issue was with `cs` instruction, which requires the address to be aligned. And after this change address at which operating was not aligned. >> >> Wisdom from Principle of Z Operations: >> >> Sytax: CS R1,R3,D2(B2) >> >> Sytax: CSY R1,R3,D2(B2) >> >> ` >> The second operand of COMPARE AND SWAP (CS, CSY) must be designated on a word boundary. >> ` >> >> >> >> => 0x3fffc3149ba <_ZN17BarrierSetNMethod15set_guard_valueEP7nmethodii+266>: cs %r1,%r4,0(%r3) >> (gdb) i r r3 >> r3 0x3ffe500017a 4397593526650 >> (gdb) p ($r3 % 8) >> $5 = 2 >> (gdb) si >> >> Thread 16 "C1 CompilerThre" received signal SIGILL, Illegal instruction. >> NativeMethodBarrier::set_guard_value (bit_mask=2147483647, value=1, this=0x3ffe5000166) >> at /home/amit/jdk/src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp:74 >> 74 if (v == old_value) break; > > src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp line 174: > >> 172: void BarrierSetAssembler::nmethod_entry_barrier(MacroAssembler* masm) { >> 173: BarrierSetNMethod* bs_nm = BarrierSet::barrier_set()->barrier_set_nmethod(); >> 174: __ align(8); // must align the following block which requires atomic updates > > Thanks for fixing this. Rather than aligning at the start, wouldn't it be more maintainable to do > `__ align(4, offset() + 2);` > before the z_cfi? That would require much more changes. The barrier sequence is expected to have a fixed size. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27213#discussion_r2342448153 From dlong at openjdk.org Fri Sep 12 00:26:22 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 12 Sep 2025 00:26:22 GMT Subject: RFR: 8367325: [s390x] build failure due to JDK-8361376 In-Reply-To: References: Message-ID: <6M1CuZ1hFWFJyT-diBc59BSsdr3YuQvZn_rtSc8LP0Q=.608a5dd6-6ed7-44bf-a840-9e89d3b8d742@github.com> On Thu, 11 Sep 2025 22:13:25 GMT, Martin Doerr wrote: >> src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp line 174: >> >>> 172: void BarrierSetAssembler::nmethod_entry_barrier(MacroAssembler* masm) { >>> 173: BarrierSetNMethod* bs_nm = BarrierSet::barrier_set()->barrier_set_nmethod(); >>> 174: __ align(8); // must align the following block which requires atomic updates >> >> Thanks for fixing this. Rather than aligning at the start, wouldn't it be more maintainable to do >> `__ align(4, offset() + 2);` >> before the z_cfi? > > That would require much more changes. The barrier sequence is expected to have a fixed size. OK, then how about we align the beginning using ` __ align(4, offset() + 3*6 + 2);` to make it more self-documenting? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27213#discussion_r2342632201 From dholmes at openjdk.org Fri Sep 12 00:36:09 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 12 Sep 2025 00:36:09 GMT Subject: RFR: 8367368: Add message for verify_legal_class_modifiers for inner classes [v5] In-Reply-To: <2IsSbuyOwrA9e4E47_sbgNaYledCEI4aFwdLL3IpH90=.c70ccf22-c964-472f-bc24-f14da9fc475d@github.com> References: <2IsSbuyOwrA9e4E47_sbgNaYledCEI4aFwdLL3IpH90=.c70ccf22-c964-472f-bc24-f14da9fc475d@github.com> Message-ID: On Thu, 11 Sep 2025 18:14:57 GMT, Coleen Phillimore wrote: >> This adds the inner class name (or unnamed) to the error message for invalid inner class modifiers. >> Testing with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Only test for message fragments - Chen's comments. Looks fine. I actually needed this fix yesterday when looking at a bug report that had been mislead by this error message. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27201#pullrequestreview-3214090432 From david.holmes at oracle.com Fri Sep 12 01:06:15 2025 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Sep 2025 11:06:15 +1000 Subject: Improve UseAVX setting and add cpu descriptions for zhaoxin processors. In-Reply-To: References: Message-ID: <58756de5-86a3-4963-a3ae-105455d1fbd0@oracle.com> Hi Vic, It has been a long time since we heard from you. :) I have filed a JBS issue for this update: https://bugs.openjdk.org/browse/JDK-8367478 Cheers, David On 11/09/2025 11:33 pm, Vic Wang(BJ-RD) wrote: > Hi All > > Here is the patch that improving the UseAVX setting and add cpu descriptions for zhaoxin processors. > Can you help to review the patch and assign a number for a pull request? > Thank you! > > > Patch in my fork repository: > https://github.com/Double-Minds-JV/jdk/commit/06498b42ed54021b3ed14a9ccc9adf52e9360c9c > >> diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp b/src/hotspot/cpu/x86/vm_version_x86.cpp >> index 094ab370190..4043b29f18c 100644 >> --- a/src/hotspot/cpu/x86/vm_version_x86.cpp >> +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp >> @@ -931,9 +931,17 @@ void VM_Version::get_processor_features() { >> if (UseSSE < 1) >> _features.clear_feature(CPU_SSE); >> >> - //since AVX instructions is slower than SSE in some ZX cpus, force USEAVX=0. >> - if (is_zx() && ((cpu_family() == 6) || (cpu_family() == 7))) { >> - UseAVX = 0; >> + // ZX cpus specific settings >> + if (is_zx() && FLAG_IS_DEFAULT(UseAVX)) { >> + if (cpu_family() == 7) { >> + if (extended_cpu_model() == 0x5B || extended_cpu_model() == 0x6B) { >> + UseAVX = 1; >> + } else if (extended_cpu_model() == 0x1B || extended_cpu_model() == 0x3B) { >> + UseAVX = 0; >> + } >> + } else if (cpu_family() == 6) { >> + UseAVX = 0; >> + } >> } >> >> // UseSSE is set to the smaller of what hardware supports and what >> @@ -2592,6 +2600,7 @@ void VM_Version::resolve_cpu_information_details(void) { >> >> const char* VM_Version::cpu_family_description(void) { >> int cpu_family_id = extended_cpu_family(); >> + int cpu_model_id = extended_cpu_model(); >> if (is_amd()) { >> if (cpu_family_id < ExtendedFamilyIdLength_AMD) { >> return _family_id_amd[cpu_family_id]; >> @@ -2605,6 +2614,22 @@ const char* VM_Version::cpu_family_description(void) { >> return _family_id_intel[cpu_family_id]; >> } >> } >> + if (is_zx()) { >> + if (cpu_family_id == 7) { >> + switch (cpu_model_id) { >> + case 0x1B: >> + return "wudaokou"; >> + case 0x3B: >> + return "lujiazui"; >> + case 0x5B: >> + return "yongfeng"; >> + case 0x6B: >> + return "shijidadao"; >> + } >> + } else if (cpu_family_id == 6) { >> + return "zhangjiang"; >> + } >> + } >> if (is_hygon()) { >> return "Dhyana"; >> } >> @@ -2624,6 +2649,9 @@ int VM_Version::cpu_type_description(char* const buf, size_t buf_len) { >> } else if (is_amd()) { >> cpu_type = "AMD"; >> x64 = cpu_is_em64t() ? " AMD64" : ""; >> + } else if (is_zx()) { >> + cpu_type = "Zhaoxin"; >> + x64 = cpu_is_em64t() ? " x86_64" : ""; >> } else if (is_hygon()) { >> cpu_type = "Hygon"; >> x64 = cpu_is_em64t() ? " AMD64" : ""; >> @@ -3236,6 +3264,12 @@ int VM_Version::allocate_prefetch_distance(bool use_watermark_prefetch) { >> } else { >> return 128; // Athlon >> } >> + } else if (is_zx()) { >> + if (supports_sse2()) { >> + return 256; >> + } else { >> + return 128; >> + } >> } else { // Intel >> if (supports_sse3() && is_intel_server_family()) { >> if (supports_sse4_2() && supports_ht()) { // Nehalem based cpus > > I have run the jtreg tests after applying the patch, the test-summary shows follows: >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR SKIP >> jtreg:test/hotspot/jtreg:tier1 3107 2797 0 0 310 >> jtreg:test/jdk:tier1 2513 2472 0 0 41 >> jtreg:test/langtools:tier1 4668 4656 0 0 12 >> jtreg:test/jaxp:tier1 0 0 0 0 0 >> jtreg:test/lib-test:tier1 38 38 0 0 0 >> ============================== >> TEST SUCCESS > > Best Regards! > Vic Wang > > > ????? > ????????????????????????????????????????????????????? > CONFIDENTIAL NOTE: > This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited. From kbarrett at openjdk.org Fri Sep 12 01:21:35 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 12 Sep 2025 01:21:35 GMT Subject: RFR: 8252582: HotSpot Style Guide should permit variable templates Message-ID: Please review this change to the HotSpot Style Guide to permit the use of variable templates. This is a C++14 feature that, while fairly simple, didn't get into the initial permitted for HotSpot list because I just didn't get to it and nobody asked for it. And it has languished on the "undecided" list for the same reasons. But recently I've had reason to want to use this feature a couple of times, so I'm now proposing we allow it. I merged it into the section for Inline Variables (a C++17 feature), as the two are closely related. Variable templates were even listed as one of the workarounds being used to make up for the lack of inline variables. ------------- Commit messages: - permit variable templates Changes: https://git.openjdk.org/jdk/pull/27240/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27240&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8252582 Stats: 50 lines in 2 files changed: 15 ins; 7 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/27240.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27240/head:pull/27240 PR: https://git.openjdk.org/jdk/pull/27240 From dholmes at openjdk.org Fri Sep 12 02:04:14 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 12 Sep 2025 02:04:14 GMT Subject: RFR: 8252582: HotSpot Style Guide should permit variable templates In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 01:13:25 GMT, Kim Barrett wrote: > Please review this change to the HotSpot Style Guide to permit the use of > variable templates. This is a C++14 feature that, while fairly simple, didn't > get into the initial permitted for HotSpot list because I just didn't get to > it and nobody asked for it. And it has languished on the "undecided" list for > the same reasons. But recently I've had reason to want to use this feature a > couple of times, so I'm now proposing we allow it. > > I merged it into the section for Inline Variables (a C++17 feature), as the > two are closely related. Variable templates were even listed as one of the > workarounds being used to make up for the lack of inline variables. Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27240#pullrequestreview-3214349356 From dholmes at openjdk.org Fri Sep 12 02:32:23 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 12 Sep 2025 02:32:23 GMT Subject: RFR: 8367282: FORBID_C_FUNCTION needs exception spec consistent with library declaration [v2] In-Reply-To: References: Message-ID: <_VAMNbQHOwGNpioqyx4EM3TVpb1zHcJ_hrDK0HZdhaQ=.57ea6460-d0d6-4181-8275-8d3c5575bc83@github.com> On Thu, 11 Sep 2025 04:11:29 GMT, Kim Barrett wrote: >> Please review this change to FORBID_C_FUNCTION to make the exception specs of >> the forbidding declarations match up with the exception specs of the >> associated library declarations. This needs to account for different platform >> libraries either having or not having exception specs. It's needed because, >> after switching to C++17, some compilers complain about some differences in >> the exception specs. >> >> Also removed the workaround for JDK-8367051, which should no longer be needed >> after this change. >> >> Hoping someone will test the aix-ppc port. @MBaesken or @TheRealMDoerr ? >> >> Testing: mach5 tier1, GHA sanity checks (nearly finished) >> Locally (linux-aarch64) built with clang, which failed without the JDK-8367051 >> workaround. > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > work around AIX noexcept inconsistencies Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27180#pullrequestreview-3214389302 From dzhang at openjdk.org Fri Sep 12 03:11:47 2025 From: dzhang at openjdk.org (Dingli Zhang) Date: Fri, 12 Sep 2025 03:11:47 GMT Subject: RFR: 8367137: RISC-V: Detect Zicboz block size via hwprobe [v7] In-Reply-To: References: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> Message-ID: <4ISbM39NbN_xOlo974uj5Mq7EhlUlyO1LCEGOe-T6wM=.1a74b42a-4fd1-4e0a-a082-f60a0deca7df@github.com> On Thu, 11 Sep 2025 01:28:33 GMT, Dingli Zhang wrote: >> Hi, >> Can you help to review this patch? Thanks! >> >> We can extends RISC-V hwprobe support to include `RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`. >> The probed value is recorded in VM_Version::zicboz_block_size and then used to set the zicboz_block_size. >> This ensures correct usage of the Zicboz extension, as block zeroing instructions operate on cache-line granularity. >> >> FYI: https://docs.kernel.org/arch/riscv/hwprobe.html > > Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: > > Unify variable names to correspond with comments Thanks all for the review! PS: hotspot:tier1 tested on OPi RV2 with `UseZicboz` (running kernel 6.15.2-spacemit-k1) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27155#issuecomment-3283485565 From duke at openjdk.org Fri Sep 12 03:11:47 2025 From: duke at openjdk.org (duke) Date: Fri, 12 Sep 2025 03:11:47 GMT Subject: RFR: 8367137: RISC-V: Detect Zicboz block size via hwprobe [v7] In-Reply-To: References: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> Message-ID: On Thu, 11 Sep 2025 01:28:33 GMT, Dingli Zhang wrote: >> Hi, >> Can you help to review this patch? Thanks! >> >> We can extends RISC-V hwprobe support to include `RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`. >> The probed value is recorded in VM_Version::zicboz_block_size and then used to set the zicboz_block_size. >> This ensures correct usage of the Zicboz extension, as block zeroing instructions operate on cache-line granularity. >> >> FYI: https://docs.kernel.org/arch/riscv/hwprobe.html > > Dingli Zhang has updated the pull request incrementally with one additional commit since the last revision: > > Unify variable names to correspond with comments @DingliZhang Your change (at version 4f6a75b8a626bfe6b6f4bc706437c4d59148c98a) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27155#issuecomment-3283487425 From VicWang at zhaoxin.com Fri Sep 12 03:19:31 2025 From: VicWang at zhaoxin.com (Vic Wang(BJ-RD)) Date: Fri, 12 Sep 2025 03:19:31 +0000 Subject: =?utf-8?B?5Zue5aSNOiBJbXByb3ZlIFVzZUFWWCBzZXR0aW5nIGFuZCBhZGQgY3B1IGRl?= =?utf-8?Q?scriptions_for_zhaoxin_processors.?= In-Reply-To: <58756de5-86a3-4963-a3ae-105455d1fbd0@oracle.com> References: <58756de5-86a3-4963-a3ae-105455d1fbd0@oracle.com> Message-ID: <8e3eab4683d34791955eac618775cea3@zhaoxin.com> Hi David, I have submitted a PR, please help to review: https://github.com/openjdk/jdk/pull/27241 It shows "OCA signatory status must be verified". My employer, Shanghai Zhaoxin Semiconductor, has already signed the OCA, and it can be found on http://oca.opensource.oracle.com. Please help me with this issue. Best Regards! Vic Wang >-----????----- >???: David Holmes >????: 2025?9?12? 9:06 >???: Vic Wang(BJ-RD) ; hotspot-dev at openjdk.org >??: Re: Improve UseAVX setting and add cpu descriptions for zhaoxin processors. > > >Hi Vic, > >It has been a long time since we heard from you. :) > >I have filed a JBS issue for this update: > >https://bugs.openjdk.org/browse/JDK-8367478 > >Cheers, >David > >On 11/09/2025 11:33 pm, Vic Wang(BJ-RD) wrote: >> Hi All >> >> Here is the patch that improving the UseAVX setting and add cpu descriptions for zhaoxin processors. >> Can you help to review the patch and assign a number for a pull request? >> Thank you! >> >> >> Patch in my fork repository: >> https://github.com/Double-Minds-JV/jdk/commit/06498b42ed54021b3ed14a9c >> cc9adf52e9360c9c >> >>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp >>> b/src/hotspot/cpu/x86/vm_version_x86.cpp >>> index 094ab370190..4043b29f18c 100644 >>> --- a/src/hotspot/cpu/x86/vm_version_x86.cpp >>> +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp >>> @@ -931,9 +931,17 @@ void VM_Version::get_processor_features() { >>> if (UseSSE < 1) >>> _features.clear_feature(CPU_SSE); >>> >>> - //since AVX instructions is slower than SSE in some ZX cpus, force USEAVX=0. >>> - if (is_zx() && ((cpu_family() == 6) || (cpu_family() == 7))) { >>> - UseAVX = 0; >>> + // ZX cpus specific settings >>> + if (is_zx() && FLAG_IS_DEFAULT(UseAVX)) { >>> + if (cpu_family() == 7) { >>> + if (extended_cpu_model() == 0x5B || extended_cpu_model() == 0x6B) { >>> + UseAVX = 1; >>> + } else if (extended_cpu_model() == 0x1B || extended_cpu_model() == 0x3B) { >>> + UseAVX = 0; >>> + } >>> + } else if (cpu_family() == 6) { >>> + UseAVX = 0; >>> + } >>> } >>> >>> // UseSSE is set to the smaller of what hardware supports and what >>> @@ -2592,6 +2600,7 @@ void >>> VM_Version::resolve_cpu_information_details(void) { >>> >>> const char* VM_Version::cpu_family_description(void) { >>> int cpu_family_id = extended_cpu_family(); >>> + int cpu_model_id = extended_cpu_model(); >>> if (is_amd()) { >>> if (cpu_family_id < ExtendedFamilyIdLength_AMD) { >>> return _family_id_amd[cpu_family_id]; @@ -2605,6 +2614,22 @@ >>> const char* VM_Version::cpu_family_description(void) { >>> return _family_id_intel[cpu_family_id]; >>> } >>> } >>> + if (is_zx()) { >>> + if (cpu_family_id == 7) { >>> + switch (cpu_model_id) { >>> + case 0x1B: >>> + return "wudaokou"; >>> + case 0x3B: >>> + return "lujiazui"; >>> + case 0x5B: >>> + return "yongfeng"; >>> + case 0x6B: >>> + return "shijidadao"; >>> + } >>> + } else if (cpu_family_id == 6) { >>> + return "zhangjiang"; >>> + } >>> + } >>> if (is_hygon()) { >>> return "Dhyana"; >>> } >>> @@ -2624,6 +2649,9 @@ int VM_Version::cpu_type_description(char* const buf, size_t buf_len) { >>> } else if (is_amd()) { >>> cpu_type = "AMD"; >>> x64 = cpu_is_em64t() ? " AMD64" : ""; >>> + } else if (is_zx()) { >>> + cpu_type = "Zhaoxin"; >>> + x64 = cpu_is_em64t() ? " x86_64" : ""; >>> } else if (is_hygon()) { >>> cpu_type = "Hygon"; >>> x64 = cpu_is_em64t() ? " AMD64" : ""; @@ -3236,6 +3264,12 @@ int >>> VM_Version::allocate_prefetch_distance(bool use_watermark_prefetch) { >>> } else { >>> return 128; // Athlon >>> } >>> + } else if (is_zx()) { >>> + if (supports_sse2()) { >>> + return 256; >>> + } else { >>> + return 128; >>> + } >>> } else { // Intel >>> if (supports_sse3() && is_intel_server_family()) { >>> if (supports_sse4_2() && supports_ht()) { // Nehalem based >>> cpus >> >> I have run the jtreg tests after applying the patch, the test-summary shows follows: >>> ============================== >>> Test summary >>> ============================== >>> TEST TOTAL PASS FAIL ERROR SKIP >>> jtreg:test/hotspot/jtreg:tier1 3107 2797 0 0 310 >>> jtreg:test/jdk:tier1 2513 2472 0 0 41 >>> jtreg:test/langtools:tier1 4668 4656 0 0 12 >>> jtreg:test/jaxp:tier1 0 0 0 0 0 >>> jtreg:test/lib-test:tier1 38 38 0 0 0 >>> ============================== >>> TEST SUCCESS >> >> Best Regards! >> Vic Wang >> >> >> ????? >> ????????????????????????????????????????????????????? >> CONFIDENTIAL NOTE: >> This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited. ????? ????????????????????????????????????????????????????? CONFIDENTIAL NOTE: This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited. From iklam at openjdk.org Fri Sep 12 03:37:22 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 12 Sep 2025 03:37:22 GMT Subject: RFR: 8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive Message-ID: Support of `-XX:+AOTClassLinking` for dynamic CDS archive is not an documented feature of [JEP 483](https://openjdk.org/jeps/483). It has very small performance benefit and complicates the development of future AOT optimizations. After this PR, `-XX:+AOTClassLinking` will have no effect when creating a dynamic CDS archive. ------------- Commit messages: - No need to run runtime/cds/appcds/dynamicArchive with -XX:+AOTClassLinking as this flag will have no effect - 8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive Changes: https://git.openjdk.org/jdk/pull/27242/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27242&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367366 Stats: 102 lines in 15 files changed: 8 ins; 68 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/27242.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27242/head:pull/27242 PR: https://git.openjdk.org/jdk/pull/27242 From dzhang at openjdk.org Fri Sep 12 03:38:32 2025 From: dzhang at openjdk.org (Dingli Zhang) Date: Fri, 12 Sep 2025 03:38:32 GMT Subject: Integrated: 8367137: RISC-V: Detect Zicboz block size via hwprobe In-Reply-To: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> References: <2C-4ambWyEiM2G3A6p5Gemckd53CIrIWe7vyg577GzI=.f712b876-4297-44af-9958-26113764b287@github.com> Message-ID: On Tue, 9 Sep 2025 03:14:42 GMT, Dingli Zhang wrote: > Hi, > Can you help to review this patch? Thanks! > > We can extends RISC-V hwprobe support to include `RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`. > The probed value is recorded in VM_Version::zicboz_block_size and then used to set the zicboz_block_size. > This ensures correct usage of the Zicboz extension, as block zeroing instructions operate on cache-line granularity. > > FYI: https://docs.kernel.org/arch/riscv/hwprobe.html This pull request has now been integrated. Changeset: 5abd1842 Author: Dingli Zhang Committer: Fei Yang URL: https://git.openjdk.org/jdk/commit/5abd18426d64f878ca45f9d36ca270be17a7760f Stats: 60 lines in 5 files changed: 10 ins; 0 del; 50 mod 8367137: RISC-V: Detect Zicboz block size via hwprobe Reviewed-by: fyang, mli, rehn ------------- PR: https://git.openjdk.org/jdk/pull/27155 From david.holmes at oracle.com Fri Sep 12 03:46:53 2025 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Sep 2025 13:46:53 +1000 Subject: =?UTF-8?B?UmU6IOWbnuWkjTogSW1wcm92ZSBVc2VBVlggc2V0dGluZyBhbmQgYWRk?= =?UTF-8?Q?_cpu_descriptions_for_zhaoxin_processors=2E?= In-Reply-To: <8e3eab4683d34791955eac618775cea3@zhaoxin.com> References: <58756de5-86a3-4963-a3ae-105455d1fbd0@oracle.com> <8e3eab4683d34791955eac618775cea3@zhaoxin.com> Message-ID: On 12/09/2025 1:19 pm, Vic Wang(BJ-RD) wrote: > Hi David, > > I have submitted a PR, please help to review: > https://github.com/openjdk/jdk/pull/27241 > > It shows "OCA signatory status must be verified". > My employer, Shanghai Zhaoxin Semiconductor, has already signed the OCA, and it can be found on http://oca.opensource.oracle.com. > Please help me with this issue. This is your first submission via Github so it has to go through the verification process. David > Best Regards! > Vic Wang > > >> -----????----- >> ???: David Holmes >> ????: 2025?9?12? 9:06 >> ???: Vic Wang(BJ-RD) ; hotspot-dev at openjdk.org >> ??: Re: Improve UseAVX setting and add cpu descriptions for zhaoxin processors. >> >> >> Hi Vic, >> >> It has been a long time since we heard from you. :) >> >> I have filed a JBS issue for this update: >> >> https://bugs.openjdk.org/browse/JDK-8367478 >> >> Cheers, >> David >> >> On 11/09/2025 11:33 pm, Vic Wang(BJ-RD) wrote: >>> Hi All >>> >>> Here is the patch that improving the UseAVX setting and add cpu descriptions for zhaoxin processors. >>> Can you help to review the patch and assign a number for a pull request? >>> Thank you! >>> >>> >>> Patch in my fork repository: >>> https://github.com/Double-Minds-JV/jdk/commit/06498b42ed54021b3ed14a9c >>> cc9adf52e9360c9c >>> >>>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp >>>> b/src/hotspot/cpu/x86/vm_version_x86.cpp >>>> index 094ab370190..4043b29f18c 100644 >>>> --- a/src/hotspot/cpu/x86/vm_version_x86.cpp >>>> +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp >>>> @@ -931,9 +931,17 @@ void VM_Version::get_processor_features() { >>>> if (UseSSE < 1) >>>> _features.clear_feature(CPU_SSE); >>>> >>>> - //since AVX instructions is slower than SSE in some ZX cpus, force USEAVX=0. >>>> - if (is_zx() && ((cpu_family() == 6) || (cpu_family() == 7))) { >>>> - UseAVX = 0; >>>> + // ZX cpus specific settings >>>> + if (is_zx() && FLAG_IS_DEFAULT(UseAVX)) { >>>> + if (cpu_family() == 7) { >>>> + if (extended_cpu_model() == 0x5B || extended_cpu_model() == 0x6B) { >>>> + UseAVX = 1; >>>> + } else if (extended_cpu_model() == 0x1B || extended_cpu_model() == 0x3B) { >>>> + UseAVX = 0; >>>> + } >>>> + } else if (cpu_family() == 6) { >>>> + UseAVX = 0; >>>> + } >>>> } >>>> >>>> // UseSSE is set to the smaller of what hardware supports and what >>>> @@ -2592,6 +2600,7 @@ void >>>> VM_Version::resolve_cpu_information_details(void) { >>>> >>>> const char* VM_Version::cpu_family_description(void) { >>>> int cpu_family_id = extended_cpu_family(); >>>> + int cpu_model_id = extended_cpu_model(); >>>> if (is_amd()) { >>>> if (cpu_family_id < ExtendedFamilyIdLength_AMD) { >>>> return _family_id_amd[cpu_family_id]; @@ -2605,6 +2614,22 @@ >>>> const char* VM_Version::cpu_family_description(void) { >>>> return _family_id_intel[cpu_family_id]; >>>> } >>>> } >>>> + if (is_zx()) { >>>> + if (cpu_family_id == 7) { >>>> + switch (cpu_model_id) { >>>> + case 0x1B: >>>> + return "wudaokou"; >>>> + case 0x3B: >>>> + return "lujiazui"; >>>> + case 0x5B: >>>> + return "yongfeng"; >>>> + case 0x6B: >>>> + return "shijidadao"; >>>> + } >>>> + } else if (cpu_family_id == 6) { >>>> + return "zhangjiang"; >>>> + } >>>> + } >>>> if (is_hygon()) { >>>> return "Dhyana"; >>>> } >>>> @@ -2624,6 +2649,9 @@ int VM_Version::cpu_type_description(char* const buf, size_t buf_len) { >>>> } else if (is_amd()) { >>>> cpu_type = "AMD"; >>>> x64 = cpu_is_em64t() ? " AMD64" : ""; >>>> + } else if (is_zx()) { >>>> + cpu_type = "Zhaoxin"; >>>> + x64 = cpu_is_em64t() ? " x86_64" : ""; >>>> } else if (is_hygon()) { >>>> cpu_type = "Hygon"; >>>> x64 = cpu_is_em64t() ? " AMD64" : ""; @@ -3236,6 +3264,12 @@ int >>>> VM_Version::allocate_prefetch_distance(bool use_watermark_prefetch) { >>>> } else { >>>> return 128; // Athlon >>>> } >>>> + } else if (is_zx()) { >>>> + if (supports_sse2()) { >>>> + return 256; >>>> + } else { >>>> + return 128; >>>> + } >>>> } else { // Intel >>>> if (supports_sse3() && is_intel_server_family()) { >>>> if (supports_sse4_2() && supports_ht()) { // Nehalem based >>>> cpus >>> >>> I have run the jtreg tests after applying the patch, the test-summary shows follows: >>>> ============================== >>>> Test summary >>>> ============================== >>>> TEST TOTAL PASS FAIL ERROR SKIP >>>> jtreg:test/hotspot/jtreg:tier1 3107 2797 0 0 310 >>>> jtreg:test/jdk:tier1 2513 2472 0 0 41 >>>> jtreg:test/langtools:tier1 4668 4656 0 0 12 >>>> jtreg:test/jaxp:tier1 0 0 0 0 0 >>>> jtreg:test/lib-test:tier1 38 38 0 0 0 >>>> ============================== >>>> TEST SUCCESS >>> >>> Best Regards! >>> Vic Wang >>> >>> >>> ????? >>> ????????????????????????????????????????????????????? >>> CONFIDENTIAL NOTE: >>> This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited. > > > ????? > ????????????????????????????????????????????????????? > CONFIDENTIAL NOTE: > This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited. From VicWang at zhaoxin.com Fri Sep 12 05:00:00 2025 From: VicWang at zhaoxin.com (Vic Wang(BJ-RD)) Date: Fri, 12 Sep 2025 05:00:00 +0000 Subject: =?utf-8?B?5Zue5aSNOiDlm57lpI06IEltcHJvdmUgVXNlQVZYIHNldHRpbmcgYW5kIGFk?= =?utf-8?Q?d_cpu_descriptions_for_zhaoxin_processors.?= In-Reply-To: References: <58756de5-86a3-4963-a3ae-105455d1fbd0@oracle.com> <8e3eab4683d34791955eac618775cea3@zhaoxin.com> Message-ID: Hi David, So what do I need to do next? Or just wait for the verification process? Best Regards! Vic Wang > -----????----- >???: David Holmes >????: 2025?9?12? 11:47 >???: Vic Wang(BJ-RD) ; hotspot-dev at openjdk.org >??: Re: ??: Improve UseAVX setting and add cpu descriptions for zhaoxin processors. > > >On 12/09/2025 1:19 pm, Vic Wang(BJ-RD) wrote: >> Hi David, >> >> I have submitted a PR, please help to review: >> https://github.com/openjdk/jdk/pull/27241 >> >> It shows "OCA signatory status must be verified". >> My employer, Shanghai Zhaoxin Semiconductor, has already signed the OCA, and it can be found on http://oca.opensource.oracle.com. >> Please help me with this issue. > >This is your first submission via Github so it has to go through the verification process. > >David > >> Best Regards! >> Vic Wang >> >> >>> -----????----- >>> ???: David Holmes >>> ????: 2025?9?12? 9:06 >>> ???: Vic Wang(BJ-RD) ; hotspot-dev at openjdk.org >>> ??: Re: Improve UseAVX setting and add cpu descriptions for zhaoxin processors. >>> >>> >>> Hi Vic, >>> >>> It has been a long time since we heard from you. :) >>> >>> I have filed a JBS issue for this update: >>> >>> https://bugs.openjdk.org/browse/JDK-8367478 >>> >>> Cheers, >>> David >>> >>> On 11/09/2025 11:33 pm, Vic Wang(BJ-RD) wrote: >>>> Hi All >>>> >>>> Here is the patch that improving the UseAVX setting and add cpu descriptions for zhaoxin processors. >>>> Can you help to review the patch and assign a number for a pull request? >>>> Thank you! >>>> >>>> >>>> Patch in my fork repository: >>>> https://github.com/Double-Minds-JV/jdk/commit/06498b42ed54021b3ed14a >>>> 9c >>>> cc9adf52e9360c9c >>>> >>>>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>> b/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>> index 094ab370190..4043b29f18c 100644 >>>>> --- a/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>> +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>> @@ -931,9 +931,17 @@ void VM_Version::get_processor_features() { >>>>> if (UseSSE < 1) >>>>> _features.clear_feature(CPU_SSE); >>>>> >>>>> - //since AVX instructions is slower than SSE in some ZX cpus, force USEAVX=0. >>>>> - if (is_zx() && ((cpu_family() == 6) || (cpu_family() == 7))) { >>>>> - UseAVX = 0; >>>>> + // ZX cpus specific settings >>>>> + if (is_zx() && FLAG_IS_DEFAULT(UseAVX)) { >>>>> + if (cpu_family() == 7) { >>>>> + if (extended_cpu_model() == 0x5B || extended_cpu_model() == 0x6B) { >>>>> + UseAVX = 1; >>>>> + } else if (extended_cpu_model() == 0x1B || extended_cpu_model() == 0x3B) { >>>>> + UseAVX = 0; >>>>> + } >>>>> + } else if (cpu_family() == 6) { >>>>> + UseAVX = 0; >>>>> + } >>>>> } >>>>> >>>>> // UseSSE is set to the smaller of what hardware supports and >>>>> what @@ -2592,6 +2600,7 @@ void >>>>> VM_Version::resolve_cpu_information_details(void) { >>>>> >>>>> const char* VM_Version::cpu_family_description(void) { >>>>> int cpu_family_id = extended_cpu_family(); >>>>> + int cpu_model_id = extended_cpu_model(); >>>>> if (is_amd()) { >>>>> if (cpu_family_id < ExtendedFamilyIdLength_AMD) { >>>>> return _family_id_amd[cpu_family_id]; @@ -2605,6 +2614,22 >>>>> @@ const char* VM_Version::cpu_family_description(void) { >>>>> return _family_id_intel[cpu_family_id]; >>>>> } >>>>> } >>>>> + if (is_zx()) { >>>>> + if (cpu_family_id == 7) { >>>>> + switch (cpu_model_id) { >>>>> + case 0x1B: >>>>> + return "wudaokou"; >>>>> + case 0x3B: >>>>> + return "lujiazui"; >>>>> + case 0x5B: >>>>> + return "yongfeng"; >>>>> + case 0x6B: >>>>> + return "shijidadao"; >>>>> + } >>>>> + } else if (cpu_family_id == 6) { >>>>> + return "zhangjiang"; >>>>> + } >>>>> + } >>>>> if (is_hygon()) { >>>>> return "Dhyana"; >>>>> } >>>>> @@ -2624,6 +2649,9 @@ int VM_Version::cpu_type_description(char* const buf, size_t buf_len) { >>>>> } else if (is_amd()) { >>>>> cpu_type = "AMD"; >>>>> x64 = cpu_is_em64t() ? " AMD64" : ""; >>>>> + } else if (is_zx()) { >>>>> + cpu_type = "Zhaoxin"; >>>>> + x64 = cpu_is_em64t() ? " x86_64" : ""; >>>>> } else if (is_hygon()) { >>>>> cpu_type = "Hygon"; >>>>> x64 = cpu_is_em64t() ? " AMD64" : ""; @@ -3236,6 +3264,12 @@ >>>>> int VM_Version::allocate_prefetch_distance(bool use_watermark_prefetch) { >>>>> } else { >>>>> return 128; // Athlon >>>>> } >>>>> + } else if (is_zx()) { >>>>> + if (supports_sse2()) { >>>>> + return 256; >>>>> + } else { >>>>> + return 128; >>>>> + } >>>>> } else { // Intel >>>>> if (supports_sse3() && is_intel_server_family()) { >>>>> if (supports_sse4_2() && supports_ht()) { // Nehalem based >>>>> cpus >>>> >>>> I have run the jtreg tests after applying the patch, the test-summary shows follows: >>>>> ============================== >>>>> Test summary >>>>> ============================== >>>>> TEST TOTAL PASS FAIL ERROR SKIP >>>>> jtreg:test/hotspot/jtreg:tier1 3107 2797 0 0 310 >>>>> jtreg:test/jdk:tier1 2513 2472 0 0 41 >>>>> jtreg:test/langtools:tier1 4668 4656 0 0 12 >>>>> jtreg:test/jaxp:tier1 0 0 0 0 0 >>>>> jtreg:test/lib-test:tier1 38 38 0 0 0 >>>>> ============================== >>>>> TEST SUCCESS >>>> >>>> Best Regards! >>>> Vic Wang >>>> >>>> >>>> ????? >>>> ????????????????????????????????????????????????????? >>>> CONFIDENTIAL NOTE: >>>> This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited. ????? ????????????????????????????????????????????????????? CONFIDENTIAL NOTE: This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited. From david.holmes at oracle.com Fri Sep 12 05:45:08 2025 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Sep 2025 15:45:08 +1000 Subject: =?UTF-8?B?UmU6IOWbnuWkjTog5Zue5aSNOiBJbXByb3ZlIFVzZUFWWCBzZXR0aW5n?= =?UTF-8?Q?_and_add_cpu_descriptions_for_zhaoxin_processors=2E?= In-Reply-To: References: <58756de5-86a3-4963-a3ae-105455d1fbd0@oracle.com> <8e3eab4683d34791955eac618775cea3@zhaoxin.com> Message-ID: <40e7e92c-2963-4952-85b9-70a9a9dcf60c@oracle.com> On 12/09/2025 3:00 pm, Vic Wang(BJ-RD) wrote: > Hi David, > > So what do I need to do next? Or just wait for the verification process? Just have to wait I'm afraid. David ----- > Best Regards! > Vic Wang > > >> -----????----- >> ???: David Holmes >> ????: 2025?9?12? 11:47 >> ???: Vic Wang(BJ-RD) ; hotspot-dev at openjdk.org >> ??: Re: ??: Improve UseAVX setting and add cpu descriptions for zhaoxin processors. >> >> >> On 12/09/2025 1:19 pm, Vic Wang(BJ-RD) wrote: >>> Hi David, >>> >>> I have submitted a PR, please help to review: >>> https://github.com/openjdk/jdk/pull/27241 >>> >>> It shows "OCA signatory status must be verified". >>> My employer, Shanghai Zhaoxin Semiconductor, has already signed the OCA, and it can be found on http://oca.opensource.oracle.com. >>> Please help me with this issue. >> >> This is your first submission via Github so it has to go through the verification process. >> >> David >> >>> Best Regards! >>> Vic Wang >>> >>> >>>> -----????----- >>>> ???: David Holmes >>>> ????: 2025?9?12? 9:06 >>>> ???: Vic Wang(BJ-RD) ; hotspot-dev at openjdk.org >>>> ??: Re: Improve UseAVX setting and add cpu descriptions for zhaoxin processors. >>>> >>>> >>>> Hi Vic, >>>> >>>> It has been a long time since we heard from you. :) >>>> >>>> I have filed a JBS issue for this update: >>>> >>>> https://bugs.openjdk.org/browse/JDK-8367478 >>>> >>>> Cheers, >>>> David >>>> >>>> On 11/09/2025 11:33 pm, Vic Wang(BJ-RD) wrote: >>>>> Hi All >>>>> >>>>> Here is the patch that improving the UseAVX setting and add cpu descriptions for zhaoxin processors. >>>>> Can you help to review the patch and assign a number for a pull request? >>>>> Thank you! >>>>> >>>>> >>>>> Patch in my fork repository: >>>>> https://github.com/Double-Minds-JV/jdk/commit/06498b42ed54021b3ed14a >>>>> 9c >>>>> cc9adf52e9360c9c >>>>> >>>>>> diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>>> b/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>>> index 094ab370190..4043b29f18c 100644 >>>>>> --- a/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>>> +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp >>>>>> @@ -931,9 +931,17 @@ void VM_Version::get_processor_features() { >>>>>> if (UseSSE < 1) >>>>>> _features.clear_feature(CPU_SSE); >>>>>> >>>>>> - //since AVX instructions is slower than SSE in some ZX cpus, force USEAVX=0. >>>>>> - if (is_zx() && ((cpu_family() == 6) || (cpu_family() == 7))) { >>>>>> - UseAVX = 0; >>>>>> + // ZX cpus specific settings >>>>>> + if (is_zx() && FLAG_IS_DEFAULT(UseAVX)) { >>>>>> + if (cpu_family() == 7) { >>>>>> + if (extended_cpu_model() == 0x5B || extended_cpu_model() == 0x6B) { >>>>>> + UseAVX = 1; >>>>>> + } else if (extended_cpu_model() == 0x1B || extended_cpu_model() == 0x3B) { >>>>>> + UseAVX = 0; >>>>>> + } >>>>>> + } else if (cpu_family() == 6) { >>>>>> + UseAVX = 0; >>>>>> + } >>>>>> } >>>>>> >>>>>> // UseSSE is set to the smaller of what hardware supports and >>>>>> what @@ -2592,6 +2600,7 @@ void >>>>>> VM_Version::resolve_cpu_information_details(void) { >>>>>> >>>>>> const char* VM_Version::cpu_family_description(void) { >>>>>> int cpu_family_id = extended_cpu_family(); >>>>>> + int cpu_model_id = extended_cpu_model(); >>>>>> if (is_amd()) { >>>>>> if (cpu_family_id < ExtendedFamilyIdLength_AMD) { >>>>>> return _family_id_amd[cpu_family_id]; @@ -2605,6 +2614,22 >>>>>> @@ const char* VM_Version::cpu_family_description(void) { >>>>>> return _family_id_intel[cpu_family_id]; >>>>>> } >>>>>> } >>>>>> + if (is_zx()) { >>>>>> + if (cpu_family_id == 7) { >>>>>> + switch (cpu_model_id) { >>>>>> + case 0x1B: >>>>>> + return "wudaokou"; >>>>>> + case 0x3B: >>>>>> + return "lujiazui"; >>>>>> + case 0x5B: >>>>>> + return "yongfeng"; >>>>>> + case 0x6B: >>>>>> + return "shijidadao"; >>>>>> + } >>>>>> + } else if (cpu_family_id == 6) { >>>>>> + return "zhangjiang"; >>>>>> + } >>>>>> + } >>>>>> if (is_hygon()) { >>>>>> return "Dhyana"; >>>>>> } >>>>>> @@ -2624,6 +2649,9 @@ int VM_Version::cpu_type_description(char* const buf, size_t buf_len) { >>>>>> } else if (is_amd()) { >>>>>> cpu_type = "AMD"; >>>>>> x64 = cpu_is_em64t() ? " AMD64" : ""; >>>>>> + } else if (is_zx()) { >>>>>> + cpu_type = "Zhaoxin"; >>>>>> + x64 = cpu_is_em64t() ? " x86_64" : ""; >>>>>> } else if (is_hygon()) { >>>>>> cpu_type = "Hygon"; >>>>>> x64 = cpu_is_em64t() ? " AMD64" : ""; @@ -3236,6 +3264,12 @@ >>>>>> int VM_Version::allocate_prefetch_distance(bool use_watermark_prefetch) { >>>>>> } else { >>>>>> return 128; // Athlon >>>>>> } >>>>>> + } else if (is_zx()) { >>>>>> + if (supports_sse2()) { >>>>>> + return 256; >>>>>> + } else { >>>>>> + return 128; >>>>>> + } >>>>>> } else { // Intel >>>>>> if (supports_sse3() && is_intel_server_family()) { >>>>>> if (supports_sse4_2() && supports_ht()) { // Nehalem based >>>>>> cpus >>>>> >>>>> I have run the jtreg tests after applying the patch, the test-summary shows follows: >>>>>> ============================== >>>>>> Test summary >>>>>> ============================== >>>>>> TEST TOTAL PASS FAIL ERROR SKIP >>>>>> jtreg:test/hotspot/jtreg:tier1 3107 2797 0 0 310 >>>>>> jtreg:test/jdk:tier1 2513 2472 0 0 41 >>>>>> jtreg:test/langtools:tier1 4668 4656 0 0 12 >>>>>> jtreg:test/jaxp:tier1 0 0 0 0 0 >>>>>> jtreg:test/lib-test:tier1 38 38 0 0 0 >>>>>> ============================== >>>>>> TEST SUCCESS >>>>> >>>>> Best Regards! >>>>> Vic Wang >>>>> >>>>> >>>>> ????? >>>>> ????????????????????????????????????????????????????? >>>>> CONFIDENTIAL NOTE: >>>>> This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited. > > > > ????? > ????????????????????????????????????????????????????? > CONFIDENTIAL NOTE: > This email contains confidential or legally privileged information and is for the sole use of its intended recipient. Any unauthorized review, use, copying or forwarding of this email or the content of this email is strictly prohibited. From stefank at openjdk.org Fri Sep 12 05:59:14 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 12 Sep 2025 05:59:14 GMT Subject: RFR: 8252582: HotSpot Style Guide should permit variable templates In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 01:13:25 GMT, Kim Barrett wrote: > Please review this change to the HotSpot Style Guide to permit the use of > variable templates. This is a C++14 feature that, while fairly simple, didn't > get into the initial permitted for HotSpot list because I just didn't get to > it and nobody asked for it. And it has languished on the "undecided" list for > the same reasons. But recently I've had reason to want to use this feature a > couple of times, so I'm now proposing we allow it. > > I merged it into the section for Inline Variables (a C++17 feature), as the > two are closely related. Variable templates were even listed as one of the > workarounds being used to make up for the lack of inline variables. Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27240#pullrequestreview-3214768117 From kbarrett at openjdk.org Fri Sep 12 06:35:19 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 12 Sep 2025 06:35:19 GMT Subject: RFR: 8367014: Rename class Atomic to AtomicAccess [v3] In-Reply-To: References: Message-ID: <7AkpbeYv_skWN-uWtPAf4LpJ4stSozu2k0I75xUrAkI=.9aa5463f-4548-4a91-80e1-929f918c0676@github.com> On Wed, 10 Sep 2025 07:40:38 GMT, Andrew Haley wrote: >>> > Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose >>> > to not rename the various "atomic_." and "atomic__." files. >>> >>> Could you motivate why you chose to not do that? >> >> I thought about it, and waffled back and forth. But I was trying to do as much >> as possible of this change mechanically. Renaming a file involves multiple >> steps that weren't all easily scriptable. (And I'd already messed up a part of >> the renaming of atomic.hpp during patch development.) Also, this change is >> going to be hard for backports as it is, and I think renamings might make that >> worse. Renamings can also be annoying for archeology. But if you think it's >> important... > >> Also, this change is >> going to be hard for backports as it is, and I think renamings might make that >> worse. Renamings can also be annoying for archeology. > > Speaking as an archaeologist and the lead of multiple backport projects, I agree with you, Kim. Thanks for reviews @theRealAph , @stefank , and @dholmes-ora ------------- PR Comment: https://git.openjdk.org/jdk/pull/27135#issuecomment-3283901596 From kbarrett at openjdk.org Fri Sep 12 06:39:35 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 12 Sep 2025 06:39:35 GMT Subject: Integrated: 8367014: Rename class Atomic to AtomicAccess In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 06:26:03 GMT, Kim Barrett wrote: > Please review this change that renames the all-static class `Atomic` to > `AtomicAccess`. The reason for this name change is to allow the introduction > of the new type `Atomic` ([JDK-8367013](https://bugs.openjdk.org/browse/JDK-8367013)). > > The PR has several commits, according to the specific category of change being > made. It may be easier to review the PR by studying these individual commits. > > Although the file "atomic.hpp" is being renamed to "atomicAccess.hpp", I chose > to not rename the various "atomic_.*" and "atomic__.*" files. > > There are a number of comments containing the word "Atomic" that I didn't > change. They are generically about atomic operations, and will just as well > serve as referring to the future `Atomic`. > > Testing: mach5 tier1, GHA sanity tests. > This is one of those changes where successful builds indicate the change is good. This pull request has now been integrated. Changeset: 9e843f56 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/9e843f56ec0e4126e8256dff44f47c56e5282d20 Stats: 5577 lines in 430 files changed: 1587 ins; 1585 del; 2405 mod 8367014: Rename class Atomic to AtomicAccess Reviewed-by: dholmes, aph, stefank ------------- PR: https://git.openjdk.org/jdk/pull/27135 From tschatzl at openjdk.org Fri Sep 12 07:26:30 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 12 Sep 2025 07:26:30 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 10:24:57 GMT, Andrew Haley wrote: >> I can argue I was following precedent :) I see your point though. What do you suggest to do here? Use `count` throughout instead? > >> I can argue I was following precedent :) > > You were, but it's a precedent that needs to die. > >> I see your point though. What do you suggest to do here? Use `count` throughout instead? > > Yes, although it might need a couple more comments. What do you think of https://github.com/openjdk/jdk/commit/74e9240ba275986375d3e6f0ac9bfa4b5fbb78ce ? (not committed in this branch yet because I do not want all the back-and-forth here) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2343254077 From mbaesken at openjdk.org Fri Sep 12 07:56:25 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 12 Sep 2025 07:56:25 GMT Subject: RFR: 8367282: FORBID_C_FUNCTION needs exception spec consistent with library declaration [v2] In-Reply-To: References: Message-ID: <5w3DvE_xDDUVUj4usmRec4W62no25mFrbBNkghlvNqk=.dc10adc1-2dd0-4179-b03e-832ea2ddc1b1@github.com> On Thu, 11 Sep 2025 04:11:29 GMT, Kim Barrett wrote: >> Please review this change to FORBID_C_FUNCTION to make the exception specs of >> the forbidding declarations match up with the exception specs of the >> associated library declarations. This needs to account for different platform >> libraries either having or not having exception specs. It's needed because, >> after switching to C++17, some compilers complain about some differences in >> the exception specs. >> >> Also removed the workaround for JDK-8367051, which should no longer be needed >> after this change. >> >> Hoping someone will test the aix-ppc port. @MBaesken or @TheRealMDoerr ? >> >> Testing: mach5 tier1, GHA sanity checks (nearly finished) >> Locally (linux-aarch64) built with clang, which failed without the JDK-8367051 >> workaround. > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > work around AIX noexcept inconsistencies Works now on AIX as well, thanks ! ------------- Marked as reviewed by mbaesken (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27180#pullrequestreview-3215249121 From azafari at openjdk.org Fri Sep 12 08:25:15 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 12 Sep 2025 08:25:15 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer In-Reply-To: <-Ct2yCIbRn7bSazmFKxlMPMeP85zAZk3kUfP9ele4so=.78e5ec0f-2d17-45e6-a68d-9fff149577c1@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> <-Ct2yCIbRn7bSazmFKxlMPMeP85zAZk3kUfP9ele4so=.78e5ec0f-2d17-45e6-a68d-9fff149577c1@github.com> Message-ID: On Wed, 27 Aug 2025 14:19:23 GMT, Johan Sj?len wrote: >> The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. >> The acceptable value is changed to 64K. >> >> Tests: >> linux-x64 tier1 > > It seems to me like we can fix the ubsan issue by avoiding the cast into pointers and computing through `size_t` as far as possible, and converting into pointer when necessary. > > For example > > ```c++ > size_t aligned_heap_base_min_address = align_up(HeapBaseMinAddress, alignment); > size_t noaccess_prefix = ((aligned_heap_base_min_address + size) > OopEncodingHeapMax) ? noaccess_prefix_size : 0; > > if (!FLAG_IS_DEFAULT(HeapBaseMinAddress)) { > reserved = try_reserve_memory(size + noaccess_prefix, alignment, page_size, static_cast(aligned_heap_base_min_address)); > if (reserved.base() != static_cast(aligned_heap_base_min_address)) { // Enforce this exact address. > release(reserved); > reserved = {}; > } > } > > > The semantics of reserving a `null` base address is still preserved as meaning "don't care where you put it" then. Someone from GC needs to look at this and see whether or not an undefined (implicitly 0?) HeapBaseMinAddress is meant to have that type of meaning. Dear @jdksjolen and @xmas92, your comments are welcome. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3284266029 From tschatzl at openjdk.org Fri Sep 12 08:29:59 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 12 Sep 2025 08:29:59 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v60] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 80 commits: - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * therealaph suggestion for avoiding the register aliasin in gen_write_ref_array_post - * walulyai review - * walulyai review * tried to remove "logged card" terminology for the current "pending card" one - * aph review, fix some comment - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * iwalulya: remove confusing comment - * sort includes - Merge branch 'master' into 8342382-card-table-instead-of-dcq - ... and 70 more: https://git.openjdk.org/jdk/compare/9e843f56...1ced9f98 ------------- Changes: https://git.openjdk.org/jdk/pull/23739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=59 Stats: 7162 lines in 112 files changed: 2594 ins; 3588 del; 980 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From mdoerr at openjdk.org Fri Sep 12 08:30:01 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 12 Sep 2025 08:30:01 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: References: Message-ID: <63y80KoZ7oXdnFLRmK28Z8wcOSSAMXHx91akDn0tcLc=.981add6e-0b3f-423f-9b5f-87bb7d9fad9a@github.com> On Fri, 12 Sep 2025 07:23:23 GMT, Thomas Schatzl wrote: >>> I can argue I was following precedent :) >> >> You were, but it's a precedent that needs to die. >> >>> I see your point though. What do you suggest to do here? Use `count` throughout instead? >> >> Yes, although it might need a couple more comments. > > What do you think of https://github.com/openjdk/jdk/commit/74e9240ba275986375d3e6f0ac9bfa4b5fbb78ce ? (not committed in this branch yet because I do not want all the back-and-forth here) Other idea: set count = noreg to prevent usage after it is used under the other name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2343415421 From mdoerr at openjdk.org Fri Sep 12 08:33:37 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 12 Sep 2025 08:33:37 GMT Subject: RFR: 8367325: [s390x] build failure due to JDK-8361376 In-Reply-To: <6M1CuZ1hFWFJyT-diBc59BSsdr3YuQvZn_rtSc8LP0Q=.608a5dd6-6ed7-44bf-a840-9e89d3b8d742@github.com> References: <6M1CuZ1hFWFJyT-diBc59BSsdr3YuQvZn_rtSc8LP0Q=.608a5dd6-6ed7-44bf-a840-9e89d3b8d742@github.com> Message-ID: On Fri, 12 Sep 2025 00:23:04 GMT, Dean Long wrote: >> That would require much more changes. The barrier sequence is expected to have a fixed size. > > OK, then how about we align the beginning using > ` __ align(4, offset() + 3*6 + 2);` > to make it more self-documenting? Or better: define a constant for 3*6 + 2 and reuse it in `class NativeMethodBarrier`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27213#discussion_r2343425223 From mli at openjdk.org Fri Sep 12 08:48:30 2025 From: mli at openjdk.org (Hamlin Li) Date: Fri, 12 Sep 2025 08:48:30 GMT Subject: RFR: 8367253: RISC-V: refactor dependent cpu extensions [v2] In-Reply-To: References: Message-ID: > Hi, > Can you help to review this patch? > > Dependent extensions could be improved in several ways. > > Currently, the dependent cpu extensions are processed in 2 separate places: > 1. update_flag() when calling VM_Version::setup_cpu_available_features() > 2. at the end of VM_Version::common_initialize(). > But we can do it in one single place, that is update_flag(). > > And, dependency relationship can only be expressed in (1:1) way, can not be expressed (1:N) way, but in fact some extensions can depend on several different other extensions, for example, zvfh depends on zvf and rvv. It's would be better to support this (1:N) relationship. > > Thanks! Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - merge master - remove obsolete extension dependency code - initial commit ------------- Changes: https://git.openjdk.org/jdk/pull/27171/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27171&range=01 Stats: 143 lines in 2 files changed: 52 ins; 30 del; 61 mod Patch: https://git.openjdk.org/jdk/pull/27171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27171/head:pull/27171 PR: https://git.openjdk.org/jdk/pull/27171 From jsjolen at openjdk.org Fri Sep 12 09:26:50 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 12 Sep 2025 09:26:50 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v3] In-Reply-To: <-eWIUjA4RqIgcpvFSyFxuiuganZpBqkMIdKSOVhnuMo=.79db2c26-5547-42fa-84d9-9bf5746728cf@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> <-eWIUjA4RqIgcpvFSyFxuiuganZpBqkMIdKSOVhnuMo=.79db2c26-5547-42fa-84d9-9bf5746728cf@github.com> Message-ID: On Fri, 5 Sep 2025 11:02:32 GMT, Afshin Zafari wrote: >> The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. >> The acceptable value is changed to 64K. >> >> Tests: >> linux-x64 tier1 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > lowest can be equal to highest src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp line 288: > 286: // If an overflow happened in Arguments::set_heap_size(), MaxHeapSize will have too large a value. > 287: // Check for this by ensuring that MaxHeapSize plus the requested min base address still fit within max_uintx. > 288: if (value + MaxHeapSize < MaxHeapSize) {// overflow Can we perform the overflow check via subtraction from the max value instead? I know that unsigned types do wrap around, but at a first glance this will look wrong and make the reader stop and think. Style: Space between { and // if (std::numeric_limits::max() - value < MaxHeapSize) { // overflow src/hotspot/share/memory/memoryReserver.cpp line 560: > 558: if (!FLAG_IS_DEFAULT(HeapBaseMinAddress)) { > 559: reserved = try_reserve_memory(size + noaccess_prefix, alignment, page_size, (char *)aligned_heap_base_min_address); > 560: if (reserved.base() != (char *)aligned_heap_base_min_address) { // Enforce this exact address. Style: Please hug the * to the char for the casts src/hotspot/share/memory/memoryReserver.cpp line 584: > 582: // Calc address range within we try to attach (range of possible start addresses). > 583: char* const highest_start = align_down((char *)UnscaledOopHeapMax - size, attach_point_alignment); > 584: char* const lowest_start = align_up((char *)aligned_heap_base_min_address, attach_point_alignment); Keep these as uintptr_t instead and only cast when trying to reserve src/hotspot/share/memory/memoryReserver.cpp line 595: > 593: > 594: // Give it several tries from top of range to bottom. > 595: if (aligned_heap_base_min_address + size <= (uintptr_t)zerobased_max && // Zerobased theoretical possible. Do the opposite: Have zerobased_max be uintptr_t and only cast it when it needs to become a char* src/hotspot/share/memory/memoryReserver.cpp line 612: > 610: } > 611: lowest_start = align_up(lowest_start, attach_point_alignment); > 612: assert(lowest_start <= highest_start, "lowest: " INTPTR_FORMAT " highest: " INTPTR_FORMAT, Keep these as uintptr_t and cast to char* only when reserving ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2343523999 PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2343578098 PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2343582330 PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2343588323 PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2343591444 From ayang at openjdk.org Fri Sep 12 10:19:40 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 12 Sep 2025 10:19:40 GMT Subject: RFR: 8367320: Sort cpu/x86 includes [v2] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 16:09:18 GMT, Francesco Andreuzzi wrote: > There should be some more details about what constitutes the "corresponding .hpp file" That's probably a good idea to further clarify what the "corresponding .hpp" file is, when arch (_x86) is included in the inline-file name. I also wonder what others think. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27189#discussion_r2343753537 From iwalulya at openjdk.org Fri Sep 12 10:38:08 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 12 Sep 2025 10:38:08 GMT Subject: RFR: 8366865: G1: Allocation GC Pauses Triggered after JVM has started shutdown [v2] In-Reply-To: References: Message-ID: > Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. > > Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. > > Testing: Tier 1-7 Ivan Walulya 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 nine additional commits since the last revision: - return on timeout - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - timed wait - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - space - remove debug logs - remove debug logs - log_cpu_time - init ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27190/files - new: https://git.openjdk.org/jdk/pull/27190/files/8a05ec45..187a463b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=00-01 Stats: 11286 lines in 575 files changed: 5300 ins; 2963 del; 3023 mod Patch: https://git.openjdk.org/jdk/pull/27190.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27190/head:pull/27190 PR: https://git.openjdk.org/jdk/pull/27190 From fandreuzzi at openjdk.org Fri Sep 12 10:43:01 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 12 Sep 2025 10:43:01 GMT Subject: RFR: 8367476: Shenandoah: Remove use of CollectedHeap::_soft_ref_policy Message-ID: Similarly to what was done in #26496 and #26648, the usages of `CollectedHeap::_soft_ref_policy` in Shenandoah can be replaced with an earlier call to ShenandoahReferenceProcessor::set_soft_reference_policy. This is the last usages of `CollectedHeap::_soft_ref_policy`, so it can be removed. Passes tier(1,2,3)_gc_shenandoah. ------------- Commit messages: - can be const - stuff - stuff Changes: https://git.openjdk.org/jdk/pull/27239/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27239&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367476 Stats: 97 lines in 17 files changed: 16 ins; 74 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27239.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27239/head:pull/27239 PR: https://git.openjdk.org/jdk/pull/27239 From mli at openjdk.org Fri Sep 12 10:51:49 2025 From: mli at openjdk.org (Hamlin Li) Date: Fri, 12 Sep 2025 10:51:49 GMT Subject: RFR: 8367253: RISC-V: refactor dependent cpu extensions [v3] In-Reply-To: References: Message-ID: > Hi, > Can you help to review this patch? > > Dependent extensions could be improved in several ways. > > Currently, the dependent cpu extensions are processed in 2 separate places: > 1. update_flag() when calling VM_Version::setup_cpu_available_features() > 2. at the end of VM_Version::common_initialize(). > But we can do it in one single place, that is update_flag(). > > And, dependency relationship can only be expressed in (1:1) way, can not be expressed (1:N) way, but in fact some extensions can depend on several different other extensions, for example, zvfh depends on zvf and rvv. It's would be better to support this (1:N) relationship. > > Thanks! Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' into refactor-dependent-cpu-extensions - Merge branch 'openjdk:master' into master - initial commit - add includes - merge master - remove obsolete extension dependency code - initial commit ------------- Changes: https://git.openjdk.org/jdk/pull/27171/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27171&range=02 Stats: 144 lines in 2 files changed: 53 ins; 30 del; 61 mod Patch: https://git.openjdk.org/jdk/pull/27171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27171/head:pull/27171 PR: https://git.openjdk.org/jdk/pull/27171 From ayang at openjdk.org Fri Sep 12 11:05:12 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 12 Sep 2025 11:05:12 GMT Subject: RFR: 8367476: Shenandoah: Remove use of CollectedHeap::_soft_ref_policy In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 00:19:05 GMT, Francesco Andreuzzi wrote: > Similarly to what was done in #26496 and #26648, the usages of `CollectedHeap::_soft_ref_policy` in Shenandoah can be replaced with an earlier call to `ShenandoahReferenceProcessor::set_soft_reference_policy`. > > This is the last usage of `CollectedHeap::_soft_ref_policy`, so it can be removed. > > Passes tier(1,2,3)_gc_shenandoah. src/hotspot/share/gc/shared/collectedHeap.hpp line 239: > 237: return cause == GCCause::_metadata_GC_clear_soft_refs || > 238: cause == GCCause::_wb_full_gc; > 239: } I feel that it makes more sense to have this in `GCCause`. src/hotspot/share/gc/shared/collectedHeap.hpp line 241: > 239: } > 240: > 241: inline bool should_clear_all_soft_refs() const { I suggest inlining this method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27239#discussion_r2343856579 PR Review Comment: https://git.openjdk.org/jdk/pull/27239#discussion_r2343858970 From fandreuzzi at openjdk.org Fri Sep 12 11:14:22 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 12 Sep 2025 11:14:22 GMT Subject: RFR: 8367320: Sort cpu/x86 includes [v2] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 10:16:33 GMT, Albert Mingkun Yang wrote: >> I think the style guide should be changed too if we want to make this change: >> >> All .inline.hpp files should include their corresponding .hpp file as >> the first include line with a blank line separating it from the rest of the >> include lines. >> >> >> There should be some more details about what constitutes the "corresponding .hpp file". In the case of your [comment above](https://github.com/openjdk/jdk/pull/27189#discussion_r2336167042) in this PR, the `.inline.hpp` file had a clear "corresponding `.hpp` file", namely `continuationEntry_x86.hpp`. >> >> Should the style guide state something like "the corresponding `.hpp` file for a `inline.hpp` whose name contains some compilation flag-dependent qualifier, is either the `.hpp` file with the qualifier (if present) or the `.hpp` file without the qualifier as a fallback" ? > >> There should be some more details about what constitutes the "corresponding .hpp file" > > That's probably a good idea to further clarify what the "corresponding .hpp" file is, when arch (_x86) is included in the inline-file name. I also wonder what others think. I'm going to open a PR with a small change in `style-guide.md` to start the discussion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27189#discussion_r2343878101 From jpai at openjdk.org Fri Sep 12 11:32:18 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 12 Sep 2025 11:32:18 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v4] In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 16:04:08 GMT, Chen Liang wrote: >> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value). >> >> This is a necessary prerequisite for https://bugs.openjdk.org/browse/JDK-8233268, which proposes enhanced null messages to `Objects::requireNonNull`. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Update NPE per roger review Hello Chen, I had a look at the changes, but I'm missing some broader context of this change. The JBS issue and the PR description states that this PR is in preparation (to upcoming additional work?) to support better `NullPointerException` exception messages when some code uses `Objects.requireNonNull()`. It also talks about a `java.lang.runtime.Checks::nullCheck` method, but there's no such `java.lang.runtime.Checks` class in mainline and it appears to be a proposed class in Valhalla project (https://bugs.openjdk.org/browse/JDK-8357936). But there too it's non-existent for now. So I'll leave out the `Checks` class from this discussion. If this change were to be integrated into mainline, would there be any change to NullPointerException exception messages in any code paths? If not, then would it better to do these changes along with the `Objects.requireNonNull()` change itself, as part of https://bugs.openjdk.org/browse/JDK-8233268? In JDK-8233268, there's also a comment from Goetz proposing how the new exception message should look like. If the current changes were to be done, would it allow for that proposal to be implemented? I did have a brief look at the new jtreg test cases in this PR, but it wasn't immediately clear to me which APIs would start seeing this new proposed exception messages. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26600#issuecomment-3284904586 From phubner at openjdk.org Fri Sep 12 11:36:32 2025 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Fri, 12 Sep 2025 11:36:32 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary Message-ID: Hi all, `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: 1) refactors `constantPoolOop` to be a hidden VM injected field `vmtarget` (name to be consistent with other similar cases), 2) removes `FilteredJavaFieldStream` entirely, and 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. Testing: Oracle tiers 1-3. ------------- Commit messages: - Fix typo. - Refactor to purely use injected fields. - Remove FilteredJavaFieldStream and usages. - Remove constantPoolOop from Java code. - Make constantPoolOop a hidden vmholder field. Changes: https://git.openjdk.org/jdk/pull/27209/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27209&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365858 Stats: 194 lines in 9 files changed: 8 ins; 166 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/27209.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27209/head:pull/27209 PR: https://git.openjdk.org/jdk/pull/27209 From coleenp at openjdk.org Fri Sep 12 12:08:19 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 12 Sep 2025 12:08:19 GMT Subject: RFR: 8367368: Add message for verify_legal_class_modifiers for inner classes [v5] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 00:37:36 GMT, Chen Liang wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Only test for message fragments - Chen's comments. > > test/hotspot/jtreg/runtime/InnerClassesAttr/TestInnerClassAccessFlagErrorMessage.java line 58: > >> 56: } catch (ClassFormatError err) { >> 57: System.out.println(err.getMessage()); >> 58: assertEquals(err.getMessage(), msg2); > > I recommend testing against message fragment to ensure the class name is included without asserting the whole message, to allow more freedom in error messages while retaining desired info. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27201#discussion_r2344035687 From bmaillard at openjdk.org Fri Sep 12 12:57:00 2025 From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard) Date: Fri, 12 Sep 2025 12:57:00 GMT Subject: RFR: 8360389: Support printing from C2 compiled code [v10] In-Reply-To: References: Message-ID: > This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types. > > ## Usage > > Suppose we have this piece of Java code, that simply computes an arithmetic operation, and > that we compile `square` with C2. > > class Square { > static int square(int a) { > return a * a; > } > > public static void main(String[] args) { > square(9); > } > } > > > We would like to inspect the node that contains the value returned in this method. > We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect. > > ```c++ > void Compile::return_values(JVMState* jvms) { > GraphKit kit(jvms); > Node* ret = new ReturnNode(TypeFunc::Parms, > kit.control(), > kit.i_o(), > kit.reset_memory(), > kit.frameptr(), > kit.returnadr()); > // Add zero or 1 return values > int ret_size = tf()->range()->cnt() - TypeFunc::Parms; > > > Node* return_value; > if (ret_size > 0) { > kit.inc_sp(-ret_size); // pop the return value(s) > kit.sync_jvms(); > return_value = kit.argument(0); > ret->add_req(return_value); > > // <-------------------- Simply insert this > C->make_debug_print("return: ", initial_gvn(), return_value); > } > > // bind it to root > root()->add_req(ret); > record_for_igvn(ret); > initial_gvn()->transform(ret); > } > > > We can then call run our code with `-XX:CompileCommand="compileonly,Square::square` > and we get the following output: > > > return: > int 81 > > > This case is of course trivial, but more useful examples are shown later. > > ## Implementation > > The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed. > > The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the `CallLeafNode` constructor. > > The first argument to the runtime printing method is the printing message, a static string encoded as a `... Beno?t Maillard has updated the pull request incrementally with two additional commits since the last revision: - Simplify logic to single pass over the graph in pick_control - Add more comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26475/files - new: https://git.openjdk.org/jdk/pull/26475/files/13da04e1..6215d510 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26475&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26475&range=08-09 Stats: 91 lines in 2 files changed: 24 ins; 30 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/26475.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26475/head:pull/26475 PR: https://git.openjdk.org/jdk/pull/26475 From stefank at openjdk.org Fri Sep 12 13:15:28 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 12 Sep 2025 13:15:28 GMT Subject: RFR: 8367320: Sort cpu/x86 includes [v2] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 11:11:10 GMT, Francesco Andreuzzi wrote: >>> There should be some more details about what constitutes the "corresponding .hpp file" >> >> That's probably a good idea to further clarify what the "corresponding .hpp" file is, when arch (_x86) is included in the inline-file name. I also wonder what others think. > > I'm going to open a PR with a small change in `style-guide.md` to start the discussion. Just note that we currently don't have a consistent way that we structure the inclusions of our the platform dependent files. When making the patch that followed the "corresponding .hpp" rule I had to handle the includes on case-by-case basis. Just be warned that you might create a rule that we can't adhere to without rewriting some of the includes patterns. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27189#discussion_r2344224871 From fandreuzzi at openjdk.org Fri Sep 12 13:31:14 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 12 Sep 2025 13:31:14 GMT Subject: RFR: 8367320: Sort cpu/x86 includes [v2] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 13:12:43 GMT, Stefan Karlsson wrote: >> I'm going to open a PR with a small change in `style-guide.md` to start the discussion. > > Just note that we currently don't have a consistent way that we structure the inclusions of our the platform dependent files. When making the patch that followed the "corresponding .hpp" rule I had to handle the includes on case-by-case basis. Just be warned that you might create a rule that we can't adhere to without rewriting some of the includes patterns. Hi @stefank, I've just opened #27259. > Just be warned that you might create a rule that we can't adhere to without rewriting some of the includes patterns. What do you mean? Do you have an example? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27189#discussion_r2344267959 From fandreuzzi at openjdk.org Fri Sep 12 13:35:12 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 12 Sep 2025 13:35:12 GMT Subject: RFR: 8367546: Clarify meaning of "corresponding header" for architecture-qualified .inline.hpp files Message-ID: <5CObrpoaAu3vff-Xv8k3o_s-5bBoKU5Y3Rd2BsBapXE=.c806157f-bea6-47b1-b50c-3a60c89b3d93@github.com> During the review of #27189 we stumbled on the lack of a clear indication of what constitutes the `corresponding .hpp` file for a `.inline.hpp` file having an architecture qualifier. For example, `continuationHelper_x86.inline.hpp` includes `runtime/continuationHelper.hpp`, and the include statement is on top as stated in the style guide: #ifndef CPU_X86_CONTINUATIONHELPER_X86_INLINE_HPP #define CPU_X86_CONTINUATIONHELPER_X86_INLINE_HPP #include "runtime/continuationHelper.hpp" #include "runtime/continuationEntry.inline.hpp" #include "runtime/frame.inline.hpp" #include "runtime/registerMap.hpp" [...] However, this order is not respected by `SortIncludes.java`, which does not designate `runtime/continuationHelper.hpp` as the "corresponding `.hpp` file". If this concept was clarified in the style guide, we could improve `SortIncludes` accordingly. ------------- Commit messages: - change guide Changes: https://git.openjdk.org/jdk/pull/27259/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27259&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367546 Stats: 15 lines in 2 files changed: 9 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27259.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27259/head:pull/27259 PR: https://git.openjdk.org/jdk/pull/27259 From cnorrbin at openjdk.org Fri Sep 12 14:07:25 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Fri, 12 Sep 2025 14:07:25 GMT Subject: RFR: 8367536: Change RBTree to use C++17 features Message-ID: Hi everyone, C++17 lets us tidy up som of the ugly templating done in the red-black tree. We can replace the `std::false_type`/`std::true_type` tricks used to discover comparator and verifier signatures with the new `std::is_invocable(_r_v)`, and most of the overload/SFINAE noise can disappear thanks to `if constexpr`. We can now write one-liners such as: ```c++ static constexpr bool HasKeyComparator = std::is_invocable_r_v; and then select the right branch with ```c++ if constexpr (HasKeyComparator) { } inside a single function instead of having several `ENABLE_IF` overloads. This results in fewer lines, clearer intent, and more readable errors, while keeping behaviour identical. Testing: - Oracle tiers 1-3 ------------- Commit messages: - is_invocable/if constexpr Changes: https://git.openjdk.org/jdk/pull/27260/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27260&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367536 Stats: 61 lines in 2 files changed: 9 ins; 23 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/27260.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27260/head:pull/27260 PR: https://git.openjdk.org/jdk/pull/27260 From fandreuzzi at openjdk.org Fri Sep 12 14:23:35 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 12 Sep 2025 14:23:35 GMT Subject: RFR: 8367476: Shenandoah: Remove use of CollectedHeap::_soft_ref_policy [v2] In-Reply-To: References: Message-ID: > Similarly to what was done in #26496 and #26648, the usages of `CollectedHeap::_soft_ref_policy` in Shenandoah can be replaced with an earlier call to `ShenandoahReferenceProcessor::set_soft_reference_policy`. > > This is the last usage of `CollectedHeap::_soft_ref_policy`, so it can be removed. > > Passes tier(1,2,3)_gc_shenandoah. Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: - eagerly initialize to always-clear - move to gccause ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27239/files - new: https://git.openjdk.org/jdk/pull/27239/files/01e41d7b..a55b8bd2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27239&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27239&range=00-01 Stats: 30 lines in 8 files changed: 11 ins; 12 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27239.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27239/head:pull/27239 PR: https://git.openjdk.org/jdk/pull/27239 From fandreuzzi at openjdk.org Fri Sep 12 14:23:37 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 12 Sep 2025 14:23:37 GMT Subject: RFR: 8367476: Shenandoah: Remove use of CollectedHeap::_soft_ref_policy [v2] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 11:00:01 GMT, Albert Mingkun Yang wrote: >> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: >> >> - eagerly initialize to always-clear >> - move to gccause > > src/hotspot/share/gc/shared/collectedHeap.hpp line 239: > >> 237: return cause == GCCause::_metadata_GC_clear_soft_refs || >> 238: cause == GCCause::_wb_full_gc; >> 239: } > > I feel that it makes more sense to have this in `GCCause`. 035963eb771c9c614cc98affdbbb18ec86a53e78 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27239#discussion_r2344402767 From cnorrbin at openjdk.org Fri Sep 12 15:01:36 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Fri, 12 Sep 2025 15:01:36 GMT Subject: RFR: 8367536: Change RBTree to use C++17 features [v2] In-Reply-To: References: Message-ID: > Hi everyone, > > C++17 lets us tidy up som of the ugly templating done in the red-black tree. We can replace the `std::false_type`/`std::true_type` tricks used to discover comparator and verifier signatures with the new `std::is_invocable(_r_v)`, and most of the overload/SFINAE noise can disappear thanks to `if constexpr`. > > We can now write one-liners such as: > ```c++ > static constexpr bool HasKeyComparator = std::is_invocable_r_v; > > > and then select the right branch with > ```c++ > if constexpr (HasKeyComparator) { } > > inside a single function instead of having several `ENABLE_IF` overloads. > > This results in fewer lines, clearer intent, and more readable errors, while keeping behaviour identical. > > Testing: > - Oracle tiers 1-3 Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: removed unneeded CMP templates ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27260/files - new: https://git.openjdk.org/jdk/pull/27260/files/0c6b03c8..f20fc8e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27260&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27260&range=00-01 Stats: 10 lines in 1 file changed: 0 ins; 3 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27260.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27260/head:pull/27260 PR: https://git.openjdk.org/jdk/pull/27260 From stefank at openjdk.org Fri Sep 12 15:02:24 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 12 Sep 2025 15:02:24 GMT Subject: RFR: 8367320: Sort cpu/x86 includes [v2] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 13:27:52 GMT, Francesco Andreuzzi wrote: >> Just note that we currently don't have a consistent way that we structure the inclusions of our the platform dependent files. When making the patch that followed the "corresponding .hpp" rule I had to handle the includes on case-by-case basis. Just be warned that you might create a rule that we can't adhere to without rewriting some of the includes patterns. > > Hi @stefank, I've just opened #27259. > >> Just be warned that you might create a rule that we can't adhere to without rewriting some of the includes patterns. > > What do you mean? Do you have an example? For example, take a look at the various frame* files: frame.inline.hpp include frame.hpp - this is according to our rules frame.hpp does one of our weird tricks to include the frame_.hpp straight into the middle of the frame class (via the CPU_HEADER macro). frame_.inline.hpp can therefore not include the corresponding frame_.hpp because if it did it would include the cpu-dependent parts of the frame class and that will not work. Another think one has to consider is if the includes are written so that the platform files can be included stand-alone or not: Sometimes we have this include order: file.inline.hpp includes file.hpp and file_.inline.hpp file_.inline.hpp doesn't include file.hpp because the only way to use file_.inline.hpp is to include file.inline.hpp. file_.inline.hpp can't be included stand-alone. Sometimes we the opposite include order: file_.inline.hpp includes file.inline.hpp, which includes file.hpp, and file_.inline.hpp can be included stand-alone. If you are going to write a style guide for the platform includes you need to go through our includes and see if your proposal matches what we have. If not, you need to figure out if there's some refactoring that can be done to change files to match the proposal. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27189#discussion_r2344516463 From asmehra at openjdk.org Fri Sep 12 15:16:10 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 12 Sep 2025 15:16:10 GMT Subject: RFR: 8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 03:31:02 GMT, Ioi Lam wrote: > Support of `-XX:+AOTClassLinking` for dynamic CDS archive is not an documented feature of [JEP 483](https://openjdk.org/jeps/483). It has very small performance benefit and complicates the development of future AOT optimizations. > > After this PR, `-XX:+AOTClassLinking` will have no effect when creating a dynamic CDS archive. This looks good. Just wondering if we should report any message if `-XX:+AOTClassLinking` is specified when creating a dynamic archive? I think this patch silently ignores it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27242#issuecomment-3285678073 From ayang at openjdk.org Fri Sep 12 15:21:22 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 12 Sep 2025 15:21:22 GMT Subject: RFR: 8367476: Shenandoah: Remove use of CollectedHeap::_soft_ref_policy [v2] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 14:23:35 GMT, Francesco Andreuzzi wrote: >> Similarly to what was done in #26496 and #26648, the usages of `CollectedHeap::_soft_ref_policy` in Shenandoah can be replaced with an earlier call to `ShenandoahReferenceProcessor::set_soft_reference_policy`. >> >> This is the last usage of `CollectedHeap::_soft_ref_policy`, so it can be removed. >> >> Passes tier1-2, and tier3_gc_shenandoah. > > Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: > > - eagerly initialize to always-clear > - move to gccause I have reviewed all non-Shenandoah code. ------------- Marked as reviewed by ayang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27239#pullrequestreview-3217218522 From ayang at openjdk.org Fri Sep 12 16:12:18 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 12 Sep 2025 16:12:18 GMT Subject: RFR: 8367536: Change RBTree to use C++17 features [v2] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 15:01:36 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> C++17 lets us tidy up som of the ugly templating done in the red-black tree. We can replace the `std::false_type`/`std::true_type` tricks used to discover comparator and verifier signatures with the new `std::is_invocable(_r_v)`, and most of the overload/SFINAE noise can disappear thanks to `if constexpr`. >> >> We can now write one-liners such as: >> ```c++ >> static constexpr bool HasKeyComparator = std::is_invocable_r_v; >> >> >> and then select the right branch with >> ```c++ >> if constexpr (HasKeyComparator) { } >> >> inside a single function instead of having several `ENABLE_IF` overloads. >> >> This results in fewer lines, clearer intent, and more readable errors, while keeping behaviour identical. >> >> Testing: >> - Oracle tiers 1-3 > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > removed unneeded CMP templates Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27260#pullrequestreview-3217577694 From fandreuzzi at openjdk.org Fri Sep 12 16:14:22 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 12 Sep 2025 16:14:22 GMT Subject: RFR: 8367320: Sort cpu/x86 includes [v2] In-Reply-To: References: Message-ID: <_4mRtYH_RWgbVHs49HojPPTYfzSidVOKkCypb-nSBbc=.b1854ffb-1b14-470d-9350-6f02d5673dd7@github.com> On Fri, 12 Sep 2025 14:59:45 GMT, Stefan Karlsson wrote: >> Hi @stefank, I've just opened #27259. >> >>> Just be warned that you might create a rule that we can't adhere to without rewriting some of the includes patterns. >> >> What do you mean? Do you have an example? > > For example, take a look at the various frame* files: > > frame.inline.hpp include frame.hpp - this is according to our rules > frame.hpp does one of our weird tricks to include the frame_.hpp straight into the middle of the frame class (via the CPU_HEADER macro). > frame_.inline.hpp can therefore not include the corresponding frame_.hpp because if it did it would include the cpu-dependent parts of the frame class and that will not work. > > Another think one has to consider is if the includes are written so that the platform files can be included stand-alone or not: > > Sometimes we have this include order: > file.inline.hpp includes file.hpp and file_.inline.hpp > file_.inline.hpp doesn't include file.hpp because the only way to use file_.inline.hpp is to include file.inline.hpp. file_.inline.hpp can't be included stand-alone. > > Sometimes we the opposite include order: > file_.inline.hpp includes file.inline.hpp, which includes file.hpp, and file_.inline.hpp can be included stand-alone. > > If you are going to write a style guide for the platform includes you need to go through our includes and see if your proposal matches what we have. If not, you need to figure out if there's some refactoring that can be done to change files to match the proposal. Thanks for the detailed summary, indeed it looks like my initial proposal is not enough to address all cases. I'll think about it and go through the cases as you suggested. For the time being, I moved #27259 to draft. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27189#discussion_r2344728131 From duke at openjdk.org Fri Sep 12 16:36:56 2025 From: duke at openjdk.org (Ruben) Date: Fri, 12 Sep 2025 16:36:56 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v4] In-Reply-To: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: > The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. > > According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. Ruben has updated the pull request incrementally with two additional commits since the last revision: - Offset the deoptimization handler entry point Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722 - Revert "Ensure stub code is not adjacent to a call" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26678/files - new: https://git.openjdk.org/jdk/pull/26678/files/1f6546e9..47178248 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26678&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26678&range=02-03 Stats: 144 lines in 20 files changed: 41 ins; 34 del; 69 mod Patch: https://git.openjdk.org/jdk/pull/26678.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26678/head:pull/26678 PR: https://git.openjdk.org/jdk/pull/26678 From duke at openjdk.org Fri Sep 12 16:40:47 2025 From: duke at openjdk.org (Ruben) Date: Fri, 12 Sep 2025 16:40:47 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v2] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Mon, 1 Sep 2025 09:51:38 GMT, Andrew Dinn wrote: >> If we end up adding a nop or illegal instruction, then we can also undo the work-around that we did in JDK-8172844 for a similar problem. > > @dean-long I think there is an alternative fix for this that we should consider. The problem here arises because a return address for a legitimate call from the body may alias the nmethod's deopt_handler start. However, that aliasing is solely down to how we are recording and comparing addresses and I think we can easily and safely avoid it. > > The nmethod's deopt handler offset is set to identify the start of the deopt handler code generated into the stubs area. We need to be able to identify that stub's first instruction because we have to patch it into the stack or link register as a return address and then return to it in order to initiate a deopt. Removing the exception handler means it is now possible for it to directly follow the main code and alias the return address of a trailing call. > > We actually work hard to ensure that this same start address is recorded on the stack when we enter the deopt blob. The generated handler code always uses a jump to enter the deopt blob. However, it makes that jump look like a call by patching in a return address that equals the stub start. On Intel we make a fake call in order to push a return address and then carefully decrement the pushed address to refer to the stub start rather than the pushed address (i.e. the one that follows the fake call). On aarch64 it requires less work. The stub start is loaded into lr before jumping effectively simulating a call that just preceded the start address. > > Doing all this fiddling of the return pc is what makes the frame code test for a deopt caller frame both *simple* -- just compare the pc to the nmethod's deopt address -- and *ambiguous* -- oops! it could have been a trailing call in the main code. However, we can easily avoid the ambiguity. We can switch to an actual call in the generated code and adjust the deopt_pc test in the frame code to look for the nmethod's deopt address *plus* some arch-specific constant offset. The offset's size is determined by whatever instructions we need to plant in order to get to and make the call. We can make this safe against code changes by binding a label after the call and asserting that the difference between the label address and stub start address equals the relevant constant. > > That will give correct results if we traverse the frame stack inside or below the deopt blob code. But what about when we fiddle the return stack to force a return into the deopt stub? i.e. when the return address is the nmethod's deopt stub address? I don't b... Thank you, @adinn , @dean-long. I've updated the patch: - Reverted the change adding NOPs at the end of main code section - Moved the deoptimization handler stub code entry point to the end of the stub. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3286011603 From fparain at openjdk.org Fri Sep 12 18:08:10 2025 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 12 Sep 2025 18:08:10 GMT Subject: RFR: 8367368: Add message for verify_legal_class_modifiers for inner classes [v5] In-Reply-To: <2IsSbuyOwrA9e4E47_sbgNaYledCEI4aFwdLL3IpH90=.c70ccf22-c964-472f-bc24-f14da9fc475d@github.com> References: <2IsSbuyOwrA9e4E47_sbgNaYledCEI4aFwdLL3IpH90=.c70ccf22-c964-472f-bc24-f14da9fc475d@github.com> Message-ID: <-mYpdYUfzwJikkdMXAE6Sh_l3zeW5cM3UxqYyEUinQU=.4fff38a2-2371-4c81-ba93-12019e15605f@github.com> On Thu, 11 Sep 2025 18:14:57 GMT, Coleen Phillimore wrote: >> This adds the inner class name (or unnamed) to the error message for invalid inner class modifiers. >> Testing with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Only test for message fragments - Chen's comments. Marked as reviewed by fparain (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27201#pullrequestreview-3218117395 From ayang at openjdk.org Fri Sep 12 18:46:21 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 12 Sep 2025 18:46:21 GMT Subject: RFR: 8367320: Sort cpu/x86 includes [v2] In-Reply-To: <_4mRtYH_RWgbVHs49HojPPTYfzSidVOKkCypb-nSBbc=.b1854ffb-1b14-470d-9350-6f02d5673dd7@github.com> References: <_4mRtYH_RWgbVHs49HojPPTYfzSidVOKkCypb-nSBbc=.b1854ffb-1b14-470d-9350-6f02d5673dd7@github.com> Message-ID: On Fri, 12 Sep 2025 16:11:21 GMT, Francesco Andreuzzi wrote: >> For example, take a look at the various frame* files: >> >> frame.inline.hpp include frame.hpp - this is according to our rules >> frame.hpp does one of our weird tricks to include the frame_.hpp straight into the middle of the frame class (via the CPU_HEADER macro). >> frame_.inline.hpp can therefore not include the corresponding frame_.hpp because if it did it would include the cpu-dependent parts of the frame class and that will not work. >> >> Another think one has to consider is if the includes are written so that the platform files can be included stand-alone or not: >> >> Sometimes we have this include order: >> file.inline.hpp includes file.hpp and file_.inline.hpp >> file_.inline.hpp doesn't include file.hpp because the only way to use file_.inline.hpp is to include file.inline.hpp. file_.inline.hpp can't be included stand-alone. >> >> Sometimes we the opposite include order: >> file_.inline.hpp includes file.inline.hpp, which includes file.hpp, and file_.inline.hpp can be included stand-alone. >> >> If you are going to write a style guide for the platform includes you need to go through our includes and see if your proposal matches what we have. If not, you need to figure out if there's some refactoring that can be done to change files to match the proposal. > > Thanks for the detailed summary, indeed it looks like my initial proposal is not enough to address all cases. I'll think about it and go through the cases as you suggested. > > For the time being, I moved #27259 to draft. > Another think one has to consider is if the includes are written so that the platform files can be included stand-alone or not If a header file (hpp or inline.hpp) can not be included stand alone, I would even argue it's not really a proper header file. Even though `#include` is indeed just copy-and-paste, the use of `#include CPU_HEADER(frame)` still feels like an overuse of C/C++ header includes. I think those "improper" header files can "stand out" if they are named differently from ordinary one, maybe sth like `frame_X.partial.hpp`. My 2c. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27189#discussion_r2345139816 From kbarrett at openjdk.org Fri Sep 12 19:00:24 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 12 Sep 2025 19:00:24 GMT Subject: RFR: 8367282: FORBID_C_FUNCTION needs exception spec consistent with library declaration In-Reply-To: <7sJAFJWdrr4puSCJh8Fp4ihtuAK7q_BCvEy2oaruxNU=.8c94ec16-02af-4084-9364-6d3de0dd9294@github.com> References: <7sJAFJWdrr4puSCJh8Fp4ihtuAK7q_BCvEy2oaruxNU=.8c94ec16-02af-4084-9364-6d3de0dd9294@github.com> Message-ID: On Wed, 10 Sep 2025 12:21:27 GMT, Matthias Baesken wrote: >> Please review this change to FORBID_C_FUNCTION to make the exception specs of >> the forbidding declarations match up with the exception specs of the >> associated library declarations. This needs to account for different platform >> libraries either having or not having exception specs. It's needed because, >> after switching to C++17, some compilers complain about some differences in >> the exception specs. >> >> Also removed the workaround for JDK-8367051, which should no longer be needed >> after this change. >> >> Hoping someone will test the aix-ppc port. @MBaesken or @TheRealMDoerr ? >> >> Testing: mach5 tier1, GHA sanity checks (nearly finished) >> Locally (linux-aarch64) built with clang, which failed without the JDK-8367051 >> workaround. > > Seems the forbidden sprintf AND snprintf cause the trouble on AIX, if I uncomment those 2 from forbiddenFunctions.hpp on top of this patch > > /* > FORBID_C_FUNCTION(int sprintf(char*, const char*, ...), noexcept, "use os::snprintf"); > FORBID_C_FUNCTION(int snprintf(char*, size_t, const char*, ...), noexcept, "use os::snprintf"); > */ > > the rest of forbidden functions causes no trouble on AIX, the build is successful. Thanks for reviews @MBaesken and @dholmes-ora ------------- PR Comment: https://git.openjdk.org/jdk/pull/27180#issuecomment-3286487853 From kbarrett at openjdk.org Fri Sep 12 19:00:25 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 12 Sep 2025 19:00:25 GMT Subject: Integrated: 8367282: FORBID_C_FUNCTION needs exception spec consistent with library declaration In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 02:58:31 GMT, Kim Barrett wrote: > Please review this change to FORBID_C_FUNCTION to make the exception specs of > the forbidding declarations match up with the exception specs of the > associated library declarations. This needs to account for different platform > libraries either having or not having exception specs. It's needed because, > after switching to C++17, some compilers complain about some differences in > the exception specs. > > Also removed the workaround for JDK-8367051, which should no longer be needed > after this change. > > Hoping someone will test the aix-ppc port. @MBaesken or @TheRealMDoerr ? > > Testing: mach5 tier1, GHA sanity checks (nearly finished) > Locally (linux-aarch64) built with clang, which failed without the JDK-8367051 > workaround. This pull request has now been integrated. Changeset: 4e59c63e Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/4e59c63ec5a896a09f61a019e2fc5a2ec75ec40e Stats: 73 lines in 4 files changed: 31 ins; 9 del; 33 mod 8367282: FORBID_C_FUNCTION needs exception spec consistent with library declaration Reviewed-by: dholmes, mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/27180 From coleenp at openjdk.org Fri Sep 12 19:02:37 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 12 Sep 2025 19:02:37 GMT Subject: RFR: 8367368: Add message for verify_legal_class_modifiers for inner classes [v5] In-Reply-To: <2IsSbuyOwrA9e4E47_sbgNaYledCEI4aFwdLL3IpH90=.c70ccf22-c964-472f-bc24-f14da9fc475d@github.com> References: <2IsSbuyOwrA9e4E47_sbgNaYledCEI4aFwdLL3IpH90=.c70ccf22-c964-472f-bc24-f14da9fc475d@github.com> Message-ID: On Thu, 11 Sep 2025 18:14:57 GMT, Coleen Phillimore wrote: >> This adds the inner class name (or unnamed) to the error message for invalid inner class modifiers. >> Testing with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Only test for message fragments - Chen's comments. Thanks for reviewing David, Chen and Fred. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27201#issuecomment-3286493701 From coleenp at openjdk.org Fri Sep 12 19:02:39 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 12 Sep 2025 19:02:39 GMT Subject: RFR: 8367368: Add message for verify_legal_class_modifiers for inner classes [v5] In-Reply-To: References: <2IsSbuyOwrA9e4E47_sbgNaYledCEI4aFwdLL3IpH90=.c70ccf22-c964-472f-bc24-f14da9fc475d@github.com> Message-ID: On Thu, 11 Sep 2025 21:32:02 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Only test for message fragments - Chen's comments. > > src/hotspot/share/classfile/classFileParser.cpp line 4316: > >> 4314: ); >> 4315: } else { >> 4316: if (is_anonymous_inner_class) { > > I think you could have just defined "" as a default name to use here rather then explicitly passing in the parameter. It wouldn't have been a better message though, or else I'd have to check for vmSymbols::null_symbol (which we don't have). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27201#discussion_r2345168927 From coleenp at openjdk.org Fri Sep 12 19:02:41 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 12 Sep 2025 19:02:41 GMT Subject: Integrated: 8367368: Add message for verify_legal_class_modifiers for inner classes In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 18:38:56 GMT, Coleen Phillimore wrote: > This adds the inner class name (or unnamed) to the error message for invalid inner class modifiers. > Testing with tier1-4. This pull request has now been integrated. Changeset: 84aa2952 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/84aa295227749f5daf73100550355ac6d56a6eca Stats: 378 lines in 5 files changed: 368 ins; 0 del; 10 mod 8367368: Add message for verify_legal_class_modifiers for inner classes Reviewed-by: dholmes, fparain ------------- PR: https://git.openjdk.org/jdk/pull/27201 From liach at openjdk.org Fri Sep 12 19:14:27 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 12 Sep 2025 19:14:27 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v4] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 11:28:41 GMT, Jaikiran Pai wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Update NPE per roger review > > Hello Chen, I had a look at the changes, but I'm missing some broader context of this change. > > The JBS issue and the PR description states that this PR is in preparation (to upcoming additional work?) to support better `NullPointerException` exception messages when some code uses `Objects.requireNonNull()`. It also talks about a `java.lang.runtime.Checks::nullCheck` method, but there's no such `java.lang.runtime.Checks` class in mainline and it appears to be a proposed class in Valhalla project (https://bugs.openjdk.org/browse/JDK-8357936). But there too it's non-existent for now. So I'll leave out the `Checks` class from this discussion. > > If this change were to be integrated into mainline, would there be any change to NullPointerException exception messages in any code paths? If not, then would it better to do these changes along with the `Objects.requireNonNull()` change itself, as part of https://bugs.openjdk.org/browse/JDK-8233268? In JDK-8233268, there's also a comment from Goetz proposing how the new exception message should look like. If the current changes were to be done, would it allow for that proposal to be implemented? > > I did have a brief look at the new jtreg test cases in this PR, but it wasn't immediately clear to me which APIs would start seeing this new proposed exception messages. Hi @jaikiran, this is currently neutral to mainline. I split the actual Objects.rNN changes because they have to go through CSR reviews. The actual change to hook it up was removed in https://github.com/openjdk/jdk/pull/26600/commits/39c2d16fa98276319d18cf9334e1e9c794e56779. The message is not the same as what Goetz Lindenmaier proposed, in part because the information about the source of the exception is already obvious in the stack traces (top level is always the null check API). I decided to only include which slot had null instead. In the test suite, the new API to see the proposed new exception messages would be `NullCheckAPITest::nullCheck`. This demonstrates the flexibility of this new system I added. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26600#issuecomment-3286532403 From bmaillard at openjdk.org Fri Sep 12 20:20:15 2025 From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard) Date: Fri, 12 Sep 2025 20:20:15 GMT Subject: RFR: 8360389: Support printing from C2 compiled code [v10] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 12:57:00 GMT, Beno?t Maillard wrote: >> This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types. >> >> ## Usage >> >> Suppose we have this piece of Java code, that simply computes an arithmetic operation, and >> that we compile `square` with C2. >> >> class Square { >> static int square(int a) { >> return a * a; >> } >> >> public static void main(String[] args) { >> square(9); >> } >> } >> >> >> We would like to inspect the node that contains the value returned in this method. >> We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect. >> >> ```c++ >> void Compile::return_values(JVMState* jvms) { >> GraphKit kit(jvms); >> Node* ret = new ReturnNode(TypeFunc::Parms, >> kit.control(), >> kit.i_o(), >> kit.reset_memory(), >> kit.frameptr(), >> kit.returnadr()); >> // Add zero or 1 return values >> int ret_size = tf()->range()->cnt() - TypeFunc::Parms; >> >> >> Node* return_value; >> if (ret_size > 0) { >> kit.inc_sp(-ret_size); // pop the return value(s) >> kit.sync_jvms(); >> return_value = kit.argument(0); >> ret->add_req(return_value); >> >> // <-------------------- Simply insert this >> C->make_debug_print("return: ", initial_gvn(), return_value); >> } >> >> // bind it to root >> root()->add_req(ret); >> record_for_igvn(ret); >> initial_gvn()->transform(ret); >> } >> >> >> We can then call run our code with `-XX:CompileCommand="compileonly,Square::square` >> and we get the following output: >> >> >> return: >> int 81 >> >> >> This case is of course trivial, but more useful examples are shown later. >> >> ## Implementation >> >> The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed. >> >> The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the ... > > Beno?t Maillard has updated the pull request incrementally with two additional commits since the last revision: > > - Simplify logic to single pass over the graph in pick_control > - Add more comments I made a few more changes to simplify the logic and improve the style, this is ready for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26475#issuecomment-3286710599 From sspitsyn at openjdk.org Fri Sep 12 21:37:05 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 12 Sep 2025 21:37:05 GMT Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired [v9] In-Reply-To: References: Message-ID: > The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27. > > TBD: Need to submit a related CSR. > > There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams: > - Class redefinition/retransformation can impact lambda expressions which are supported with private methods > - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now). > > Testing: > - mach5 tiers 1-6 are good > - may need to run mach5 tiers > 6 Serguei Spitsyn 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 nine additional commits since the last revision: - Merge - Merge - Merge - Merge - Merge - review: replace RESERVED flag with UNUSED - review: keep right order of the obsoleted VM options - corrected one assert message - 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26232/files - new: https://git.openjdk.org/jdk/pull/26232/files/df91f171..70a595aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=07-08 Stats: 67844 lines in 2326 files changed: 39746 ins; 16876 del; 11222 mod Patch: https://git.openjdk.org/jdk/pull/26232.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26232/head:pull/26232 PR: https://git.openjdk.org/jdk/pull/26232 From fandreuzzi at openjdk.org Fri Sep 12 21:37:19 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 12 Sep 2025 21:37:19 GMT Subject: RFR: 8367576: JvmtiThreadState::_debuggable is unused Message-ID: The flag has been there since 8153779ad32d1e8ddd37ced826c76c7aafc61894, but seems to be unused. Testing: `tier1`. ------------- Commit messages: - remove Changes: https://git.openjdk.org/jdk/pull/27265/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27265&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367576 Stats: 10 lines in 2 files changed: 0 ins; 10 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27265.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27265/head:pull/27265 PR: https://git.openjdk.org/jdk/pull/27265 From amenkov at openjdk.org Fri Sep 12 22:09:15 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 12 Sep 2025 22:09:15 GMT Subject: RFR: 8367576: JvmtiThreadState::_debuggable is unused In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 21:28:41 GMT, Francesco Andreuzzi wrote: > The flag has been there since 8153779ad32d1e8ddd37ced826c76c7aafc61894, but seems to be unused. > > Testing: `tier1`. Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27265#pullrequestreview-3218928154 From dlong at openjdk.org Sat Sep 13 00:00:22 2025 From: dlong at openjdk.org (Dean Long) Date: Sat, 13 Sep 2025 00:00:22 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v4] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Fri, 12 Sep 2025 16:36:56 GMT, Ruben wrote: >> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. >> >> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. > > Ruben has updated the pull request incrementally with two additional commits since the last revision: > > - Offset the deoptimization handler entry point > > Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722 > - Revert "Ensure stub code is not adjacent to a call" I think this version is an improvement, so still good. ------------- Marked as reviewed by dlong (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26678#pullrequestreview-3219095546 From ayang at openjdk.org Sat Sep 13 13:46:38 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Sat, 13 Sep 2025 13:46:38 GMT Subject: RFR: 8367576: JvmtiThreadState::_debuggable is unused In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 21:28:41 GMT, Francesco Andreuzzi wrote: > The flag has been there since 8153779ad32d1e8ddd37ced826c76c7aafc61894, but seems to be unused. > > Testing: `tier1`. Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27265#pullrequestreview-3220782480 From duke at openjdk.org Sat Sep 13 19:15:17 2025 From: duke at openjdk.org (duke) Date: Sat, 13 Sep 2025 19:15:17 GMT Subject: RFR: 8367576: JvmtiThreadState::_debuggable is unused In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 21:28:41 GMT, Francesco Andreuzzi wrote: > The flag has been there since 8153779ad32d1e8ddd37ced826c76c7aafc61894, but seems to be unused. > > Testing: `tier1`. @fandreuz Your change (at version a2712d42c18830058c1cee6b530c8b9d94b1ecd3) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27265#issuecomment-3288747493 From duke at openjdk.org Sun Sep 14 08:42:53 2025 From: duke at openjdk.org (jonghoonpark) Date: Sun, 14 Sep 2025 08:42:53 GMT Subject: RFR: 8364927: Move SmapsParser from runtime/os/TestTracePageSizes.java into testlib Message-ID: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com> related jira issue: https://bugs.openjdk.org/browse/JDK-8366716 --- Following the direction outlined in the issue description, I've extracted the common parts from `TestTracePageSizes` and `TestTransparentHugePagesHeap` to implement the `SmapsParser` test library. I've confirmed that it works without issues in my local tests. Reviews and feedback are welcome. ------------- Commit messages: - Refactor: Introduce SmapsParser Changes: https://git.openjdk.org/jdk/pull/27273/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27273&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364927 Stats: 459 lines in 3 files changed: 234 ins; 212 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/27273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27273/head:pull/27273 PR: https://git.openjdk.org/jdk/pull/27273 From duke at openjdk.org Sun Sep 14 10:02:45 2025 From: duke at openjdk.org (jonghoonpark) Date: Sun, 14 Sep 2025 10:02:45 GMT Subject: RFR: 8364927: Move SmapsParser from runtime/os/TestTracePageSizes.java into testlib [v2] In-Reply-To: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com> References: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com> Message-ID: <7KPVHAnRl-SW1Bg0tFf5CcIkYf0XYlhrwwWFXXi-jYk=.9fe16f05-9689-4eb4-8bdc-3a72eca3a4df@github.com> > related jira issue: https://bugs.openjdk.org/browse/JDK-8366716 > > --- > > Following the direction outlined in the issue description, > I've extracted the common parts from `TestTracePageSizes` and `TestTransparentHugePagesHeap` to implement the `SmapsParser` test library. > > I've confirmed that it works without issues in my local tests. > > Reviews and feedback are welcome. jonghoonpark has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: Refactor: Introduce SmapsParser Signed-off-by: jonghoonpark ------------- Changes: https://git.openjdk.org/jdk/pull/27273/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27273&range=01 Stats: 491 lines in 3 files changed: 237 ins; 243 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/27273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27273/head:pull/27273 PR: https://git.openjdk.org/jdk/pull/27273 From duke at openjdk.org Sun Sep 14 10:02:46 2025 From: duke at openjdk.org (jonghoonpark) Date: Sun, 14 Sep 2025 10:02:46 GMT Subject: RFR: 8364927: Move SmapsParser from runtime/os/TestTracePageSizes.java into testlib In-Reply-To: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com> References: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com> Message-ID: On Sun, 14 Sep 2025 08:35:53 GMT, jonghoonpark wrote: > related jira issue: https://bugs.openjdk.org/browse/JDK-8366716 > > --- > > Following the direction outlined in the issue description, > I've extracted the common parts from `TestTracePageSizes` and `TestTransparentHugePagesHeap` to implement the `SmapsParser` test library. > > I've confirmed that it works without issues in my local tests. > > Reviews and feedback are welcome. I converted this PR to a draft due to changes in https://github.com/openjdk/jdk/pull/27143 have confirmed that both `TestTracePageSizes` and `TestTransparentHugePagesHeap` pass when tested locally. Additionally, I verified that `TestTransparentHugePagesHeap` also passes without any issues when the `-XX:+UseCompressedOops` option is added, as shown below: OutputAnalyzer oa = ProcessTools.executeTestJava("-XX:+Use" + args[0] + "GC", "-Xmx128m", "-Xms128m", "-Xlog:pagesize:thp-%p.log", "-XX:+UseTransparentHugePages", "-XX:+UseCompressedOops", VerifyTHPEnabledForHeap.class.getName()); Is this the correct way to verify it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27273#issuecomment-3289363658 PR Comment: https://git.openjdk.org/jdk/pull/27273#issuecomment-3289408042 From iklam at openjdk.org Mon Sep 15 04:13:32 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 15 Sep 2025 04:13:32 GMT Subject: RFR: 8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive [v2] In-Reply-To: References: Message-ID: > Support of `-XX:+AOTClassLinking` for dynamic CDS archive is not an documented feature of [JEP 483](https://openjdk.org/jeps/483). It has very small performance benefit and complicates the development of future AOT optimizations. > > After this PR, `-XX:+AOTClassLinking` will have no effect when creating a dynamic CDS archive. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @ashu-mehra comment -- print warning if -XX:+AOTClassLinking is enabled for dynamic dump ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27242/files - new: https://git.openjdk.org/jdk/pull/27242/files/597718c6..e94f0503 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27242&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27242&range=00-01 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27242.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27242/head:pull/27242 PR: https://git.openjdk.org/jdk/pull/27242 From iklam at openjdk.org Mon Sep 15 04:14:39 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 15 Sep 2025 04:14:39 GMT Subject: RFR: 8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 15:13:35 GMT, Ashutosh Mehra wrote: > This looks good. Just wondering if we should report any message if `-XX:+AOTClassLinking` is specified when creating a dynamic archive? I think this patch silently ignores it. I added a warning message as `-XX:+AOTClassLinking` makes a semantic differences -- classes in the archive will be unconditionally loaded at VM start-up, so I think it's a good idea to tell the user that the flag is ignored for dynamic dumps. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27242#issuecomment-3290426302 From stefank at openjdk.org Mon Sep 15 05:58:17 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 15 Sep 2025 05:58:17 GMT Subject: RFR: 8367320: Sort cpu/x86 includes [v2] In-Reply-To: References: <_4mRtYH_RWgbVHs49HojPPTYfzSidVOKkCypb-nSBbc=.b1854ffb-1b14-470d-9350-6f02d5673dd7@github.com> Message-ID: On Fri, 12 Sep 2025 18:43:52 GMT, Albert Mingkun Yang wrote: >> Thanks for the detailed summary, indeed it looks like my initial proposal is not enough to address all cases. I'll think about it and go through the cases as you suggested. >> >> For the time being, I moved #27259 to draft. > >> Another think one has to consider is if the includes are written so that the platform files can be included stand-alone or not > > If a header file (hpp or inline.hpp) can not be included stand alone, I would even argue it's not really a proper header file. > > Even though `#include` is indeed just copy-and-paste, the use of `#include CPU_HEADER(frame)` still feels like an overuse of C/C++ header includes. I think those "improper" header files can "stand out" if they are named differently from ordinary one, maybe sth like `frame_X.partial.hpp`. My 2c. FWIW, while writing the above and looking through the files I had a similar reaction to what Albert writes here. We would still need to differentiate between .hpp and .inline.hpp files. Maybe: file.partial.hpp file.partial.inline.hpp Another interesting pattern we have can be found in the gc_globals.hpp and g1_globals.hpp files: If you want the flags from g1_globals.hpp you must include gc_globals.hpp. g1_globals.hpp can be included stand-alone, but it won't do you much good because the declarations of the flags are generated by including gc_globals.hpp. Should g1_globals.hpp then be named g1_globals.partial.hpp? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27189#discussion_r2347943256 From stefank at openjdk.org Mon Sep 15 06:03:20 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 15 Sep 2025 06:03:20 GMT Subject: RFR: 8366716: Move SmapsParser from runtime/os/TestTracePageSizes.java into testlib In-Reply-To: References: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com> Message-ID: On Sun, 14 Sep 2025 09:57:47 GMT, jonghoonpark wrote: > Is this the correct way to verify it? I think @kstefanj , who wrote the RFE and probably intended to implement it, might have ideas on how to verify this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27273#issuecomment-3290603087 From syan at openjdk.org Mon Sep 15 06:50:13 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 15 Sep 2025 06:50:13 GMT Subject: RFR: 8366716: Move SmapsParser from runtime/os/TestTracePageSizes.java into testlib [v2] In-Reply-To: <7KPVHAnRl-SW1Bg0tFf5CcIkYf0XYlhrwwWFXXi-jYk=.9fe16f05-9689-4eb4-8bdc-3a72eca3a4df@github.com> References: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com> <7KPVHAnRl-SW1Bg0tFf5CcIkYf0XYlhrwwWFXXi-jYk=.9fe16f05-9689-4eb4-8bdc-3a72eca3a4df@github.com> Message-ID: On Sun, 14 Sep 2025 10:02:45 GMT, jonghoonpark wrote: >> related jira issue: https://bugs.openjdk.org/browse/JDK-8366716 >> >> --- >> >> Following the direction outlined in the issue description, >> I've extracted the common parts from `TestTracePageSizes` and `TestTransparentHugePagesHeap` to implement the `SmapsParser` test library. >> >> I've confirmed that it works without issues in my local tests. >> >> Reviews and feedback are welcome. > > jonghoonpark has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > Refactor: Introduce SmapsParser > > Signed-off-by: jonghoonpark Marked as reviewed by syan (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27273#pullrequestreview-3223126472 From sjohanss at openjdk.org Mon Sep 15 06:50:15 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Mon, 15 Sep 2025 06:50:15 GMT Subject: RFR: 8366716: Move SmapsParser from runtime/os/TestTracePageSizes.java into testlib In-Reply-To: References: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com> Message-ID: On Mon, 15 Sep 2025 06:00:48 GMT, Stefan Karlsson wrote: > Is this the correct way to verify it? The problem we had in testing ([JDK-8366980](https://bugs.openjdk.org/browse/JDK-8366980)) was that we saw failures when running with `-XX:-UseCompressedOops` so that should be explicitly verified (`-XX:+UseCompressedOops` is the default). Adding it to the process launcher in the code works for testing, but to test without altering the code you can also pass it in. If you run the tests through make: make test TEST=gc/TestTransparentHugePagesHeap.java JTREG="JAVA_OPTIONS=-XX:-UseCompressedOops" A couple of other comments without doing a proper review is that the new smaps classes should be located along side `HugePageConfiguration` under `lib/os/linux` and I think we want to think about how to structure the classes. Maybe something like this: public class Smaps { public static class Parser { ... } public static class Range { ... } } ------------- PR Comment: https://git.openjdk.org/jdk/pull/27273#issuecomment-3290711581 From sjohanss at openjdk.org Mon Sep 15 06:53:13 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Mon, 15 Sep 2025 06:53:13 GMT Subject: RFR: 8366716: Move SmapsParser from runtime/os/TestTracePageSizes.java into testlib [v2] In-Reply-To: <7KPVHAnRl-SW1Bg0tFf5CcIkYf0XYlhrwwWFXXi-jYk=.9fe16f05-9689-4eb4-8bdc-3a72eca3a4df@github.com> References: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com> <7KPVHAnRl-SW1Bg0tFf5CcIkYf0XYlhrwwWFXXi-jYk=.9fe16f05-9689-4eb4-8bdc-3a72eca3a4df@github.com> Message-ID: On Sun, 14 Sep 2025 10:02:45 GMT, jonghoonpark wrote: >> related jira issue: https://bugs.openjdk.org/browse/JDK-8366716 >> >> --- >> >> Following the direction outlined in the issue description, >> I've extracted the common parts from `TestTracePageSizes` and `TestTransparentHugePagesHeap` to implement the `SmapsParser` test library. >> >> I've confirmed that it works without issues in my local tests. >> >> Reviews and feedback are welcome. > > jonghoonpark has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > Refactor: Introduce SmapsParser > > Signed-off-by: jonghoonpark Changes requested by sjohanss (Reviewer). test/hotspot/jtreg/gc/TestTransparentHugePagesHeap.java line 61: > 59: import jdk.test.lib.process.ProcessTools; > 60: import jdk.test.lib.Platform; > 61: import jdk.test.lib.SmapsParser; Should be located in: `jdk.test.lib.os.linux` ------------- PR Review: https://git.openjdk.org/jdk/pull/27273#pullrequestreview-3223133659 PR Review Comment: https://git.openjdk.org/jdk/pull/27273#discussion_r2348030096 From tschatzl at openjdk.org Mon Sep 15 07:18:14 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 15 Sep 2025 07:18:14 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v61] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * iwalulya review * documentation for a few PSS members * rename some member variables to contain _ct and _rt suffixes in remembered set verification ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/1ced9f98..bf8cab33 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=60 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=59-60 Stats: 25 lines in 3 files changed: 10 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From shade at openjdk.org Mon Sep 15 08:05:20 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 15 Sep 2025 08:05:20 GMT Subject: RFR: 8367576: JvmtiThreadState::_debuggable is unused In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 21:28:41 GMT, Francesco Andreuzzi wrote: > The flag has been there since 8153779ad32d1e8ddd37ced826c76c7aafc61894, but seems to be unused. > > Testing: `tier1`. Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27265#pullrequestreview-3223348796 From fandreuzzi at openjdk.org Mon Sep 15 08:05:21 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Mon, 15 Sep 2025 08:05:21 GMT Subject: Integrated: 8367576: JvmtiThreadState::_debuggable is unused In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 21:28:41 GMT, Francesco Andreuzzi wrote: > The flag has been there since 8153779ad32d1e8ddd37ced826c76c7aafc61894, but seems to be unused. > > Testing: `tier1`. This pull request has now been integrated. Changeset: c16462b3 Author: Francesco Andreuzzi Committer: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/c16462b3b4686982e80fdde6802defafc2de8b1a Stats: 10 lines in 2 files changed: 0 ins; 10 del; 0 mod 8367576: JvmtiThreadState::_debuggable is unused Reviewed-by: amenkov, ayang, shade ------------- PR: https://git.openjdk.org/jdk/pull/27265 From fyang at openjdk.org Mon Sep 15 08:47:13 2025 From: fyang at openjdk.org (Fei Yang) Date: Mon, 15 Sep 2025 08:47:13 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 19:54:41 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > > Currently, the cpu features of riscv are stored in separate RVFeature subclasses. > But to support the store/restore CPU features for aot in the future, we need to store the cpu features in a continuous memory. > As the riscv extensions are introduced continuously, I think it's better to do it via an simple bitmap at the beginning. > Currently, just suppose the non-extension features will not be stored in aot image, so I also split the extension and non-extenion features. When we implement the related aot feature in the short future, we can revisit the way of splitting the features. Currently, just change the storage way of cpu features, lay the foundation for future aot. > > Thanks Hi, I like the idea of separating the two group of flags. I am having a look. BTW: Can you merge and rebase? src/hotspot/cpu/riscv/vm_version_riscv.hpp line 295: > 293: } > 294: > 295: static int index(RVFeatureIndex feature) { Seems better to rename this to `element_index`? src/hotspot/cpu/riscv/vm_version_riscv.hpp line 333: > 331: } > 332: > 333: bool supports_feature(uint32_t feature) { Should this be `support_feature` like its friends `set_feature` or `clear_feature` in style? ------------- PR Review: https://git.openjdk.org/jdk/pull/27152#pullrequestreview-3223494725 PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2348274530 PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2348271850 From azafari at openjdk.org Mon Sep 15 08:49:42 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 15 Sep 2025 08:49:42 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v4] In-Reply-To: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: > The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. > The acceptable value is changed to 64K. > > Tests: > linux-x64 tier1 Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26955/files - new: https://git.openjdk.org/jdk/pull/26955/files/76cf950e..251dd986 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=02-03 Stats: 23 lines in 2 files changed: 0 ins; 0 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/26955.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26955/head:pull/26955 PR: https://git.openjdk.org/jdk/pull/26955 From azafari at openjdk.org Mon Sep 15 08:49:46 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 15 Sep 2025 08:49:46 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v3] In-Reply-To: References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> <-eWIUjA4RqIgcpvFSyFxuiuganZpBqkMIdKSOVhnuMo=.79db2c26-5547-42fa-84d9-9bf5746728cf@github.com> Message-ID: On Fri, 12 Sep 2025 09:01:18 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> lowest can be equal to highest > > src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp line 288: > >> 286: // If an overflow happened in Arguments::set_heap_size(), MaxHeapSize will have too large a value. >> 287: // Check for this by ensuring that MaxHeapSize plus the requested min base address still fit within max_uintx. >> 288: if (value + MaxHeapSize < MaxHeapSize) {// overflow > > Can we perform the overflow check via subtraction from the max value instead? I know that unsigned types do wrap around, but at a first glance this will look wrong and make the reader stop and think. > > Style: Space between { and // > > > if (std::numeric_limits::max() - value < MaxHeapSize) { // overflow Using ` a < a - b` for checking overflow, does not work when `a - b` is negative and it will become a very large number when cast to unsigned. Space added. > src/hotspot/share/memory/memoryReserver.cpp line 560: > >> 558: if (!FLAG_IS_DEFAULT(HeapBaseMinAddress)) { >> 559: reserved = try_reserve_memory(size + noaccess_prefix, alignment, page_size, (char *)aligned_heap_base_min_address); >> 560: if (reserved.base() != (char *)aligned_heap_base_min_address) { // Enforce this exact address. > > Style: Please hug the * to the char for the casts Done. There are some preexisting cases like this. Should I change them too? > src/hotspot/share/memory/memoryReserver.cpp line 584: > >> 582: // Calc address range within we try to attach (range of possible start addresses). >> 583: char* const highest_start = align_down((char *)UnscaledOopHeapMax - size, attach_point_alignment); >> 584: char* const lowest_start = align_up((char *)aligned_heap_base_min_address, attach_point_alignment); > > Keep these as uintptr_t instead and only cast when trying to reserve Done. > src/hotspot/share/memory/memoryReserver.cpp line 595: > >> 593: >> 594: // Give it several tries from top of range to bottom. >> 595: if (aligned_heap_base_min_address + size <= (uintptr_t)zerobased_max && // Zerobased theoretical possible. > > Do the opposite: Have zerobased_max be uintptr_t and only cast it when it needs to become a char* Done. > src/hotspot/share/memory/memoryReserver.cpp line 612: > >> 610: } >> 611: lowest_start = align_up(lowest_start, attach_point_alignment); >> 612: assert(lowest_start <= highest_start, "lowest: " INTPTR_FORMAT " highest: " INTPTR_FORMAT, > > Keep these as uintptr_t and cast to char* only when reserving done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2348276821 PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2348278478 PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2348278713 PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2348279035 PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2348288660 From azafari at openjdk.org Mon Sep 15 09:15:49 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 15 Sep 2025 09:15:49 GMT Subject: RFR: 8358957: [ubsan]: The assert in layout_helper_boolean_diffbit() in klass.hpp needs UB to fail Message-ID: Avoid using loop and UB in left-shift operation as suggested by Kim's comment in the JBS-issue. Tests: mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product} ------------- Commit messages: - 8358957: [ubsan]: The assert in layout_helper_boolean_diffbit() in klass.hpp needs UB to fail Changes: https://git.openjdk.org/jdk/pull/27288/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27288&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358957 Stats: 10 lines in 1 file changed: 1 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/27288.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27288/head:pull/27288 PR: https://git.openjdk.org/jdk/pull/27288 From adinn at openjdk.org Mon Sep 15 09:26:21 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 15 Sep 2025 09:26:21 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v4] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Fri, 12 Sep 2025 16:36:56 GMT, Ruben wrote: >> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. >> >> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. > > Ruben has updated the pull request incrementally with two additional commits since the last revision: > > - Offset the deoptimization handler entry point > > Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722 > - Revert "Ensure stub code is not adjacent to a call" This is a nice, uniform fix that makes the way the deopt entry interacts with the frame code check much clearer. I think we would benefit from a comment in each generator to explain the indirect order of entry and call. src/hotspot/cpu/aarch64/aarch64.ad line 2276: > 2274: __ far_call(RuntimeAddress(SharedRuntime::deopt_blob()->unpack())); > 2275: > 2276: int entry_point = __ offset(); I feel we ought to have a comment somewhere that explains why this backward jump exists so that no one subsequently tries to 'optimize' it away. It would be most helpful right here in the code -- even though that means repeating it in every port's generator file Suggestion: // the entry point is placed immediately after the unpack call so we can test for // it as a return PC marking the nmethod being in deopt int entry_point = __ offset(); ------------- Marked as reviewed by adinn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26678#pullrequestreview-3223645152 PR Review Comment: https://git.openjdk.org/jdk/pull/26678#discussion_r2348370056 From duke at openjdk.org Mon Sep 15 09:49:18 2025 From: duke at openjdk.org (Ruben) Date: Mon, 15 Sep 2025 09:49:18 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v2] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Tue, 19 Aug 2025 11:42:50 GMT, Martin Doerr wrote: >> Ruben has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > Tier 1 has passed on linux ppc64le. Nice cleanup! @TheRealMDoerr, @RealFYang, @offamitkumar, @bulasevich, Could you please take a look at the latest commit and run the tier1 tests on your platforms? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3291313041 From duke at openjdk.org Mon Sep 15 09:55:34 2025 From: duke at openjdk.org (Ruben) Date: Mon, 15 Sep 2025 09:55:34 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v4] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Mon, 15 Sep 2025 09:19:45 GMT, Andrew Dinn wrote: >> Ruben has updated the pull request incrementally with two additional commits since the last revision: >> >> - Offset the deoptimization handler entry point >> >> Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722 >> - Revert "Ensure stub code is not adjacent to a call" > > src/hotspot/cpu/aarch64/aarch64.ad line 2276: > >> 2274: __ far_call(RuntimeAddress(SharedRuntime::deopt_blob()->unpack())); >> 2275: >> 2276: int entry_point = __ offset(); > > I feel we ought to have a comment somewhere that explains why this backward jump exists so that no one subsequently tries to 'optimize' it away. It would be most helpful right here in the code -- even though that means repeating it in every port's generator file > > Suggestion: > > // the entry point is placed immediately after the unpack call so we can test for > // it as a return PC marking the nmethod being in deopt > int entry_point = __ offset(); Thanks for the feedback. I will update the PR to add an explanatory comment at each `emit_deopt_handler`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26678#discussion_r2348462182 From ayang at openjdk.org Mon Sep 15 10:10:24 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 15 Sep 2025 10:10:24 GMT Subject: RFR: 8367150: Add a header line to improve VMErrorCallback printing In-Reply-To: <7kHwLsN1YaX-vrNMs2hojrCnVuTyzxfDEI3323huo_c=.05650b47-8055-4825-8322-f7547e198251@github.com> References: <7kHwLsN1YaX-vrNMs2hojrCnVuTyzxfDEI3323huo_c=.05650b47-8055-4825-8322-f7547e198251@github.com> Message-ID: On Tue, 9 Sep 2025 06:26:43 GMT, Axel Boldt-Christmas wrote: > Currently all the registered VMErrorCallback are printed one after another in the error report with only a newline separating them. It makes harder to both quickly find the section, or differentiate the where one starts and another begins in the case of multiple callbacks. I propose we add a simple header line before each callback. > > > VMErrorCallback 1: > [ First callback's print ] > VMErrorCallback 2: > [ Second callback's print ] Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27160#pullrequestreview-3223850159 From aboldtch at openjdk.org Mon Sep 15 10:13:23 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 15 Sep 2025 10:13:23 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v4] In-Reply-To: References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: On Mon, 15 Sep 2025 08:49:42 GMT, Afshin Zafari wrote: >> The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. >> The acceptable value is changed to 64K. >> >> Tests: >> linux-x64 tier1 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > fixes I agree with @jdksjolen that I think we should go towards using `uintptr_t` as far as possible. Maybe we do it piecemeal like this. Eventually we could end up using `uintptr_t` until we reach the os layer. Looks like you at least have to clean up the `uintptr_t` vs `uint64_t` in the touched methods as some platforms have them define as `unsigned long` vs `unsigned long long`. src/hotspot/share/memory/memoryReserver.cpp line 612: > 610: } > 611: lowest_start = align_up(lowest_start, attach_point_alignment); > 612: assert(lowest_start < highest_start, "lowest: " INTPTR_FORMAT " highest: " INTPTR_FORMAT, We should support a start which is a single value. Suggestion: assert(lowest_start <= highest_start, "lowest: " INTPTR_FORMAT " highest: " INTPTR_FORMAT, ------------- PR Review: https://git.openjdk.org/jdk/pull/26955#pullrequestreview-3223852121 PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2348500738 From amitkumar at openjdk.org Mon Sep 15 10:14:40 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 15 Sep 2025 10:14:40 GMT Subject: RFR: 8367325: [s390x] build failure due to JDK-8361376 [v2] In-Reply-To: References: Message-ID: > Fixes the SIGLL caused after [JDK-8361376](https://bugs.openjdk.org/browse/JDK-8361376). > > Issue was with `cs` instruction, which requires the address to be aligned. And after this change address at which operating was not aligned. > > Wisdom from Principle of Z Operations: > > Sytax: CS R1,R3,D2(B2) > > Sytax: CSY R1,R3,D2(B2) > > ` > The second operand of COMPARE AND SWAP (CS, CSY) must be designated on a word boundary. > ` > > > > => 0x3fffc3149ba <_ZN17BarrierSetNMethod15set_guard_valueEP7nmethodii+266>: cs %r1,%r4,0(%r3) > (gdb) i r r3 > r3 0x3ffe500017a 4397593526650 > (gdb) p ($r3 % 8) > $5 = 2 > (gdb) si > > Thread 16 "C1 CompilerThre" received signal SIGILL, Illegal instruction. > NativeMethodBarrier::set_guard_value (bit_mask=2147483647, value=1, this=0x3ffe5000166) > at /home/amit/jdk/src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp:74 > 74 if (v == old_value) break; Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: better fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27213/files - new: https://git.openjdk.org/jdk/pull/27213/files/668caeb9..3545cf1b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27213&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27213&range=00-01 Stats: 8 lines in 3 files changed: 3 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27213.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27213/head:pull/27213 PR: https://git.openjdk.org/jdk/pull/27213 From amitkumar at openjdk.org Mon Sep 15 10:14:41 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 15 Sep 2025 10:14:41 GMT Subject: RFR: 8367325: [s390x] build failure due to JDK-8361376 [v2] In-Reply-To: References: <6M1CuZ1hFWFJyT-diBc59BSsdr3YuQvZn_rtSc8LP0Q=.608a5dd6-6ed7-44bf-a840-9e89d3b8d742@github.com> Message-ID: On Fri, 12 Sep 2025 08:30:13 GMT, Martin Doerr wrote: >> OK, then how about we align the beginning using >> ` __ align(4, offset() + 3*6 + 2);` >> to make it more self-documenting? > > Or better: define a constant for 3*6 + 2 and reuse it in `class NativeMethodBarrier`. I have updated the code, please have a look now ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27213#discussion_r2348509580 From jsjolen at openjdk.org Mon Sep 15 10:24:52 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 15 Sep 2025 10:24:52 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two Message-ID: Hi, This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array` to store the offsets in and an `Array` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`. We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately. For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc. On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement. Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again. ------------- Commit messages: - Bug - Missing inline - oops again - Oops - Docs - Another one - Simplify further - Rename and simplify - This is wron - Deleting operands Changes: https://git.openjdk.org/jdk/pull/27198/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367656 Stats: 728 lines in 11 files changed: 321 ins; 247 del; 160 mod Patch: https://git.openjdk.org/jdk/pull/27198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27198/head:pull/27198 PR: https://git.openjdk.org/jdk/pull/27198 From mdoerr at openjdk.org Mon Sep 15 10:29:20 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 15 Sep 2025 10:29:20 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v4] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Fri, 12 Sep 2025 16:36:56 GMT, Ruben wrote: >> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. >> >> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. > > Ruben has updated the pull request incrementally with two additional commits since the last revision: > > - Offset the deoptimization handler entry point > > Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722 > - Revert "Ensure stub code is not adjacent to a call" PPC64 is broken, now: assert(cb != nullptr) failed: must be Stack: [0x00006702d7600000,0x00006702d7800000], sp=0x00006702d77f9800, free space=2022k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x7a61d4] frame::setup(frame::kind)+0x4c4 (codeCache.inline.hpp:48) V [libjvm.so+0x7a6c54] frame::sender(RegisterMap*) const+0x724 (frame_ppc.inline.hpp:102) V [libjvm.so+0xb905a8] Deoptimization::fetch_unroll_info_helper(JavaThread*, int)+0x218 (deoptimization.cpp:501) V [libjvm.so+0xb91ecc] Deoptimization::fetch_unroll_info(JavaThread*, int)+0x7c (deoptimization.cpp:297) v ~DeoptimizationBlob 0x00006702cd110874 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3291467814 From kbarrett at openjdk.org Mon Sep 15 10:30:25 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 15 Sep 2025 10:30:25 GMT Subject: RFR: 8358957: [ubsan]: The assert in layout_helper_boolean_diffbit() in klass.hpp needs UB to fail In-Reply-To: References: Message-ID: <_zOzryyrcX3PRWGo7osHOKa9hHfWTsKUi_Sj_bhUMLo=.9c7313b8-268e-41b9-8567-325449c24784@github.com> On Mon, 15 Sep 2025 09:01:56 GMT, Afshin Zafari wrote: > Avoid using loop and UB in left-shift operation as suggested by Kim's comment in the JBS-issue. > > Tests: > mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product} src/hotspot/share/oops/klass.hpp line 515: > 513: > 514: // Want a pattern to quickly diff against layout header in register > 515: // find something less clever! Comment needs to be updated. It should describe what is being calculated, and the 2nd line is presumably resolved by this change. src/hotspot/share/oops/klass.hpp line 526: > 524: // So use alternate form of negation to avoid warning. > 525: uint result = candidates & (~candidates + 1); > 526: return static_cast(result); Since this is the implementation I suggested in JBS, I'm going to leave it to others to approve or not. Maybe there should be a post-condition check that the result meets the requirements. That's simpler than adding a gtest or anything like that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27288#discussion_r2348529098 PR Review Comment: https://git.openjdk.org/jdk/pull/27288#discussion_r2348546757 From iwalulya at openjdk.org Mon Sep 15 10:32:14 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 15 Sep 2025 10:32:14 GMT Subject: RFR: 8366865: G1: Allocation GC Pauses Triggered after JVM has started shutdown [v2] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 08:19:45 GMT, Ivan Walulya wrote: >> src/hotspot/share/gc/shared/collectedHeap.cpp line 616: >> >>> 614: // If the VM is shutting down, we may have skipped VM_CollectForAllocation. >>> 615: // To avoid returning nullptr (which could cause premature OOME), we stall >>> 616: // allocation requests here until the VM shutdown is complete. >> >> If I understand the shutdown sequence correctly, I don't think you can do this without risking a hang. The thread doing the shutdown can potentially execute code that requires allocation after `is_shutting_down()` returns true. This is due to the JVMTI events posted from `before_exit`: >> >> if (JvmtiExport::should_post_thread_life()) { >> JvmtiExport::post_thread_end(thread); >> } >> >> // Always call even when there are not JVMTI environments yet, since environments >> // may be attached late and JVMTI must track phases of VM execution >> JvmtiExport::post_vm_death(); >> >> I think if you can't GC during shutdown then you have to simply let the allocation fail. > > Thanks, I completely overlooked the JVMTI callbacks. It?s probably better to stall with a timeout and then return an allocation failure. I moved the `Universe::before_exit()` call and also added a timed `wait`. @dholmes-ora do you have any concerns with this approach? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2348552023 From mdoerr at openjdk.org Mon Sep 15 10:56:16 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 15 Sep 2025 10:56:16 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v4] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: <2oxU81yPj1mPZcYyy5dimdl0z3B2tIJsieTpkSXmHQk=.4f62a862-38c6-488b-b7c6-016fec53c788@github.com> On Fri, 12 Sep 2025 16:36:56 GMT, Ruben wrote: >> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. >> >> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. > > Ruben has updated the pull request incrementally with two additional commits since the last revision: > > - Offset the deoptimization handler entry point > > Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722 > - Revert "Ensure stub code is not adjacent to a call" I suggest reverting only the PPC64 files to the previous version. That one works. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3291566682 From mdoerr at openjdk.org Mon Sep 15 10:56:16 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 15 Sep 2025 10:56:16 GMT Subject: RFR: 8367325: [s390x] build failure due to JDK-8361376 [v2] In-Reply-To: References: Message-ID: <_GxY7fMDVZ1mv50GHTe7__GPvDOxC-vf1V50TDZuIo8=.4840c726-14a9-4311-87e3-2459e42efe3f@github.com> On Mon, 15 Sep 2025 10:14:40 GMT, Amit Kumar wrote: >> Fixes the SIGLL caused after [JDK-8361376](https://bugs.openjdk.org/browse/JDK-8361376). >> >> Issue was with `cs` instruction, which requires the address to be aligned. And after this change address at which operating was not aligned. >> >> Wisdom from Principle of Z Operations: >> >> Sytax: CS R1,R3,D2(B2) >> >> Sytax: CSY R1,R3,D2(B2) >> >> ` >> The second operand of COMPARE AND SWAP (CS, CSY) must be designated on a word boundary. >> ` >> >> >> >> => 0x3fffc3149ba <_ZN17BarrierSetNMethod15set_guard_valueEP7nmethodii+266>: cs %r1,%r4,0(%r3) >> (gdb) i r r3 >> r3 0x3ffe500017a 4397593526650 >> (gdb) p ($r3 % 8) >> $5 = 2 >> (gdb) si >> >> Thread 16 "C1 CompilerThre" received signal SIGILL, Illegal instruction. >> NativeMethodBarrier::set_guard_value (bit_mask=2147483647, value=1, this=0x3ffe5000166) >> at /home/amit/jdk/src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp:74 >> 74 if (v == old_value) break; > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > better fix src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.hpp line 70: > 68: #endif // COMPILER2 > 69: > 70: static const int PATCHABLE_INSTRUCTION_OFFSET = 3 * 6 + 2; Maybe better call it `PATCHABLE_BARRIER_VALUE_OFFSET`? It's no longer the instruction start address. Or even better: define 2 constants. The version without the +2 is still needed below. src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp line 30: > 28: #include "code/nmethod.hpp" > 29: #include "gc/shared/barrierSetNMethod.hpp" > 30: #include "gc/shared/barrierSetAssembler.hpp" Should be sorted alphabetically. src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp line 43: > 41: address inst_addr = get_barrier_start_address() + BarrierSetAssembler::PATCHABLE_INSTRUCTION_OFFSET; > 42: > 43: DEBUG_ONLY(Assembler::is_z_cfi(*((long*)inst_addr))); The cfi check needs an adjustment to point to the instruction start, right? src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp line 48: > 46: > 47: public: > 48: static const int BARRIER_TOTAL_LENGTH = BarrierSetAssembler::PATCHABLE_INSTRUCTION_OFFSET + 2*6; // bytes Same here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27213#discussion_r2348599191 PR Review Comment: https://git.openjdk.org/jdk/pull/27213#discussion_r2348599782 PR Review Comment: https://git.openjdk.org/jdk/pull/27213#discussion_r2348601880 PR Review Comment: https://git.openjdk.org/jdk/pull/27213#discussion_r2348606577 From duke at openjdk.org Mon Sep 15 12:24:49 2025 From: duke at openjdk.org (jonghoonpark) Date: Mon, 15 Sep 2025 12:24:49 GMT Subject: RFR: 8366716: Move SmapsParser from runtime/os/TestTracePageSizes.java into testlib In-Reply-To: References: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com> Message-ID: <9TeOhgljMCn3RkUFR-N79hsqbiRpMq0RHLh_8-Debjk=.dc863969-02a9-4584-b8a2-9d66e9ca9833@github.com> On Mon, 15 Sep 2025 06:46:43 GMT, Stefan Johansson wrote: >>> Is this the correct way to verify it? >> >> I think @kstefanj , who wrote the RFE and probably intended to implement it, might have ideas on how to verify this. > >> Is this the correct way to verify it? > > The problem we had in testing ([JDK-8366980](https://bugs.openjdk.org/browse/JDK-8366980)) was that we saw failures when running with `-XX:-UseCompressedOops` so that should be explicitly verified (`-XX:+UseCompressedOops` is the default). Adding it to the process launcher in the code works for testing, but to test without altering the code you can also pass it in. If you run the tests through make: > > make test TEST=gc/TestTransparentHugePagesHeap.java JTREG="JAVA_OPTIONS=-XX:-UseCompressedOops" > > > A couple of other comments without doing a proper review is that the new smaps classes should be located along side `HugePageConfiguration` under `lib/os/linux` and I think we want to think about how to structure the classes. Maybe something like this: > > public class Smaps { > public static class Parser { ... } > public static class Range { ... } > } @kstefanj I've also tested it using the method that doesn't require altering the code, and it passed successfully. Now, I'll move the path and refactor the code as you reviewed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27273#issuecomment-3291891500 From jbechberger at openjdk.org Mon Sep 15 12:25:31 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Mon, 15 Sep 2025 12:25:31 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing Message-ID: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> This change hopefully fixes the test failures by making the test cases more resilient. ------------- Commit messages: - Make the auto size test more resilient Changes: https://git.openjdk.org/jdk/pull/27293/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27293&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367302 Stats: 61 lines in 3 files changed: 24 ins; 7 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/27293.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27293/head:pull/27293 PR: https://git.openjdk.org/jdk/pull/27293 From duke at openjdk.org Mon Sep 15 12:51:40 2025 From: duke at openjdk.org (jonghoonpark) Date: Mon, 15 Sep 2025 12:51:40 GMT Subject: RFR: 8366716: Move SmapsParser from runtime/os/TestTracePageSizes.java into testlib [v3] In-Reply-To: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com> References: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com> Message-ID: <1DpnUSHf7W4kL6Xg-AfFX0iWBVSZ5-AVTIBGgWWGk5M=.1cae7869-d51c-4beb-8f5a-65ea5e96c9c5@github.com> > related jira issue: https://bugs.openjdk.org/browse/JDK-8366716 > > --- > > Following the direction outlined in the issue description, > I've extracted the common parts from `TestTracePageSizes` and `TestTransparentHugePagesHeap` to implement the `SmapsParser` test library. > > I've confirmed that it works without issues in my local tests. > > Reviews and feedback are welcome. jonghoonpark has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Refactor: Introduce Smaps class for testing Signed-off-by: jonghoonpark ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27273/files - new: https://git.openjdk.org/jdk/pull/27273/files/538b4405..873804c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27273&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27273&range=01-02 Stats: 465 lines in 4 files changed: 231 ins; 226 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/27273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27273/head:pull/27273 PR: https://git.openjdk.org/jdk/pull/27273 From duke at openjdk.org Mon Sep 15 12:55:14 2025 From: duke at openjdk.org (jonghoonpark) Date: Mon, 15 Sep 2025 12:55:14 GMT Subject: RFR: 8366716: Move SmapsParser from runtime/os/TestTracePageSizes.java into testlib [v3] In-Reply-To: <1DpnUSHf7W4kL6Xg-AfFX0iWBVSZ5-AVTIBGgWWGk5M=.1cae7869-d51c-4beb-8f5a-65ea5e96c9c5@github.com> References: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com> <1DpnUSHf7W4kL6Xg-AfFX0iWBVSZ5-AVTIBGgWWGk5M=.1cae7869-d51c-4beb-8f5a-65ea5e96c9c5@github.com> Message-ID: On Mon, 15 Sep 2025 12:51:40 GMT, jonghoonpark wrote: >> related jira issue: https://bugs.openjdk.org/browse/JDK-8366716 >> >> --- >> >> Following the direction outlined in the issue description, >> I've extracted the common parts from `TestTracePageSizes` and `TestTransparentHugePagesHeap` to implement the `SmapsParser` test library. >> >> I've confirmed that it works without issues in my local tests. >> >> Reviews and feedback are welcome. > > jonghoonpark has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Refactor: Introduce Smaps class for testing > > Signed-off-by: jonghoonpark I have finished refactoring and completed testing locally. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27273#issuecomment-3292024859 From mli at openjdk.org Mon Sep 15 12:57:25 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 15 Sep 2025 12:57:25 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v2] In-Reply-To: References: Message-ID: <7lvSssmxbOyLJSEtLqhofdkEY2SkXx5lMCo6wzdXTo8=.73639d26-d273-42d6-99a1-38d71915a7e9@github.com> > Hi, > Can you help to review this patch? > > Currently, the cpu features of riscv are stored in separate RVFeature subclasses. > But to support the store/restore CPU features for aot in the future, we need to store the cpu features in a continuous memory. > As the riscv extensions are introduced continuously, I think it's better to do it via an simple bitmap at the beginning. > Currently, just suppose the non-extension features will not be stored in aot image, so I also split the extension and non-extenion features. When we implement the related aot feature in the short future, we can revisit the way of splitting the features. Currently, just change the storage way of cpu features, lay the foundation for future aot. > > Thanks Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: - merge master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - initial commit - refine - split extension and non-extension features - remove RVFeatureValue::_enabled - rename own to current - initial commit ------------- Changes: https://git.openjdk.org/jdk/pull/27152/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27152&range=01 Stats: 214 lines in 2 files changed: 144 ins; 4 del; 66 mod Patch: https://git.openjdk.org/jdk/pull/27152.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27152/head:pull/27152 PR: https://git.openjdk.org/jdk/pull/27152 From duke at openjdk.org Mon Sep 15 13:05:20 2025 From: duke at openjdk.org (Ruben) Date: Mon, 15 Sep 2025 13:05:20 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v4] In-Reply-To: <2oxU81yPj1mPZcYyy5dimdl0z3B2tIJsieTpkSXmHQk=.4f62a862-38c6-488b-b7c6-016fec53c788@github.com> References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> <2oxU81yPj1mPZcYyy5dimdl0z3B2tIJsieTpkSXmHQk=.4f62a862-38c6-488b-b7c6-016fec53c788@github.com> Message-ID: On Mon, 15 Sep 2025 10:53:50 GMT, Martin Doerr wrote: > I suggest reverting only the PPC64 files to the previous version. That one works. There should never be a `bl` instruction immediately before the deopt handler on PPC64. Thank you, @TheRealMDoerr, I will revert the change in PPC64 files and will add a comment in the `emit_deopt_handler`. Would it be possible for you to advise what does guarantee there is never a `bl` before the deopt handler? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3292062709 From mli at openjdk.org Mon Sep 15 13:07:36 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 15 Sep 2025 13:07:36 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v3] In-Reply-To: References: Message-ID: <6ZAynMQkqdt6tIryWfsDRCmUSG_JxswlIKfj-YkcvSk=.e4874a70-a97e-43e2-ade8-e023be610a0c@github.com> > Hi, > Can you help to review this patch? > > Currently, the cpu features of riscv are stored in separate RVFeature subclasses. > But to support the store/restore CPU features for aot in the future, we need to store the cpu features in a continuous memory. > As the riscv extensions are introduced continuously, I think it's better to do it via an simple bitmap at the beginning. > Currently, just suppose the non-extension features will not be stored in aot image, so I also split the extension and non-extenion features. When we implement the related aot feature in the short future, we can revisit the way of splitting the features. Currently, just change the storage way of cpu features, lay the foundation for future aot. > > Thanks Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: refine ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27152/files - new: https://git.openjdk.org/jdk/pull/27152/files/08bd5dd8..0ef68423 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27152&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27152&range=01-02 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27152.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27152/head:pull/27152 PR: https://git.openjdk.org/jdk/pull/27152 From mli at openjdk.org Mon Sep 15 13:07:39 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 15 Sep 2025 13:07:39 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v3] In-Reply-To: References: Message-ID: <7l77d9TemowRk6zLqPGDqDr8z-GCjYhk1U-0uW_cTs0=.795ecba4-1ec2-4e2f-a526-3e2aa596daf4@github.com> On Mon, 15 Sep 2025 08:44:16 GMT, Fei Yang wrote: > Hi, I like the idea of separating the two group of flags. I am having a look. BTW: Can you merge and rebase? Thank you for having a look. > src/hotspot/cpu/riscv/vm_version_riscv.hpp line 295: > >> 293: } >> 294: >> 295: static int index(RVFeatureIndex feature) { > > Seems better to rename this to `element_index`? fixed > src/hotspot/cpu/riscv/vm_version_riscv.hpp line 333: > >> 331: } >> 332: >> 333: bool supports_feature(uint32_t feature) { > > Should this be `support_feature` like its friends `set_feature` or `clear_feature` in style? fixed ------------- PR Comment: https://git.openjdk.org/jdk/pull/27152#issuecomment-3292064020 PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2348929010 PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2348928552 From tschatzl at openjdk.org Mon Sep 15 13:19:48 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 15 Sep 2025 13:19:48 GMT Subject: RFR: 8366865: G1: Allocation GC Pauses Triggered after JVM has started shutdown [v2] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 10:38:08 GMT, Ivan Walulya wrote: >> Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. >> >> Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. >> >> Testing: Tier 1-7 > > Ivan Walulya 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 nine additional commits since the last revision: > > - return on timeout > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - timed wait > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - space > - remove debug logs > - remove debug logs > - log_cpu_time > - init I think this is mostly good, just some minor nitpicks. src/hotspot/share/gc/shared/collectedHeap.cpp line 616: > 614: // If the VM is shutting down, we may have skipped VM_CollectForAllocation. > 615: // To avoid returning nullptr (which could cause premature OOME), we stall > 616: // allocation requests here allow the VM shutdown is complete. This sentence is confusing and does not seem to be proper English. I do not completely understand what is meant, (maybe `s/allow/until`?) so no particular suggestions from me. src/hotspot/share/gc/shared/collectedHeap.cpp line 624: > 622: // sequence completes in the common case. > 623: // - short enough to avoid excessive stall time if the shutdown itself > 624: // triggers a GC. I think this should be put into the .hpp file, or at least the comment `// Stall allocation requests until the VM shutdown is complete.` seems a bit misleading if in reality the VM has a timeout. src/hotspot/share/gc/shared/collectedHeap.cpp line 626: > 624: // triggers a GC. > 625: MonitorLocker ml(VMExit_lock); > 626: ml.wait(2 * 1000); Maybe log a warning or such in case this times out - it seems to be only possible at that point if we are continuing for too long, and the VM will OOME soon anyway (the code will return `nullptr`). However I'm fine if we think that is not necessary. Also maybe use the constant `MILLIUNITS` instead of the hardcoded `1000`. src/hotspot/share/runtime/java.cpp line 511: > 509: #endif > 510: > 511: // Run before exit and then stop concurrent GC threads I think this comment should be improved - it looks like a straggler from the many changes in this file. It describes what `Universe::before_exit()` does, but maybe such documentation (what it does) is better put in the documentation for that method. ------------- Changes requested by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27190#pullrequestreview-3224510575 PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2348932834 PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2348941360 PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2348962032 PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2348952363 From tschatzl at openjdk.org Mon Sep 15 13:19:50 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 15 Sep 2025 13:19:50 GMT Subject: RFR: 8366865: G1: Allocation GC Pauses Triggered after JVM has started shutdown [v2] In-Reply-To: References: <04Lru322UkYz11DPPFo3alqoYCd7pSEsPSkpW4Z0_bQ=.d536246e-a5bb-4594-8966-52936927e117@github.com> Message-ID: <3V6E695BA79HaxWhscgYqZAjY6bokbZptRqcJ1DZq4A=.9aecd1f1-b5c1-4336-8b66-fc4829ab2827@github.com> On Wed, 10 Sep 2025 13:55:44 GMT, Ivan Walulya wrote: >> src/hotspot/share/gc/shared/gcVMOperations.cpp line 115: >> >>> 113: >>> 114: // Check invocations >>> 115: if (skip_operation() || Universe::heap()->is_shutting_down()) { >> >> Can the new condition be inlined inside `skip_operation()`? > > In the first iteration I had it inlined, but then decided to make it more explicit. I can change it back if you prefer No particular preference, but the comments in `skip_operation()` need to be adjusted to also indicate that as additional condition. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2348946011 From ayang at openjdk.org Mon Sep 15 13:26:24 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 15 Sep 2025 13:26:24 GMT Subject: RFR: 8346005: Parallel: Incorrect page size calculation with UseLargePages [v5] In-Reply-To: References: Message-ID: > Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`. > > The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation. > > The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`. > > When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary. > > Test: tier1?8 Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' into pgc-largepage - page-size - Merge branch 'master' into pgc-largepage - Merge branch 'master' into pgc-largepage - Merge branch 'master' into pgc-largepage - pgc-largepage ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26700/files - new: https://git.openjdk.org/jdk/pull/26700/files/74d4fa3c..c7254311 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=03-04 Stats: 28369 lines in 982 files changed: 14055 ins; 9009 del; 5305 mod Patch: https://git.openjdk.org/jdk/pull/26700.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26700/head:pull/26700 PR: https://git.openjdk.org/jdk/pull/26700 From coleenp at openjdk.org Mon Sep 15 13:38:27 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 15 Sep 2025 13:38:27 GMT Subject: RFR: 8365823: Revert storing abstract and interface Klasses to non-class metaspace Message-ID: This change removes the optimization to not store abstract and interface Klass metadata to non-class metaspace. Now all Klass metadata is in the Klass metaspace. This is simpler and less bug prone, and didn't help with the limitation of classes that can be stored in class metaspace materially. Tested with tier1-4. ------------- Commit messages: - 8365823: Revert storing abstract and interface Klasses to non-class metaspace - 8365823: Revert storing abstract and interface Klasses to non-class metaspace Changes: https://git.openjdk.org/jdk/pull/27295/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27295&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365823 Stats: 85 lines in 18 files changed: 6 ins; 55 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/27295.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27295/head:pull/27295 PR: https://git.openjdk.org/jdk/pull/27295 From coleenp at openjdk.org Mon Sep 15 13:38:28 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 15 Sep 2025 13:38:28 GMT Subject: RFR: 8365823: Revert storing abstract and interface Klasses to non-class metaspace In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 13:28:45 GMT, Coleen Phillimore wrote: > This change removes the optimization to not store abstract and interface Klass metadata to non-class metaspace. Now all Klass metadata is in the Klass metaspace. This is simpler and less bug prone, and didn't help with the limitation of classes that can be stored in class metaspace materially. > Tested with tier1-4. to review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27295#issuecomment-3292173729 From shade at openjdk.org Mon Sep 15 13:46:34 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 15 Sep 2025 13:46:34 GMT Subject: RFR: 8365823: Revert storing abstract and interface Klasses to non-class metaspace In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 13:28:45 GMT, Coleen Phillimore wrote: > This change removes the optimization to not store abstract and interface Klass metadata to non-class metaspace. Now all Klass metadata is in the Klass metaspace. This is simpler and less bug prone, and didn't help with the limitation of classes that can be stored in class metaspace materially. > Tested with tier1-4. First pass comments below. Also, I looked at original change, and I wonder if we want to revert other changes as well. It looks to me they are fairly innocuous, TBH, so I have no strong opinion about them. Changing `final` -> `abstract` in `InvokerBytecodeGenerator`: https://github.com/openjdk/jdk/commit/ad104932e6c26806c353ad048ce5cff7d2b4c29a?diff=unified#diff-3b05b61400e7766115409b3f508d839fb51e450423822252ab2e18543427c764L249-R249 JFR: https://github.com/openjdk/jdk/commit/ad104932e6c26806c353ad048ce5cff7d2b4c29a?diff=unified#diff-d58d6d9783cb29084a15c42ecd7f59860a48be8bcfd9be0ee15a9d50209b576fR1-R160 And to the test: https://github.com/openjdk/jdk/commit/ad104932e6c26806c353ad048ce5cff7d2b4c29a?diff=unified#diff-00138acd973f46c5f91674e5388ee82d2e7ed1b788ed551f34120cc761d228b7L1-R166 src/hotspot/share/memory/metaspace.cpp line 885: > 883: MetaspaceCriticalAllocation::block_if_concurrent_purge(); > 884: > 885: MetadataType mdtype = type == MetaspaceObj::ClassType ? ClassType: NonClassType; This matches the style of original hunk: Suggestion: MetadataType mdtype = (type == MetaspaceObj::ClassType) ? ClassType : NonClassType; (see https://github.com/openjdk/jdk/commit/ad104932e6c26806c353ad048ce5cff7d2b4c29a?diff=unified#diff-d22e3e58e52d574f4277c0f89304d775b68833148a57c5af6760395b002b2b86L843-R843) src/hotspot/share/memory/metaspace.cpp line 920: > 918: > 919: if (result == nullptr) { > 920: MetadataType mdtype = type == MetaspaceObj::ClassType ? ClassType: NonClassType; Suggestion: MetadataType mdtype = (type == MetaspaceObj::ClassType) ? ClassType : NonClassType; src/hotspot/share/oops/klass.cpp line 281: > 279: #ifdef _LP64 > 280: if (UseCompactObjectHeaders) { > 281: precond(CompressedKlassPointers::is_encodable(kls)); Sounds like we want to leave this comment in: // With compact object headers, the narrow Klass ID is part of the mark word. // We therefore seed the mark word with the narrow Klass ID. ------------- PR Review: https://git.openjdk.org/jdk/pull/27295#pullrequestreview-3224650389 PR Review Comment: https://git.openjdk.org/jdk/pull/27295#discussion_r2349034149 PR Review Comment: https://git.openjdk.org/jdk/pull/27295#discussion_r2349035742 PR Review Comment: https://git.openjdk.org/jdk/pull/27295#discussion_r2349020024 From asmehra at openjdk.org Mon Sep 15 13:53:35 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Mon, 15 Sep 2025 13:53:35 GMT Subject: RFR: 8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive [v2] In-Reply-To: References: Message-ID: <1VSCpgFsR3ihRW-AYyVTTDLrMV7azj94fOyZnmWRgMQ=.8b98c2e5-ae90-4e74-a78e-15ed645b8d36@github.com> On Mon, 15 Sep 2025 04:13:32 GMT, Ioi Lam wrote: >> Support of `-XX:+AOTClassLinking` for dynamic CDS archive is not an documented feature of [JEP 483](https://openjdk.org/jeps/483). It has very small performance benefit and complicates the development of future AOT optimizations. >> >> After this PR, `-XX:+AOTClassLinking` will have no effect when creating a dynamic CDS archive. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @ashu-mehra comment -- print warning if -XX:+AOTClassLinking is enabled for dynamic dump lgtm ------------- Marked as reviewed by asmehra (Committer). PR Review: https://git.openjdk.org/jdk/pull/27242#pullrequestreview-3224743037 From liach at openjdk.org Mon Sep 15 14:17:51 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Sep 2025 14:17:51 GMT Subject: RFR: 8365823: Revert storing abstract and interface Klasses to non-class metaspace In-Reply-To: References: Message-ID: <-fecZtztO6hiM81X7rvfgiuqYRSx3JI6wdj_XvK7G4Q=.08a72d12-8b54-46a4-a2ae-b5af9febe652@github.com> On Mon, 15 Sep 2025 13:28:45 GMT, Coleen Phillimore wrote: > This change removes the optimization to not store abstract and interface Klass metadata to non-class metaspace. Now all Klass metadata is in the Klass metaspace. This is simpler and less bug prone, and didn't help with the limitation of classes that can be stored in class metaspace materially. > Tested with tier1-4. Re InvokerBytecodeGenerator: it was rolled back almost immediately after the original patch due to performance regressions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27295#issuecomment-3292388736 From coleenp at openjdk.org Mon Sep 15 14:25:29 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 15 Sep 2025 14:25:29 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 08:35:05 GMT, Paul H?bner wrote: > Hi all, > > `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: > 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases), > 2) removes `FilteredJavaFieldStream` entirely, and > 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. > > Testing: Oracle tiers 1-3. This looks great. You said vmtarget but you meant vmholder, which is the right name for this internal field since it points to the mirror (instance of java.lang.Class). ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27209#pullrequestreview-3224893210 From phubner at openjdk.org Mon Sep 15 14:25:30 2025 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Mon, 15 Sep 2025 14:25:30 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary In-Reply-To: References: Message-ID: <3NcFIVzB54ClBeKBOMpzHFt9gHz-VY5tZGflXHpAXVQ=.f69ec18a-1732-404d-9f0a-c34af33698f1@github.com> On Mon, 15 Sep 2025 14:19:39 GMT, Coleen Phillimore wrote: > This looks great. You said vmtarget but you meant vmholder, which is the right name for this internal field since it points to the mirror (instance of java.lang.Class). Apologies, I've updated the PR description accordingly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3292440414 From coleenp at openjdk.org Mon Sep 15 14:34:45 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 15 Sep 2025 14:34:45 GMT Subject: RFR: 8365823: Revert storing abstract and interface Klasses to non-class metaspace [v2] In-Reply-To: References: Message-ID: > This change removes the optimization to not store abstract and interface Klass metadata to non-class metaspace. Now all Klass metadata is in the Klass metaspace. This is simpler and less bug prone, and didn't help with the limitation of classes that can be stored in class metaspace materially. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with three additional commits since the last revision: - Update src/hotspot/share/memory/metaspace.cpp Co-authored-by: Aleksey Shipil?v - Update src/hotspot/share/memory/metaspace.cpp Co-authored-by: Aleksey Shipil?v - Restore comment. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27295/files - new: https://git.openjdk.org/jdk/pull/27295/files/864e938d..097c6b33 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27295&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27295&range=00-01 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27295.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27295/head:pull/27295 PR: https://git.openjdk.org/jdk/pull/27295 From coleenp at openjdk.org Mon Sep 15 14:34:47 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 15 Sep 2025 14:34:47 GMT Subject: RFR: 8365823: Revert storing abstract and interface Klasses to non-class metaspace [v2] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 13:33:47 GMT, Aleksey Shipilev wrote: >> Coleen Phillimore has updated the pull request incrementally with three additional commits since the last revision: >> >> - Update src/hotspot/share/memory/metaspace.cpp >> >> Co-authored-by: Aleksey Shipil?v >> - Update src/hotspot/share/memory/metaspace.cpp >> >> Co-authored-by: Aleksey Shipil?v >> - Restore comment. > > src/hotspot/share/oops/klass.cpp line 281: > >> 279: #ifdef _LP64 >> 280: if (UseCompactObjectHeaders) { >> 281: precond(CompressedKlassPointers::is_encodable(kls)); > > Sounds like we want to leave this comment in: > > > // With compact object headers, the narrow Klass ID is part of the mark word. > // We therefore seed the mark word with the narrow Klass ID. Little too aggressive with the delete button. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27295#discussion_r2349206231 From coleenp at openjdk.org Mon Sep 15 14:38:04 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 15 Sep 2025 14:38:04 GMT Subject: RFR: 8365823: Revert storing abstract and interface Klasses to non-class metaspace In-Reply-To: References: Message-ID: <4zUQMNnJKfrNy91JGdPH8u6Ev2pQOlgKMb-NBE4Qrok=.95b41cbd-1a75-45b7-a539-b804458afcee@github.com> On Mon, 15 Sep 2025 13:28:45 GMT, Coleen Phillimore wrote: > This change removes the optimization to not store abstract and interface Klass metadata to non-class metaspace. Now all Klass metadata is in the Klass metaspace. This is simpler and less bug prone, and didn't help with the limitation of classes that can be stored in class metaspace materially. > Tested with tier1-4. The JFR changes were a slight refactoring, so I don't think they need to be changed back. The ClassFileParser.is_abstract() function is now unused. Well spoltted. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27295#issuecomment-3292499021 From coleenp at openjdk.org Mon Sep 15 14:38:03 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 15 Sep 2025 14:38:03 GMT Subject: RFR: 8365823: Revert storing abstract and interface Klasses to non-class metaspace [v3] In-Reply-To: References: Message-ID: > This change removes the optimization to not store abstract and interface Klass metadata to non-class metaspace. Now all Klass metadata is in the Klass metaspace. This is simpler and less bug prone, and didn't help with the limitation of classes that can be stored in class metaspace materially. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Remove CFP.is_abstract(). ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27295/files - new: https://git.openjdk.org/jdk/pull/27295/files/097c6b33..fe44431f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27295&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27295&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27295.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27295/head:pull/27295 PR: https://git.openjdk.org/jdk/pull/27295 From mdoerr at openjdk.org Mon Sep 15 15:05:30 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 15 Sep 2025 15:05:30 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v4] In-Reply-To: <2oxU81yPj1mPZcYyy5dimdl0z3B2tIJsieTpkSXmHQk=.4f62a862-38c6-488b-b7c6-016fec53c788@github.com> References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> <2oxU81yPj1mPZcYyy5dimdl0z3B2tIJsieTpkSXmHQk=.4f62a862-38c6-488b-b7c6-016fec53c788@github.com> Message-ID: On Mon, 15 Sep 2025 10:53:50 GMT, Martin Doerr wrote: >> Ruben has updated the pull request incrementally with two additional commits since the last revision: >> >> - Offset the deoptimization handler entry point >> >> Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722 >> - Revert "Ensure stub code is not adjacent to a call" > > I suggest reverting only the PPC64 files to the previous version. That one works. There should never be a `bl` instruction immediately before the deopt handler on PPC64. > Thank you, @TheRealMDoerr, I will revert the change in PPC64 files and will add a comment in the `emit_deopt_handler`. Would it be possible for you to advise what does guarantee there is never a `bl` before the deopt handler? Thanks! The main code ends with `blr` or `b` instructions. There may be trampoline stubs which end with `bctr` instructions. None of them set the `LR` (link register). I wonder why arm uses instructions which set it and the end. Does that make any sense? Note that we sometimes emit a 2nd deopt handler: https://github.com/openjdk/jdk/blob/a7dc011ac4fec73d686661b1bb6969c7135982f2/src/hotspot/share/opto/output.cpp#L1814 After having executed the first one, LR may point to the beginning of the 2nd one. I don't think this causes problems on PPC64, but should better be double-checked. At least, this code pattern is not new. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3292652424 From liach at openjdk.org Mon Sep 15 15:08:59 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Sep 2025 15:08:59 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary In-Reply-To: References: Message-ID: <6nVRAWluMUpKh1sSgz0KhCY83eZ5eLTrnA0lSyWlYUo=.43ff7884-ed9e-4aa8-b0ad-1f6ab740dd43@github.com> On Thu, 11 Sep 2025 08:35:05 GMT, Paul H?bner wrote: > Hi all, > > `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: > 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases), > 2) removes `FilteredJavaFieldStream` entirely, and > 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. > > Testing: Oracle tiers 1-3. Is `constantPoolOop` in `test/lib/jdk/test/lib/hprof/HprofParser.java` related to this removed field? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3292670063 From shade at openjdk.org Mon Sep 15 15:09:38 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 15 Sep 2025 15:09:38 GMT Subject: RFR: 8365823: Revert storing abstract and interface Klasses to non-class metaspace [v3] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 14:38:03 GMT, Coleen Phillimore wrote: >> This change removes the optimization to not store abstract and interface Klass metadata to non-class metaspace. Now all Klass metadata is in the Klass metaspace. This is simpler and less bug prone, and didn't help with the limitation of classes that can be stored in class metaspace materially. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove CFP.is_abstract(). This looks good to me, I have a few more questions: src/hotspot/share/ci/ciKlass.hpp line 112: > 110: assert(is_in_encoding_range, "sanity"); > 111: return is_in_encoding_range; > 112: } I thought about this method, and it _looks_ to be just: bool is_in_encoding_range() { assert(CompressedKlassPointers::is_encodable(get_Klass()), "sanity"); return true; } But I think your version is better, since it is more paranoid and actually checks if we are dealing with the class within the class range. src/hotspot/share/memory/allocation.cpp line 76: > 74: // Klass has its own operator new > 75: assert(type != ClassType, "class has its own operator new"); > 76: return Metaspace::allocate(loader_data, word_size, type, /*use_class_space*/ false, THREAD); Question: now that `ArrayKlass` and `InstanceKlass` do not have `::new`, the assert above is still valid? I am guessing all these inherit `Klass::new`? ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27295#pullrequestreview-3225077178 PR Review Comment: https://git.openjdk.org/jdk/pull/27295#discussion_r2349317958 PR Review Comment: https://git.openjdk.org/jdk/pull/27295#discussion_r2349286698 From phubner at openjdk.org Mon Sep 15 15:25:54 2025 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Mon, 15 Sep 2025 15:25:54 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary In-Reply-To: <6nVRAWluMUpKh1sSgz0KhCY83eZ5eLTrnA0lSyWlYUo=.43ff7884-ed9e-4aa8-b0ad-1f6ab740dd43@github.com> References: <6nVRAWluMUpKh1sSgz0KhCY83eZ5eLTrnA0lSyWlYUo=.43ff7884-ed9e-4aa8-b0ad-1f6ab740dd43@github.com> Message-ID: On Mon, 15 Sep 2025 15:05:25 GMT, Chen Liang wrote: > Is `constantPoolOop` in `test/lib/jdk/test/lib/hprof/HprofParser.java` related to this removed field? I'm not sure, I came across this file as well and could not determine if it was an old artefact or not. I had a look at the log message and cross-referenced with HotSpot, and I also went digging in the commit messages, but I could not find anything fruitful. Considering it uses a wildcard and does not reference `sun.reflect.ConstantPool` or `jdk.internal.reflect.ConstantPool` leads me to believe this might be something else, most likely dead code. Many tiers of tests pass. I'm happy to open an issue if you think it's worth looking into. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3292742093 From adinn at openjdk.org Mon Sep 15 15:43:12 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 15 Sep 2025 15:43:12 GMT Subject: RFR: 8367532: Declare all stubgen stub entries including internal cross-stub entries Message-ID: This PR adds declarations for internal entries used to daisy chain memory copy stubs and ensures they are saved to generated fields when produced and accessed via those fields when consumed. This will ensure they are saved and restored correctly when stubgen blobs are included in the AOT Code Cache. The PR also fixes a few AArch64 stubs which do not currently have their first entry at offset 0, another thing that will be needed to simplify AOT Code cache save and restore. ------------- Commit messages: - mark internal cross-stub entry as a runtime target on AArch64 - correct aarch64 and riscv arraycopy stub cross-targets - correct typos in x86 code - ensure all cross stub calls use declared entries - first stub entry must be at offset 0 Changes: https://git.openjdk.org/jdk/pull/27228/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27228&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367532 Stats: 533 lines in 8 files changed: 273 ins; 54 del; 206 mod Patch: https://git.openjdk.org/jdk/pull/27228.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27228/head:pull/27228 PR: https://git.openjdk.org/jdk/pull/27228 From coleenp at openjdk.org Mon Sep 15 15:45:25 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 15 Sep 2025 15:45:25 GMT Subject: RFR: 8367142: Avoid InstanceKlass::cast when converting java mirror to InstanceKlass [v3] In-Reply-To: <3Xh3sS0I7pp0fslgQndt4CLqddxga7W8c11tuZkNgd8=.b5a28dba-05f1-49d9-80f8-6260a9772287@github.com> References: <3Xh3sS0I7pp0fslgQndt4CLqddxga7W8c11tuZkNgd8=.b5a28dba-05f1-49d9-80f8-6260a9772287@github.com> Message-ID: On Wed, 10 Sep 2025 22:46:00 GMT, Ioi Lam wrote: >> The purpose of this PR is to simplify JNI code and also to avoid unnecessary `InstanceKlass::cast()` calls by adding a new function: >> >> >> static InstanceKlass* java_lang_Class::as_InstanceKlass(oop java_class); >> >> >> This PR is intended to be a strict clean-up that preserves existing behaviors. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Removed the (jobject) version of as_Klass/as_InstanceKlass This looks great. Thanks! ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27158#pullrequestreview-3225277530 From coleenp at openjdk.org Mon Sep 15 15:59:39 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 15 Sep 2025 15:59:39 GMT Subject: RFR: 8365823: Revert storing abstract and interface Klasses to non-class metaspace [v3] In-Reply-To: References: Message-ID: <7v3qSjT6T3crtTXTRCwHuire5p-HFHDp6LyO3YfuHvs=.5969244a-ec88-4e9f-af2f-8263711dc010@github.com> On Mon, 15 Sep 2025 15:06:04 GMT, Aleksey Shipilev wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove CFP.is_abstract(). > > src/hotspot/share/ci/ciKlass.hpp line 112: > >> 110: assert(is_in_encoding_range, "sanity"); >> 111: return is_in_encoding_range; >> 112: } > > I thought about this method, and it _looks_ to be just: > > > bool is_in_encoding_range() { > assert(CompressedKlassPointers::is_encodable(get_Klass()), "sanity"); > return true; > } > > > But I think your version is better, since it is more paranoid and actually checks if we are dealing with the class within the class range. I was on the verge of removing this but that snowballed into removing all sorts of other things that maybe can be removed later. This was sort of where I cut it off and I did like the variable name. > src/hotspot/share/memory/allocation.cpp line 76: > >> 74: // Klass has its own operator new >> 75: assert(type != ClassType, "class has its own operator new"); >> 76: return Metaspace::allocate(loader_data, word_size, type, /*use_class_space*/ false, THREAD); > > Question: now that `ArrayKlass` and `InstanceKlass` do not have `::new`, the assert above is still valid? I am guessing all these inherit `Klass::new`? Yes, all Klass allocation should call Klass::operator new(). Klass is derived from Metadata that's derived from MetaspaceObj. The Klass operator new _hides_ the one in MetaspaceObj. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27295#discussion_r2349433048 PR Review Comment: https://git.openjdk.org/jdk/pull/27295#discussion_r2349449119 From liach at openjdk.org Mon Sep 15 16:06:30 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Sep 2025 16:06:30 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 08:35:05 GMT, Paul H?bner wrote: > Hi all, > > `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: > 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases), > 2) removes `FilteredJavaFieldStream` entirely, and > 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. > > Testing: Oracle tiers 1-3. The removal of this field looks good. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27209#pullrequestreview-3225353180 From adinn at openjdk.org Mon Sep 15 16:06:31 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 15 Sep 2025 16:06:31 GMT Subject: RFR: 8367532: Declare all stubgen stub entries including internal cross-stub entries In-Reply-To: References: Message-ID: <6N06v2kLnE8xiOzV_Wz09ULHb0EWjQ32Bf8QOuLN8kY=.d86e8952-b240-47b6-b322-6377e88c8d6c@github.com> On Thu, 11 Sep 2025 15:13:07 GMT, Andrew Dinn wrote: > This PR adds declarations for internal entries used to daisy chain memory copy stubs and ensures they are saved to generated fields when produced and accessed via those fields when consumed. This will ensure they are saved and restored correctly when stubgen blobs are included in the AOT Code Cache. > > The PR also fixes a few AArch64 stubs which do not currently have their first entry at offset 0, another thing that will be needed to simplify AOT Code cache save and restore. @RealFYang Could you check that this patch does works ok on riscv? It should be enough to 1) make images and 2) make test with TEST=test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java and TEST=test/hotspot/jtreg/compiler/unsafe/UnsafeArrayCopy.java ------------- PR Comment: https://git.openjdk.org/jdk/pull/27228#issuecomment-3292904523 From coleenp at openjdk.org Mon Sep 15 16:06:31 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 15 Sep 2025 16:06:31 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 08:35:05 GMT, Paul H?bner wrote: > Hi all, > > `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: > 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases), > 2) removes `FilteredJavaFieldStream` entirely, and > 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. > > Testing: Oracle tiers 1-3. ConstantPool in the JVM metadata used to be called constantPoolOop, so I think that's what it's looking to not find. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3292895168 From sparasa at openjdk.org Mon Sep 15 16:28:26 2025 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Mon, 15 Sep 2025 16:28:26 GMT Subject: RFR: 8367694: Fix jtreg test failure when Intel APX is enabled for KNL platforms Message-ID: This goal of this PR is fix the jtreg test failure observed in compiler test: `test/hotspot/jtreg/compiler/loopopts/superword/TestDependencyOffsets.java` The test failure is occurring specifically for the tests with ids = {avx512-v064-A, avx512-v064-U, avx512-v032-A, avx512-v032-U}. These tests are run with KNL hardware features enabled (`-XX:+UseKNLSetting`). The two main causes of test failure are: 1. KNL does not support Intel APX. Currently, APX is not turned off when using KNL. This PR fixes this issue. 2. BMI2 instructions like sarxl are encoded incorrectly with `uses_vl=true` (use vector length). This PR fixes the encoding to use the correct one:`uses_vl=false`. After fixing these two bugs, `TestDependencyOffsets.java` is passing using the SDE emulator when APX is enabled. ------------- Commit messages: - Update assembler_x86.cpp - 8367694: Fix jtreg test failure when Intel APX is enabled for KNL platforms Changes: https://git.openjdk.org/jdk/pull/27299/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27299&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367694 Stats: 14 lines in 2 files changed: 1 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/27299.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27299/head:pull/27299 PR: https://git.openjdk.org/jdk/pull/27299 From iwalulya at openjdk.org Mon Sep 15 17:12:35 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 15 Sep 2025 17:12:35 GMT Subject: RFR: 8366865: G1: Allocation GC Pauses Triggered after JVM has started shutdown [v3] In-Reply-To: References: Message-ID: > Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. > > Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. > > Testing: Tier 1-7 Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: Thomas Review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27190/files - new: https://git.openjdk.org/jdk/pull/27190/files/187a463b..0e45912b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=01-02 Stats: 13 lines in 4 files changed: 5 ins; 5 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27190.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27190/head:pull/27190 PR: https://git.openjdk.org/jdk/pull/27190 From jsjolen at openjdk.org Mon Sep 15 17:44:39 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 15 Sep 2025 17:44:39 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 08:35:05 GMT, Paul H?bner wrote: > Hi all, > > `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: > 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases), > 2) removes `FilteredJavaFieldStream` entirely, and > 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. > > Testing: Oracle tiers 1-3. Looks good to me! ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27209#pullrequestreview-3225668786 From jsjolen at openjdk.org Mon Sep 15 18:07:57 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 15 Sep 2025 18:07:57 GMT Subject: RFR: 8367249: [REDO] MemBaseline accesses VMT without using lock [v2] In-Reply-To: References: Message-ID: > Hi, > > This is a REDO, as the previous attempt caused build failures when merged with latest master. > The only difference is that the copy ctr for the RBTRee had been integrated with a different PR, but it never should have been. I deleted the copy ctr. > > Thanks. Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: - Merge remote-tracking branch 'openjdk/master' into cleanup-membaseline - Delete unneeded copy ctr - Merge remote-tracking branch 'openjdk/master' into cleanup-membaseline - Missed const-ness - Move into rbTree.inline.hpp file - Merge remote-tracking branch 'openjdk/master' into cleanup-membaseline - Rename to _vma_allocations - After a lot of casting - Yup - Some more ugly casts - ... and 11 more: https://git.openjdk.org/jdk/compare/60930a3e...c6c65a80 ------------- Changes: https://git.openjdk.org/jdk/pull/27170/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27170&range=01 Stats: 235 lines in 12 files changed: 162 ins; 50 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/27170.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27170/head:pull/27170 PR: https://git.openjdk.org/jdk/pull/27170 From sviswanathan at openjdk.org Mon Sep 15 18:29:09 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Mon, 15 Sep 2025 18:29:09 GMT Subject: RFR: 8367694: Fix jtreg test failure when Intel APX is enabled for KNL platforms In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 16:19:29 GMT, Srinivas Vamsi Parasa wrote: > This goal of this PR is fix the jtreg test failure observed in compiler test: `test/hotspot/jtreg/compiler/loopopts/superword/TestDependencyOffsets.java` > > The test failure is occurring specifically for the tests with ids = {avx512-v064-A, avx512-v064-U, avx512-v032-A, avx512-v032-U}. These tests are run with KNL hardware features enabled (`-XX:+UseKNLSetting`). > > The two main causes of test failure are: > 1. KNL does not support Intel APX. Currently, APX is not turned off when using KNL. This PR fixes this issue. > 2. BMI2 instructions like sarxl are encoded incorrectly with `uses_vl=true` (use vector length). This PR fixes the encoding to use the correct one:`uses_vl=false`. > > After fixing these two bugs, `TestDependencyOffsets.java` is passing using the SDE emulator when APX is enabled. src/hotspot/cpu/x86/vm_version_x86.cpp line 1020: > 1018: > 1019: // Currently APX support is only enabled for targets supporting AVX512VL feature. > 1020: bool apx_supported = !is_knights_family() && os_supports_apx_egprs() && supports_apx_f() && supports_avx512vl(); Instead of adding is_knights_family check here, it is better to move the lines 1020-1028 after 1070. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27299#discussion_r2349787918 From kbarrett at openjdk.org Mon Sep 15 19:12:37 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 15 Sep 2025 19:12:37 GMT Subject: RFR: 8358957: [ubsan]: The assert in layout_helper_boolean_diffbit() in klass.hpp needs UB to fail In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 09:01:56 GMT, Afshin Zafari wrote: > Avoid using loop and UB in left-shift operation as suggested by Kim's comment in the JBS-issue. > > Tests: > mach5 tiers 1-5 {macosx-aarch64, linux-x64, windows-x64} x {debug, product} src/hotspot/share/oops/klass.hpp line 518: > 516: static int layout_helper_boolean_diffbit() { > 517: uint zlh = checked_cast(array_layout_helper(T_BOOLEAN)); > 518: uint blh = checked_cast(array_layout_helper(T_BYTE)); Use of check_cast is probably wrong. I think an alh is negative. Oops, my mistake. It probably doesn't fail currently because of [JDK-8314258](https://bugs.openjdk.org/browse/JDK-8314258). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27288#discussion_r2349874742 From amenkov at openjdk.org Mon Sep 15 19:15:26 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 15 Sep 2025 19:15:26 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 08:35:05 GMT, Paul H?bner wrote: > Hi all, > > `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: > 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases), > 2) removes `FilteredJavaFieldStream` entirely, and > 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. > > Testing: Oracle tiers 1-3. Looks good I was sure HeapDumper also uses FilteredJavaFieldStream to exclude constantPoolOop field, but it doesn't (I don't remember when it changed and why we didn't have issue with it) ------------- Marked as reviewed by amenkov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27209#pullrequestreview-3225947841 From sparasa at openjdk.org Mon Sep 15 20:08:10 2025 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Mon, 15 Sep 2025 20:08:10 GMT Subject: RFR: 8367694: Fix jtreg test failure when Intel APX is enabled for KNL platforms [v2] In-Reply-To: References: Message-ID: > This goal of this PR is fix the jtreg test failure observed in compiler test: `test/hotspot/jtreg/compiler/loopopts/superword/TestDependencyOffsets.java` > > The test failure is occurring specifically for the tests with ids = {avx512-v064-A, avx512-v064-U, avx512-v032-A, avx512-v032-U}. These tests are run with KNL hardware features enabled (`-XX:+UseKNLSetting`). > > The two main causes of test failure are: > 1. KNL does not support Intel APX. Currently, APX is not turned off when using KNL. This PR fixes this issue. > 2. BMI2 instructions like sarxl are encoded incorrectly with `uses_vl=true` (use vector length). This PR fixes the encoding to use the correct one:`uses_vl=false`. > > After fixing these two bugs, `TestDependencyOffsets.java` is passing using the SDE emulator when APX is enabled. Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: change the location of APX feature check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27299/files - new: https://git.openjdk.org/jdk/pull/27299/files/c795d9b0..a1ef0159 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27299&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27299&range=00-01 Stats: 21 lines in 1 file changed: 11 ins; 10 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27299.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27299/head:pull/27299 PR: https://git.openjdk.org/jdk/pull/27299 From sparasa at openjdk.org Mon Sep 15 20:10:25 2025 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Mon, 15 Sep 2025 20:10:25 GMT Subject: RFR: 8367694: Fix jtreg test failure when Intel APX is enabled for KNL platforms [v2] In-Reply-To: References: Message-ID: <0eeMoY0Y26jCeXBp1ivS-q1OJtSzf-TUblhF1h2p3YM=.b51b735b-ceee-4f47-b9f7-63dd379e0ff1@github.com> On Mon, 15 Sep 2025 18:26:37 GMT, Sandhya Viswanathan wrote: >> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: >> >> change the location of APX feature check > > src/hotspot/cpu/x86/vm_version_x86.cpp line 1020: > >> 1018: >> 1019: // Currently APX support is only enabled for targets supporting AVX512VL feature. >> 1020: bool apx_supported = !is_knights_family() && os_supports_apx_egprs() && supports_apx_f() && supports_avx512vl(); > > Instead of adding is_knights_family check here, it is better to move the lines 1020-1028 after 1070. Moved the APX feature check from 1020-1028 to 1070. Please see the updated code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27299#discussion_r2349985891 From sviswanathan at openjdk.org Mon Sep 15 20:24:33 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Mon, 15 Sep 2025 20:24:33 GMT Subject: RFR: 8367694: Fix jtreg test failure when Intel APX is enabled for KNL platforms [v2] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 20:08:10 GMT, Srinivas Vamsi Parasa wrote: >> This goal of this PR is fix the jtreg test failure observed in compiler test: `test/hotspot/jtreg/compiler/loopopts/superword/TestDependencyOffsets.java` >> >> The test failure is occurring specifically for the tests with ids = {avx512-v064-A, avx512-v064-U, avx512-v032-A, avx512-v032-U}. These tests are run with KNL hardware features enabled (`-XX:+UseKNLSetting`). >> >> The two main causes of test failure are: >> 1. KNL does not support Intel APX. Currently, APX is not turned off when using KNL. This PR fixes this issue. >> 2. BMI2 instructions like sarxl are encoded incorrectly with `uses_vl=true` (use vector length). This PR fixes the encoding to use the correct one:`uses_vl=false`. >> >> After fixing these two bugs, `TestDependencyOffsets.java` is passing using the SDE emulator when APX is enabled. > > Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: > > change the location of APX feature check Looks good to me. ------------- Marked as reviewed by sviswanathan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27299#pullrequestreview-3226157178 From iklam at openjdk.org Mon Sep 15 23:20:47 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 15 Sep 2025 23:20:47 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v2] In-Reply-To: References: Message-ID: > This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. > > This PR annotates a single class, `jdk.internal.math.MathUtils`. More classes will be added in future PRs. > > If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to > - All of `K`'s super classes > - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` > > Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). > > This annotation is awfully similar to `@AOTSafeAnnotation`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Exclude more GC heap size tests as AOT cache size has increased for "make test JTREG=AOT_JDK=onestep ..." ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27024/files - new: https://git.openjdk.org/jdk/pull/27024/files/5b71ce80..b1ef47dc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27024&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27024&range=00-01 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27024.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27024/head:pull/27024 PR: https://git.openjdk.org/jdk/pull/27024 From kbarrett at openjdk.org Mon Sep 15 23:50:11 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 15 Sep 2025 23:50:11 GMT Subject: RFR: 8252582: HotSpot Style Guide should permit variable templates In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 01:13:25 GMT, Kim Barrett wrote: > Please review this change to the HotSpot Style Guide to permit the use of > variable templates. This is a C++14 feature that, while fairly simple, didn't > get into the initial permitted for HotSpot list because I just didn't get to > it and nobody asked for it. And it has languished on the "undecided" list for > the same reasons. But recently I've had reason to want to use this feature a > couple of times, so I'm now proposing we allow it. > > I merged it into the section for Inline Variables (a C++17 feature), as the > two are closely related. Variable templates were even listed as one of the > workarounds being used to make up for the lack of inline variables. Anyone else have an opinion? @vnkozlov ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27240#issuecomment-3294357127 From kvn at openjdk.org Tue Sep 16 00:08:18 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 16 Sep 2025 00:08:18 GMT Subject: RFR: 8252582: HotSpot Style Guide should permit variable templates In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 01:13:25 GMT, Kim Barrett wrote: > Please review this change to the HotSpot Style Guide to permit the use of > variable templates. This is a C++14 feature that, while fairly simple, didn't > get into the initial permitted for HotSpot list because I just didn't get to > it and nobody asked for it. And it has languished on the "undecided" list for > the same reasons. But recently I've had reason to want to use this feature a > couple of times, so I'm now proposing we allow it. > > I merged it into the section for Inline Variables (a C++17 feature), as the > two are closely related. Variable templates were even listed as one of the > workarounds being used to make up for the lack of inline variables. Approved. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27240#pullrequestreview-3226653895 From kvn at openjdk.org Tue Sep 16 00:34:10 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 16 Sep 2025 00:34:10 GMT Subject: RFR: 8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive [v2] In-Reply-To: References: Message-ID: <9tei5T4Ox7c_zVMGBsROyJTxsdRjKAXDQTOPo3d62sM=.b2331cfb-b759-4552-9a79-6cd0c71097cb@github.com> On Mon, 15 Sep 2025 04:13:32 GMT, Ioi Lam wrote: >> Support of `-XX:+AOTClassLinking` for dynamic CDS archive is not an documented feature of [JEP 483](https://openjdk.org/jeps/483). It has very small performance benefit and complicates the development of future AOT optimizations. >> >> After this PR, `-XX:+AOTClassLinking` will have no effect when creating a dynamic CDS archive. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @ashu-mehra comment -- print warning if -XX:+AOTClassLinking is enabled for dynamic dump src/hotspot/share/cds/cdsConfig.cpp line 762: > 760: log_warning(cds)("AOTClassLinking is not supported for dynamic CDS archive"); > 761: FLAG_SET_ERGO(AOTClassLinking, false); > 762: } Can you do it in `CDSConfig::check_vm_args_consistency()` instead, where `AOTClassLinking` is set ergonomically? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27242#discussion_r2350387479 From iklam at openjdk.org Tue Sep 16 01:06:12 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Sep 2025 01:06:12 GMT Subject: RFR: 8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive [v2] In-Reply-To: <9tei5T4Ox7c_zVMGBsROyJTxsdRjKAXDQTOPo3d62sM=.b2331cfb-b759-4552-9a79-6cd0c71097cb@github.com> References: <9tei5T4Ox7c_zVMGBsROyJTxsdRjKAXDQTOPo3d62sM=.b2331cfb-b759-4552-9a79-6cd0c71097cb@github.com> Message-ID: On Tue, 16 Sep 2025 00:31:31 GMT, Vladimir Kozlov wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @ashu-mehra comment -- print warning if -XX:+AOTClassLinking is enabled for dynamic dump > > src/hotspot/share/cds/cdsConfig.cpp line 762: > >> 760: log_warning(cds)("AOTClassLinking is not supported for dynamic CDS archive"); >> 761: FLAG_SET_ERGO(AOTClassLinking, false); >> 762: } > > Can you do it in `CDSConfig::check_vm_args_consistency()` instead, where `AOTClassLinking` is set ergonomically? At that point, `is_dumping_dynamic_archive()` will always return zero, as we don't know if we can dump the dynamic archive until `CDSConfig::ergo_init_classic_archive_paths()`, which is called much later. The calling sequence is: - `CDSConfig::check_vm_args_consistency()` - `CDSConfig::ergo_initialize ()`-> `ergo_init_classic_archive_paths()` - `CDSConfig::prepare_for_dumping()` Today we are doing ergo setting of AOT flags inside `check_vm_args_consistency()`. I think we should move that to the end of `CDSConfig::ergo_initialize()`. Since that's a bigger scope, maybe I should do that in a follow-up PR? The current PR still works as intended, because `AOTClassLinking` acts as a master switch that will turn off all other AOT optimizations for dynamic dump, regardless of the values of `AOTInvokeDynamicLinking`, etc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27242#discussion_r2350419118 From iklam at openjdk.org Tue Sep 16 01:08:35 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Sep 2025 01:08:35 GMT Subject: RFR: 8367142: Avoid InstanceKlass::cast when converting java mirror to InstanceKlass [v3] In-Reply-To: References: <30w65N-VMzjkn9Tpy6cXrKz2F-gyoGSyCMpzLc2H8HI=.82760ff5-84b2-4adb-897e-ee8f94be6dad@github.com> Message-ID: On Wed, 10 Sep 2025 07:28:42 GMT, David Holmes wrote: >>> > So I am not sure if we really have that separation anymore. >>> >>> I think it is more that there are many bits of code that actually form the "boundary" (prims, services, some runtime, jvmci, interpreter-related). But I guess it is hard to argue this makes it markedly worse. >> >> Arguably the translation of Java mirrors to Klasses is also a boundary (from Java representation to VM representation) :-) >> >> In reality I think because jobjects are easy to use and are just another kind of handle (like Handle and OopHandle), the leakage from JNI code to other parts of VM just happened naturally. >> >>> > The code already assumes that it has an InstanceKlass, and I am not changing that. >>> >>> Okay. >> >> BTW I removed the JVMTI changes from this PR. > >> Arguably the translation of Java mirrors to Klasses is also a boundary (from Java representation to VM representation) :-) > > The mirror is an oop, both oop and klass are internal VM representations. Thanks @dholmes-ora @coleenp for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/27158#issuecomment-3294479460 From iklam at openjdk.org Tue Sep 16 01:08:36 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Sep 2025 01:08:36 GMT Subject: Integrated: 8367142: Avoid InstanceKlass::cast when converting java mirror to InstanceKlass In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 05:21:10 GMT, Ioi Lam wrote: > The purpose of this PR is to simplify JNI code and also to avoid unnecessary `InstanceKlass::cast()` calls by adding a new function: > > > static InstanceKlass* java_lang_Class::as_InstanceKlass(oop java_class); > > > This PR is intended to be a strict clean-up that preserves existing behaviors. This pull request has now been integrated. Changeset: 24255848 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/242558484985cb954b0e658776fd59cbca1be1db Stats: 110 lines in 15 files changed: 9 ins; 30 del; 71 mod 8367142: Avoid InstanceKlass::cast when converting java mirror to InstanceKlass Reviewed-by: dholmes, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/27158 From kvn at openjdk.org Tue Sep 16 01:18:16 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 16 Sep 2025 01:18:16 GMT Subject: RFR: 8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive [v2] In-Reply-To: References: <9tei5T4Ox7c_zVMGBsROyJTxsdRjKAXDQTOPo3d62sM=.b2331cfb-b759-4552-9a79-6cd0c71097cb@github.com> Message-ID: On Tue, 16 Sep 2025 01:02:07 GMT, Ioi Lam wrote: >> src/hotspot/share/cds/cdsConfig.cpp line 762: >> >>> 760: log_warning(cds)("AOTClassLinking is not supported for dynamic CDS archive"); >>> 761: FLAG_SET_ERGO(AOTClassLinking, false); >>> 762: } >> >> Can you do it in `CDSConfig::check_vm_args_consistency()` instead, where `AOTClassLinking` is set ergonomically? > > At that point, `is_dumping_dynamic_archive()` will always return zero, as we don't know if we can dump the dynamic archive until `CDSConfig::ergo_init_classic_archive_paths()`, which is called much later. > > The calling sequence is: > > - `CDSConfig::check_vm_args_consistency()` > - `CDSConfig::ergo_initialize ()`-> `ergo_init_classic_archive_paths()` > - `CDSConfig::prepare_for_dumping()` > > Today we are doing ergo setting of AOT flags inside `check_vm_args_consistency()`. I think we should move that to the end of `CDSConfig::ergo_initialize()`. Since that's a bigger scope, maybe I should do that in a follow-up PR? > > The current PR still works as intended, because `AOTClassLinking` acts as a master switch that will turn off all other AOT optimizations for dynamic dump, regardless of the values of `AOTInvokeDynamicLinking`, etc. Okay. An other thing. I think you need to issue warning only if `AOTClassLinking` is set on command line. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27242#discussion_r2350427982 From kvn at openjdk.org Tue Sep 16 01:18:17 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 16 Sep 2025 01:18:17 GMT Subject: RFR: 8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive [v2] In-Reply-To: References: <9tei5T4Ox7c_zVMGBsROyJTxsdRjKAXDQTOPo3d62sM=.b2331cfb-b759-4552-9a79-6cd0c71097cb@github.com> Message-ID: On Tue, 16 Sep 2025 01:11:57 GMT, Vladimir Kozlov wrote: >> At that point, `is_dumping_dynamic_archive()` will always return zero, as we don't know if we can dump the dynamic archive until `CDSConfig::ergo_init_classic_archive_paths()`, which is called much later. >> >> The calling sequence is: >> >> - `CDSConfig::check_vm_args_consistency()` >> - `CDSConfig::ergo_initialize ()`-> `ergo_init_classic_archive_paths()` >> - `CDSConfig::prepare_for_dumping()` >> >> Today we are doing ergo setting of AOT flags inside `check_vm_args_consistency()`. I think we should move that to the end of `CDSConfig::ergo_initialize()`. Since that's a bigger scope, maybe I should do that in a follow-up PR? >> >> The current PR still works as intended, because `AOTClassLinking` acts as a master switch that will turn off all other AOT optimizations for dynamic dump, regardless of the values of `AOTInvokeDynamicLinking`, etc. > > Okay. > > An other thing. I think you need to issue warning only if `AOTClassLinking` is set on command line. Also what about AOTMode and other AOT flags? `setup_compiler_args()` are set in `check_vm_args_consistency()` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27242#discussion_r2350429762 From iklam at openjdk.org Tue Sep 16 02:43:32 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Sep 2025 02:43:32 GMT Subject: RFR: 8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive [v3] In-Reply-To: References: Message-ID: > Support of `-XX:+AOTClassLinking` for dynamic CDS archive is not an documented feature of [JEP 483](https://openjdk.org/jeps/483). It has very small performance benefit and complicates the development of future AOT optimizations. > > After this PR, `-XX:+AOTClassLinking` will have no effect when creating a dynamic CDS archive. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Added assert that AOTClassLinking should be be ergonomically set for dynamic dump ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27242/files - new: https://git.openjdk.org/jdk/pull/27242/files/e94f0503..0ff6fd44 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27242&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27242&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27242.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27242/head:pull/27242 PR: https://git.openjdk.org/jdk/pull/27242 From iklam at openjdk.org Tue Sep 16 02:43:33 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Sep 2025 02:43:33 GMT Subject: RFR: 8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive [v2] In-Reply-To: References: <9tei5T4Ox7c_zVMGBsROyJTxsdRjKAXDQTOPo3d62sM=.b2331cfb-b759-4552-9a79-6cd0c71097cb@github.com> Message-ID: On Tue, 16 Sep 2025 01:14:08 GMT, Vladimir Kozlov wrote: >> Okay. >> >> An other thing. I think you need to issue warning only if `AOTClassLinking` is set on command line. > > Also what about AOTMode and other AOT flags? `setup_compiler_args()` are set in `check_vm_args_consistency()` > An other thing. I think you need to issue warning only if `AOTClassLinking` is set on command line. The default value of `AOTClassLinking` is false, so if we come here, it must have been set in the command-line. I added an assert (so our ERGO code doesn't set it by mistake). > Also what about AOTMode and other AOT flags? setup_compiler_args() are set in check_vm_args_consistency() AOTMode/AOTConfiguration/AOTCache/AOTCacheOutput needs to be checked in `check_vm_args_consistency()` -> `check_aot_flags()`. If these flags are inconsistent, the JVM will exit. I think the ergo setting of these flags should also be there as well. The settings of optimization levels, including all the settings in `setup_compiler_args()`, should be moved to `CDSConfig::ergo_initialize()`. If we see any inconsistent settings, they should be correct with `FLAG_SET_ERGO()` (and we don't exit the VM). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27242#discussion_r2350518370 From iklam at openjdk.org Tue Sep 16 02:53:04 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Sep 2025 02:53:04 GMT Subject: RFR: 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition() Message-ID: Simplify the boilerplate code in jvm.cpp that calls `JvmtiThreadState::class_to_verify_considering_redefinition()`, and reduce the number of `InstanceKlass::cast()` calls. I also changed a few fields/arguments from `Klass*` to `InstanceKlass*` as these are used exclusively with `InstanceKlass*`. ------------- Commit messages: - 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition() Changes: https://git.openjdk.org/jdk/pull/27303/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27303&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367719 Stats: 128 lines in 3 files changed: 26 ins; 33 del; 69 mod Patch: https://git.openjdk.org/jdk/pull/27303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27303/head:pull/27303 PR: https://git.openjdk.org/jdk/pull/27303 From dholmes at openjdk.org Tue Sep 16 03:02:09 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 16 Sep 2025 03:02:09 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v3] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 10:29:11 GMT, Ivan Walulya wrote: >> Thanks, I completely overlooked the JVMTI callbacks. It?s probably better to stall with a timeout and then return an allocation failure. > > I moved the `Universe::before_exit()` call and also added a timed `wait`. > @dholmes-ora do you have any concerns with this approach? Yes I do have concerns - sorry. Any change to the shutdown sequence needs very careful analysis. You have now changed the circumstances whereby the JVMTI events get posted. Maybe it won't matter, maybe it will - the issue is that it is very hard to determine the impact of such a change until you get notified that someone's code is now broken. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2350540080 From fyang at openjdk.org Tue Sep 16 03:51:11 2025 From: fyang at openjdk.org (Fei Yang) Date: Tue, 16 Sep 2025 03:51:11 GMT Subject: RFR: 8367532: Declare all stubgen stub entries including internal cross-stub entries In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 15:13:07 GMT, Andrew Dinn wrote: > This PR adds declarations for internal entries used to daisy chain memory copy stubs and ensures they are saved to generated fields when produced and accessed via those fields when consumed. This will ensure they are saved and restored correctly when stubgen blobs are included in the AOT Code Cache. > > The PR also fixes a few AArch64 stubs which do not currently have their first entry at offset 0, another thing that will be needed to simplify AOT Code cache save and restore. The riscv part seems fine to me. Thanks. ------------- Marked as reviewed by fyang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27228#pullrequestreview-3227024370 From fyang at openjdk.org Tue Sep 16 03:51:12 2025 From: fyang at openjdk.org (Fei Yang) Date: Tue, 16 Sep 2025 03:51:12 GMT Subject: RFR: 8367532: Declare all stubgen stub entries including internal cross-stub entries In-Reply-To: <6N06v2kLnE8xiOzV_Wz09ULHb0EWjQ32Bf8QOuLN8kY=.d86e8952-b240-47b6-b322-6377e88c8d6c@github.com> References: <6N06v2kLnE8xiOzV_Wz09ULHb0EWjQ32Bf8QOuLN8kY=.d86e8952-b240-47b6-b322-6377e88c8d6c@github.com> Message-ID: On Mon, 15 Sep 2025 16:02:56 GMT, Andrew Dinn wrote: > @RealFYang Could you check that this patch does works ok on riscv? It should be enough to 1) make images and 2) make test with TEST=test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java and TEST=test/hotspot/jtreg/compiler/unsafe/UnsafeArrayCopy.java Yes, the tests works fine with a fastdebug build. Thanks for the ping! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27228#issuecomment-3294763278 From kbarrett at openjdk.org Tue Sep 16 04:45:23 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 16 Sep 2025 04:45:23 GMT Subject: RFR: 8252582: HotSpot Style Guide should permit variable templates In-Reply-To: References: Message-ID: <9hUH1qBRX4d6CXWWmL2f0JXpjNcL4T82CruLjH-5954=.05957ee0-33b7-4be9-8d39-5068d46bf9f9@github.com> On Fri, 12 Sep 2025 01:13:25 GMT, Kim Barrett wrote: > Please review this change to the HotSpot Style Guide to permit the use of > variable templates. This is a C++14 feature that, while fairly simple, didn't > get into the initial permitted for HotSpot list because I just didn't get to > it and nobody asked for it. And it has languished on the "undecided" list for > the same reasons. But recently I've had reason to want to use this feature a > couple of times, so I'm now proposing we allow it. > > I merged it into the section for Inline Variables (a C++17 feature), as the > two are closely related. Variable templates were even listed as one of the > workarounds being used to make up for the lack of inline variables. Thanks for reviews and approval. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27240#issuecomment-3295110649 From kbarrett at openjdk.org Tue Sep 16 04:45:24 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 16 Sep 2025 04:45:24 GMT Subject: Integrated: 8252582: HotSpot Style Guide should permit variable templates In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 01:13:25 GMT, Kim Barrett wrote: > Please review this change to the HotSpot Style Guide to permit the use of > variable templates. This is a C++14 feature that, while fairly simple, didn't > get into the initial permitted for HotSpot list because I just didn't get to > it and nobody asked for it. And it has languished on the "undecided" list for > the same reasons. But recently I've had reason to want to use this feature a > couple of times, so I'm now proposing we allow it. > > I merged it into the section for Inline Variables (a C++17 feature), as the > two are closely related. Variable templates were even listed as one of the > workarounds being used to make up for the lack of inline variables. This pull request has now been integrated. Changeset: 0fbae805 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/0fbae8050b6f853053c7dee6a43d3ffbcfa69954 Stats: 50 lines in 2 files changed: 15 ins; 7 del; 28 mod 8252582: HotSpot Style Guide should permit variable templates Reviewed-by: dholmes, stefank, kvn ------------- PR: https://git.openjdk.org/jdk/pull/27240 From aboldtch at openjdk.org Tue Sep 16 05:08:29 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 16 Sep 2025 05:08:29 GMT Subject: RFR: 8367150: Add a header line to improve VMErrorCallback printing In-Reply-To: <7kHwLsN1YaX-vrNMs2hojrCnVuTyzxfDEI3323huo_c=.05650b47-8055-4825-8322-f7547e198251@github.com> References: <7kHwLsN1YaX-vrNMs2hojrCnVuTyzxfDEI3323huo_c=.05650b47-8055-4825-8322-f7547e198251@github.com> Message-ID: <2g7Y4_Ysn-iAx8D_kaHn-7OAfVXLyPr97BOKRxdizhY=.f4eceed3-b9c6-4fd7-a3a1-2b2cff3537f5@github.com> On Tue, 9 Sep 2025 06:26:43 GMT, Axel Boldt-Christmas wrote: > Currently all the registered VMErrorCallback are printed one after another in the error report with only a newline separating them. It makes harder to both quickly find the section, or differentiate the where one starts and another begins in the case of multiple callbacks. I propose we add a simple header line before each callback. > > > VMErrorCallback 1: > [ First callback's print ] > VMErrorCallback 2: > [ Second callback's print ] Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27160#issuecomment-3295262352 From aboldtch at openjdk.org Tue Sep 16 05:08:29 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 16 Sep 2025 05:08:29 GMT Subject: Integrated: 8367150: Add a header line to improve VMErrorCallback printing In-Reply-To: <7kHwLsN1YaX-vrNMs2hojrCnVuTyzxfDEI3323huo_c=.05650b47-8055-4825-8322-f7547e198251@github.com> References: <7kHwLsN1YaX-vrNMs2hojrCnVuTyzxfDEI3323huo_c=.05650b47-8055-4825-8322-f7547e198251@github.com> Message-ID: On Tue, 9 Sep 2025 06:26:43 GMT, Axel Boldt-Christmas wrote: > Currently all the registered VMErrorCallback are printed one after another in the error report with only a newline separating them. It makes harder to both quickly find the section, or differentiate the where one starts and another begins in the case of multiple callbacks. I propose we add a simple header line before each callback. > > > VMErrorCallback 1: > [ First callback's print ] > VMErrorCallback 2: > [ Second callback's print ] This pull request has now been integrated. Changeset: 76e464bc Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/76e464bcd56dab6ef0dfd917f87fdedeb9f838b4 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8367150: Add a header line to improve VMErrorCallback printing Reviewed-by: stefank, ayang ------------- PR: https://git.openjdk.org/jdk/pull/27160 From iklam at openjdk.org Tue Sep 16 05:27:11 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Sep 2025 05:27:11 GMT Subject: RFR: 8362561: Remove diagnostic option AllowArchivingWithJavaAgent Message-ID: Goal: simplify AOT implementation and removed unnecessary tests: This PR removes old CDS tests that use java agents during CDS dump (to increase test coverage by triggering conditions, such as GCs, that were not happening during usual `java -Xshare:dump` operations). Since AOT assembly is much more complex now, we have enough coverage. These old tests are no longer necessary. With these tests removed, we no longer need the `-XX:-AllowArchivingWithJavaAgent` diagnostic flag, which has been abused by users despite the warning that this flag should not be used in production. ------------- Commit messages: - Added test case for dynamic archive with -javaagent - 8362561: Remove diagnostic option AllowArchivingWithJavaAgent Changes: https://git.openjdk.org/jdk/pull/27304/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27304&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8362561 Stats: 1198 lines in 25 files changed: 41 ins; 1147 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/27304.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27304/head:pull/27304 PR: https://git.openjdk.org/jdk/pull/27304 From kbarrett at openjdk.org Tue Sep 16 05:50:47 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 16 Sep 2025 05:50:47 GMT Subject: RFR: 8367724: Remove Trailing Return Types from undecided list Message-ID: <46T-RDnR9-S5ksqd56yTDZOrjMp5FtV0nLEcynfSmOE=.efddc6d4-1db6-4b7e-a1df-d857e320c277@github.com> Please review this trivial editorial change to the HotSpot Style Guide. This change removes Trailing Return Types from the undecided list. This should have been done as part of JDK-8366057, but was forgotten. ------------- Commit messages: - remove trailing return types from undecided list Changes: https://git.openjdk.org/jdk/pull/27305/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27305&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367724 Stats: 5 lines in 2 files changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27305.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27305/head:pull/27305 PR: https://git.openjdk.org/jdk/pull/27305 From fyang at openjdk.org Tue Sep 16 06:06:23 2025 From: fyang at openjdk.org (Fei Yang) Date: Tue, 16 Sep 2025 06:06:23 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v59] In-Reply-To: References: Message-ID: <-D3Oiz-fmDudrEt2zZDa40Xff-Z4DP5GBWhts-CxPsY=.ea2ea9d6-49e6-4973-b4d2-cc1e0201f3c8@github.com> On Thu, 11 Sep 2025 07:24:13 GMT, Thomas Schatzl wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * walulyai review > > That test failure in windows-x64 is a shenandoah timeout that looks unrelated. @tschatzl : Hi, would you mind adding a small cleanup change for riscv? This also adds back the assertion about the registers. Still test good on linux-riscv64 platform. [riscv-addon.diff.txt](https://github.com/user-attachments/files/22356611/riscv-addon.diff.txt) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3295662846 From kbarrett at openjdk.org Tue Sep 16 06:24:12 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 16 Sep 2025 06:24:12 GMT Subject: RFR: 8367536: Change RBTree to use C++17 features [v2] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 15:01:36 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> C++17 lets us tidy up som of the ugly templating done in the red-black tree. We can replace the `std::false_type`/`std::true_type` tricks used to discover comparator and verifier signatures with the new `std::is_invocable(_r_v)`, and most of the overload/SFINAE noise can disappear thanks to `if constexpr`. >> >> We can now write one-liners such as: >> ```c++ >> static constexpr bool HasKeyComparator = std::is_invocable_r_v; >> >> >> and then select the right branch with >> ```c++ >> if constexpr (HasKeyComparator) { } >> >> inside a single function instead of having several `ENABLE_IF` overloads. >> >> This results in fewer lines, clearer intent, and more readable errors, while keeping behaviour identical. >> >> Testing: >> - Oracle tiers 1-3 > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > removed unneeded CMP templates Looks good. src/hotspot/share/utilities/rbTree.hpp line 201: > 199: template > 200: static constexpr bool HasKeyComparator = > 201: std::is_invocable_r_v; Note that these are static data member templates, which were not permitted by the style guide until about an hour ago. :) ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27260#pullrequestreview-3227581496 PR Review Comment: https://git.openjdk.org/jdk/pull/27260#discussion_r2350967857 From dholmes at openjdk.org Tue Sep 16 06:35:44 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 16 Sep 2025 06:35:44 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two In-Reply-To: References: Message-ID: <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com> On Wed, 10 Sep 2025 16:19:17 GMT, Johan Sj?len wrote: > Hi, > > This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array` to store the offsets in and an `Array` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`. > > We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately. > > For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc. > > On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement. > > Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again. Overall this looks good - a lot to digest though, so this is only an initial pass (and I'm not that familiar with the existing code). Quite a few minor issues (mainly use of `CHECK` macros), some comments and suggestions. Thanks src/hotspot/share/classfile/classFileParser.cpp line 3327: > 3325: bootstrap_methods_u2_len, > 3326: _loader_data, > 3327: CHECK); Suggestion: cp->bsm_entries().start_extension(num_bootstrap_methods, bootstrap_methods_u2_len, _loader_data, CHECK); Fix indent src/hotspot/share/classfile/classFileParser.cpp line 3338: > 3336: "bootstrap_method_index %u has bad constant type in class file %s", > 3337: bootstrap_method_ref, > 3338: CHECK); Suggestion: bootstrap_method_ref, CHECK); Fix indent src/hotspot/share/oops/constantPool.cpp line 53: > 51: #include "memory/universe.hpp" > 52: #include "oops/array.hpp" > 53: #include "oops/constantPool.hpp" Suggestion: You don't include the base header if including the .inline.hpp src/hotspot/share/oops/constantPool.cpp line 1614: > 1612: ConstantPool::start_extension(const constantPoolHandle& ext_cp, TRAPS) { > 1613: return bsm_entries().start_extension(ext_cp->bsm_entries(), pool_holder()->class_loader_data(), > 1614: CHECK_(BSMAttributeEntries::InsertionIterator())); You can't use a `CHECK` macro on a return statement - the expansion puts the exception check after the return where it is unreachable. src/hotspot/share/oops/constantPool.cpp line 1619: > 1617: > 1618: void ConstantPool::end_extension(BSMAttributeEntries::InsertionIterator iter, TRAPS) { > 1619: bsm_entries().end_extension(iter, pool_holder()->class_loader_data(), CHECK); Again no CHECK on a return. In this case all you need is `THREAD`. src/hotspot/share/oops/constantPool.cpp line 1625: > 1623: void ConstantPool::copy_bsm_entries(const constantPoolHandle& from_cp, > 1624: const constantPoolHandle& to_cp, > 1625: TRAPS) { Suggestion: void ConstantPool::copy_bsm_entries(const constantPoolHandle& from_cp, const constantPoolHandle& to_cp, TRAPS) { Fix indent src/hotspot/share/oops/constantPool.cpp line 1628: > 1626: to_cp->bsm_entries().append(from_cp->bsm_entries(), > 1627: to_cp->pool_holder()->class_loader_data(), > 1628: CHECK); Suggestion: to_cp->bsm_entries().append(from_cp->bsm_entries(), to_cp->pool_holder()->class_loader_data(), THREAD); Fix indent, plus (pre-existing) no need for CHECK when you will return anyway. src/hotspot/share/oops/constantPool.cpp line 1659: > 1657: } > 1658: } > 1659: copy_bsm_entries(from_cp, to_cp, CHECK); Suggestion: copy_bsm_entries(from_cp, to_cp, THREAD); (pre-existing) no need for CHECK when you will return anyway. src/hotspot/share/oops/constantPool.cpp line 1831: > 1829: const BSMAttributeEntry* const bsmae2 = cp2->bsm_attribute_entry(idx2); > 1830: int cp_entry_index1 = bsmae1->bootstrap_method_index(); > 1831: int cp_entry_index2 = bsmae2->bootstrap_method_index(); The existing simple names are more readable in my opinion. src/hotspot/share/oops/constantPool.cpp line 1859: > 1857: // Return the index of a matching bootstrap attribute record or (-1) if there is no match. > 1858: int ConstantPool::find_matching_bsm_entry(int pattern_i, > 1859: const constantPoolHandle& search_cp, int offset_limit) { Suggestion: int ConstantPool::find_matching_bsm_entry(int pattern_i, const constantPoolHandle& search_cp, int offset_limit) { Fix indent src/hotspot/share/oops/constantPool.cpp line 2348: > 2346: assert(num_entries + iter._cur_offset <= iter.insert_into->_offsets->length(), "must"); > 2347: for (int i = 0; i < num_entries; i++) { > 2348: const BSMAttributeEntry* bsmae = entry(i); Nit: It's okay to use a simple name like `e` to represent `entry` - when you don't have different types of entries involved we don't need to encode the type in the variable name. EDIT: just like in `BSMAttributeEntries::InsertionIterator::reserve_new_entry`. src/hotspot/share/oops/constantPool.cpp line 2355: > 2353: > 2354: BSMAttributeEntries::InsertionIterator BSMAttributeEntries::start_extension(const BSMAttributeEntries& other, ClassLoaderData* loader_data, TRAPS) { > 2355: return start_extension(other.number_of_entries(), other.array_length(), loader_data, CHECK_(BSMAttributeEntries::InsertionIterator())); Again can't use `CHECK_` on a return statement. src/hotspot/share/oops/constantPool.cpp line 2388: > 2386: InsertionIterator iter = start_extension(other, loader_data, CHECK); > 2387: other.copy_into(iter, other.number_of_entries()); > 2388: end_extension(iter, loader_data, CHECK); Again no need for CHECK on final statement. src/hotspot/share/oops/constantPool.cpp line 2393: > 2391: > 2392: void BSMAttributeEntries::end_extension(InsertionIterator& iter, ClassLoaderData* loader_data, > 2393: TRAPS) { Suggestion: void BSMAttributeEntries::end_extension(InsertionIterator& iter, ClassLoaderData* loader_data, TRAPS) { This line is still shorter than 2382 above src/hotspot/share/oops/constantPool.hpp line 145: > 143: : insert_into(insert_into), > 144: _cur_offset(cur_offset), > 145: _cur_array(cur_array) {} Not sure what the indentation rules are for constructors but I think we need some more. src/hotspot/share/oops/constantPool.hpp line 200: > 198: // Extend to have the space for both this BSMAEntries and other's. > 199: // Does not copy in the other's BSMAEntrys, that must be done via the InsertionIterator. > 200: // This starts an insertion iterator. Any call to start_extension must have a matching end_exntesion call. Suggestion: // This starts an insertion iterator. Any call to start_extension must have a matching end_extension call. src/hotspot/share/oops/constantPool.hpp line 224: > 222: InstanceKlass* _pool_holder; // the corresponding class > 223: > 224: BSMAttributeEntries _bsmaentries; Nit: `_entries` would suffice. src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 394: > 392: write_attribute_name_index("BootstrapMethods"); > 393: u4 length = sizeof(u2) + // num_bootstrap_methods > 394: // The rest of it The comment doesn't add any value here. src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 398: > 396: write_u4(length); > 397: > 398: int num_bootstrap_methods = cpool()->bsm_entries().number_of_entries(); I'm confused about the seemingly different uses of `num_bootstrap_methods` here and in the comment above: sizeof(u2) + // num_bootstrap_methods ? src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 49: > 47: #include "oops/annotations.hpp" > 48: #include "oops/constantPool.hpp" > 49: #include "oops/constantPool.inline.hpp" Suggestion: #include "oops/constantPool.inline.hpp" You don't include the regular header when you include the inline one. src/hotspot/share/prims/jvmtiRedefineClasses.hpp line 371: > 369: intArray * _bsm_index_map_p; > 370: > 371: // After merge_constant_pools pass 0 the BSMAttribute entries of merge_cp_p will have been expanded to fit scratch_cp. This comment doesn't read correctly. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java line 444: > 442: a = bsmaentries_offsets.getValue(a); > 443: return VMObjectFactory.newObject(U4Array.class, a); > 444: } Suggestion: private U4Array getOffsets() { Address a = getAddress().addOffsetTo(bsmaentries); if (a == null) return null; a = bsmaentries_offsets.getValue(a); return VMObjectFactory.newObject(U4Array.class, a); } Fix indent. (Note this file is using 2-indent instead of the 4-indent it should for Java code.) ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27198#pullrequestreview-3227461452 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350904057 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350905434 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350911716 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350919770 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350921555 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350923178 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350926508 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350929316 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350937167 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350939688 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350948252 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350949299 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350952103 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350954308 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350974468 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350977926 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350979954 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350990306 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350994934 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2350996928 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2351002821 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2351014174 From stefank at openjdk.org Tue Sep 16 06:38:23 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 16 Sep 2025 06:38:23 GMT Subject: RFR: 8367724: Remove Trailing Return Types from undecided list In-Reply-To: <46T-RDnR9-S5ksqd56yTDZOrjMp5FtV0nLEcynfSmOE=.efddc6d4-1db6-4b7e-a1df-d857e320c277@github.com> References: <46T-RDnR9-S5ksqd56yTDZOrjMp5FtV0nLEcynfSmOE=.efddc6d4-1db6-4b7e-a1df-d857e320c277@github.com> Message-ID: On Tue, 16 Sep 2025 05:43:16 GMT, Kim Barrett wrote: > Please review this trivial editorial change to the HotSpot Style Guide. This > change removes Trailing Return Types from the undecided list. This should have > been done as part of JDK-8366057, but was forgotten. Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27305#pullrequestreview-3227747286 From epeter at openjdk.org Tue Sep 16 06:42:18 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 16 Sep 2025 06:42:18 GMT Subject: RFR: 8367694: Fix jtreg test failure when Intel APX is enabled for KNL platforms [v2] In-Reply-To: References: Message-ID: <6Y52fAzQqJ1mb4OApVOaChF6JcV0KIzhNF3tkYBr3ak=.b0e69dac-fc2c-4f94-8678-95e54ae5aade@github.com> On Mon, 15 Sep 2025 20:08:10 GMT, Srinivas Vamsi Parasa wrote: >> This goal of this PR is fix the jtreg test failure observed in compiler test: `test/hotspot/jtreg/compiler/loopopts/superword/TestDependencyOffsets.java` >> >> The test failure is occurring specifically for the tests with ids = {avx512-v064-A, avx512-v064-U, avx512-v032-A, avx512-v032-U}. These tests are run with KNL hardware features enabled (`-XX:+UseKNLSetting`). >> >> The two main causes of test failure are: >> 1. KNL does not support Intel APX. Currently, APX is not turned off when using KNL. This PR fixes this issue. >> 2. BMI2 instructions like sarxl are encoded incorrectly with `uses_vl=true` (use vector length). This PR fixes the encoding to use the correct one:`uses_vl=false`. >> >> After fixing these two bugs, `TestDependencyOffsets.java` is passing using the SDE emulator when APX is enabled. > > Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: > > change the location of APX feature check Looks reasonable. Let me do some testing, takes about 24h. ------------- PR Review: https://git.openjdk.org/jdk/pull/27299#pullrequestreview-3227765182 From dholmes at openjdk.org Tue Sep 16 06:44:33 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 16 Sep 2025 06:44:33 GMT Subject: RFR: 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition() In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 02:44:26 GMT, Ioi Lam wrote: > Simplify the boilerplate code in jvm.cpp that calls `JvmtiThreadState::class_to_verify_considering_redefinition()`, and reduce the number of `InstanceKlass::cast()` calls. > > I also changed a few fields/arguments from `Klass*` to `InstanceKlass*` as these are used exclusively with `InstanceKlass*`. Looks good. Just some minor nits. Thanks src/hotspot/share/prims/jvm.cpp line 2263: > 2261: // Please, refer to the description in the jvmtiThreadState.hpp. > 2262: > 2263: inline Klass* get_klass_considering_redefinition(jclass cls, JavaThread *thread) { Suggestion: inline Klass* get_klass_considering_redefinition(jclass cls, JavaThread* thread) { src/hotspot/share/prims/jvm.cpp line 2269: > 2267: } > 2268: > 2269: inline InstanceKlass* get_instance_klass_considering_redefinition(jclass cls, JavaThread *thread) { Suggestion: inline InstanceKlass* get_instance_klass_considering_redefinition(jclass cls, JavaThread* thread) { src/hotspot/share/prims/jvmtiThreadState.hpp line 31: > 29: #include "memory/allocation.hpp" > 30: #include "oops/oopHandle.hpp" > 31: #include "oops/instanceKlass.hpp" Suggestion: #include "oops/instanceKlass.hpp" #include "oops/oopHandle.hpp" Include order is wrong. src/hotspot/share/prims/jvmtiThreadState.hpp line 438: > 436: static inline > 437: Klass* class_to_verify_considering_redefinition(Klass* klass, > 438: JavaThread *thread) { Suggestion: JavaThread* thread) { src/hotspot/share/prims/jvmtiThreadState.hpp line 445: > 443: } else { > 444: return class_to_verify_considering_redefinition(InstanceKlass::cast(klass), > 445: thread); Suggestion: return class_to_verify_considering_redefinition(InstanceKlass::cast(klass), thread); src/hotspot/share/prims/jvmtiThreadState.hpp line 451: > 449: static inline > 450: InstanceKlass* class_to_verify_considering_redefinition(InstanceKlass* klass, > 451: JavaThread *thread) { Suggestion: JavaThread* thread) { ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27303#pullrequestreview-3227749202 PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2351033232 PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2351035033 PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2351044566 PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2351048289 PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2351050636 PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2351051532 From duke at openjdk.org Tue Sep 16 06:54:33 2025 From: duke at openjdk.org (duke) Date: Tue, 16 Sep 2025 06:54:33 GMT Subject: RFR: 8359104: gc/TestAlwaysPreTouchBehavior.java# fails on Linux [v3] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 14:32:19 GMT, Andreas Steiner wrote: >> Get accurate RSS, from smaps_rollup if available(Linux >= 4.14), because the RSS from status is inaccurate especially on systems with more than 32 CPUs. >> >> Not sure if all the additional meminfos like the Pss, Pss_dirty, Pss_Anon, Pss_File, Pss_Shmem, Swap and SwapPss are really needed too. But can be perhaps helpful too. >> >> As the inaccurate memory infos are still used in other methods: >> - [print_process_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2393) >> - [jfr_report_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2686) >> - [trim_native_heap()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L5376) >> >> one can think about to use the accurate values there too. > > Andreas Steiner has updated the pull request incrementally with one additional commit since the last revision: > > Changed num_found and num_values to size_t, do the null-check right after the fopen and return early, eliminated the variable shadowing of info @ansteiner Your change (at version 6c6fc40e006046aad728a150cd31bdf643acbc6f) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27192#issuecomment-3295952608 From asteiner at openjdk.org Tue Sep 16 07:20:34 2025 From: asteiner at openjdk.org (Andreas Steiner) Date: Tue, 16 Sep 2025 07:20:34 GMT Subject: Integrated: 8359104: gc/TestAlwaysPreTouchBehavior.java# fails on Linux In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 13:55:59 GMT, Andreas Steiner wrote: > Get accurate RSS, from smaps_rollup if available(Linux >= 4.14), because the RSS from status is inaccurate especially on systems with more than 32 CPUs. > > Not sure if all the additional meminfos like the Pss, Pss_dirty, Pss_Anon, Pss_File, Pss_Shmem, Swap and SwapPss are really needed too. But can be perhaps helpful too. > > As the inaccurate memory infos are still used in other methods: > - [print_process_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2393) > - [jfr_report_memory_info()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L2686) > - [trim_native_heap()](https://github.com/openjdk/jdk/blob/385c13298932f1de16e6161652be35d966d822ec/src/hotspot/os/linux/os_linux.cpp#L5376) > > one can think about to use the accurate values there too. This pull request has now been integrated. Changeset: 73df06c8 Author: Andreas Steiner Committer: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/73df06c80c33be584b054a528ecdab4ecbf51d56 Stats: 61 lines in 3 files changed: 57 ins; 0 del; 4 mod 8359104: gc/TestAlwaysPreTouchBehavior.java# fails on Linux Reviewed-by: mbaesken, ayang ------------- PR: https://git.openjdk.org/jdk/pull/27192 From jsjolen at openjdk.org Tue Sep 16 07:28:21 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 16 Sep 2025 07:28:21 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two In-Reply-To: <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com> References: <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com> Message-ID: On Tue, 16 Sep 2025 06:24:25 GMT, David Holmes wrote: >> Hi, >> >> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array` to store the offsets in and an `Array` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`. >> >> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately. >> >> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc. >> >> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement. >> >> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again. > > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 49: > >> 47: #include "oops/annotations.hpp" >> 48: #include "oops/constantPool.hpp" >> 49: #include "oops/constantPool.inline.hpp" > > Suggestion: > > #include "oops/constantPool.inline.hpp" > > You don't include the regular header when you include the inline one. I wasn't aware! Thanks > src/hotspot/share/prims/jvmtiRedefineClasses.hpp line 371: > >> 369: intArray * _bsm_index_map_p; >> 370: >> 371: // After merge_constant_pools pass 0 the BSMAttribute entries of merge_cp_p will have been expanded to fit scratch_cp. > > This comment doesn't read correctly. There's a missing comma but otherwise it reads fine to me? I added a few more words. There are multiple passes in the method `merge_constant_pools` and they are numbered. // After merge_constant_pools pass 0, the BSMAttribute entries of merge_cp_p will have been expanded to fit // scratch_cp's BSMAttribute entries as well. // However, the newly acquired space will not have been filled in yet. // To append to this new space, the iterator is used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2351203555 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2351202052 From jsjolen at openjdk.org Tue Sep 16 07:33:24 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 16 Sep 2025 07:33:24 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two In-Reply-To: <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com> References: <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com> Message-ID: On Tue, 16 Sep 2025 06:22:07 GMT, David Holmes wrote: >> Hi, >> >> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array` to store the offsets in and an `Array` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`. >> >> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately. >> >> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc. >> >> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement. >> >> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again. > > src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 394: > >> 392: write_attribute_name_index("BootstrapMethods"); >> 393: u4 length = sizeof(u2) + // num_bootstrap_methods >> 394: // The rest of it > > The comment doesn't add any value here. The previous code did a manual count of the total amount of bytes required. The comment is a bit sloppy, I replaced it with "The rest of the data for the attribute is exactly the u2s in the data array.". The goal is to very explicitly say "we don't need to count, we've got the information already". > src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 398: > >> 396: write_u4(length); >> 397: >> 398: int num_bootstrap_methods = cpool()->bsm_entries().number_of_entries(); > > I'm confused about the seemingly different uses of `num_bootstrap_methods` here and in the comment above: > > sizeof(u2) + // num_bootstrap_methods > > ? I'm trying to explain to the reader what the `sizeof(u2)` stands for, in this case it stands for the bytes taken up by the `num_bootstrap_methods` field in `BootstrapMethods_attribute`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2351227073 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2351221844 From jsjolen at openjdk.org Tue Sep 16 07:36:28 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 16 Sep 2025 07:36:28 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two In-Reply-To: <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com> References: <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com> Message-ID: On Tue, 16 Sep 2025 06:15:25 GMT, David Holmes wrote: > Not sure what the indentation rules are for constructors Same. I added 2 spaces. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2351238027 From tschatzl at openjdk.org Tue Sep 16 07:36:40 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 16 Sep 2025 07:36:40 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v59] In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 07:24:13 GMT, Thomas Schatzl wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * walulyai review > > That test failure in windows-x64 is a shenandoah timeout that looks unrelated. > @tschatzl : Hi, would you mind adding a small cleanup change for riscv? This also adds back the assertion about the registers. Still test good on linux-riscv64 platform. [riscv-addon.diff.txt](https://github.com/user-attachments/files/22356611/riscv-addon.diff.txt) This is the `end` -> `count` transformation in the barrier I suggested earlier for RISC-V, isn't it? Thanks for contributing that, but would you mind me holding off this until @theRealAph acks that similar change for aarch64? It would be unfortunate imo if the implementations diverge too much. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3296253540 From fyang at openjdk.org Tue Sep 16 07:41:46 2025 From: fyang at openjdk.org (Fei Yang) Date: Tue, 16 Sep 2025 07:41:46 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v59] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 07:33:18 GMT, Thomas Schatzl wrote: > > @tschatzl : Hi, would you mind adding a small cleanup change for riscv? This also adds back the assertion about the registers. Still test good on linux-riscv64 platform. [riscv-addon.diff.txt](https://github.com/user-attachments/files/22356611/riscv-addon.diff.txt) > > This is the `end` -> `count` transformation in the barrier I suggested earlier for RISC-V, isn't it? Thanks for contributing that, but would you mind me holding off this until @theRealAph acks that similar change for aarch64? It would be unfortunate imo if the implementations diverge too much. Yes, sure! The purpose is to minimize the difference to avoid possible issues in the future. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3296286316 From jsjolen at openjdk.org Tue Sep 16 08:08:30 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 16 Sep 2025 08:08:30 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two In-Reply-To: <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com> References: <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com> Message-ID: On Tue, 16 Sep 2025 06:03:09 GMT, David Holmes wrote: >> Hi, >> >> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array` to store the offsets in and an `Array` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`. >> >> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately. >> >> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc. >> >> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement. >> >> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again. > > src/hotspot/share/oops/constantPool.cpp line 2348: > >> 2346: assert(num_entries + iter._cur_offset <= iter.insert_into->_offsets->length(), "must"); >> 2347: for (int i = 0; i < num_entries; i++) { >> 2348: const BSMAttributeEntry* bsmae = entry(i); > > Nit: It's okay to use a simple name like `e` to represent `entry` - when you don't have different types of entries involved we don't need to encode the type in the variable name. EDIT: just like in `BSMAttributeEntries::InsertionIterator::reserve_new_entry`. In this particular case, the `entry` method will be shadowed so you have to explicitly write `this->entry()` if you want to use that name. The existence of that variable is so short, we can just call it `e`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2351351291 From phubner at openjdk.org Tue Sep 16 08:34:37 2025 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Tue, 16 Sep 2025 08:34:37 GMT Subject: RFR: 8367724: Remove Trailing Return Types from undecided list In-Reply-To: <46T-RDnR9-S5ksqd56yTDZOrjMp5FtV0nLEcynfSmOE=.efddc6d4-1db6-4b7e-a1df-d857e320c277@github.com> References: <46T-RDnR9-S5ksqd56yTDZOrjMp5FtV0nLEcynfSmOE=.efddc6d4-1db6-4b7e-a1df-d857e320c277@github.com> Message-ID: On Tue, 16 Sep 2025 05:43:16 GMT, Kim Barrett wrote: > Please review this trivial editorial change to the HotSpot Style Guide. This > change removes Trailing Return Types from the undecided list. This should have > been done as part of JDK-8366057, but was forgotten. Marked as reviewed by phubner (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/27305#pullrequestreview-3228369424 From adinn at openjdk.org Tue Sep 16 08:41:23 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 16 Sep 2025 08:41:23 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v2] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 23:20:47 GMT, Ioi Lam wrote: >> This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. >> >> This PR annotates a single class, `jdk.internal.math.MathUtils`. More classes will be added in future PRs. >> >> If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to >> - All of `K`'s super classes >> - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` >> >> Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). >> >> This annotation is awfully similar to `@AOTSafeAnnotation`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Exclude more GC heap size tests as AOT cache size has increased for "make test JTREG=AOT_JDK=onestep ..." Just for clarity you might want to update the PR description to state that this PR "annotates a single aot initializable class, jdk.internal.math.MathUtils (also the object hierarchy root class, Object.class, which has no associated aot initialization but is required for completeness)". More classes will be added in future PRs. Also, the PR description refers to @AOTSafeAnnotation -- do you mean @AOTSafeClassInitializer? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27024#issuecomment-3296618017 PR Comment: https://git.openjdk.org/jdk/pull/27024#issuecomment-3296635606 From jsjolen at openjdk.org Tue Sep 16 08:47:10 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 16 Sep 2025 08:47:10 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two In-Reply-To: <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com> References: <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com> Message-ID: On Tue, 16 Sep 2025 06:32:34 GMT, David Holmes wrote: >> Hi, >> >> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array` to store the offsets in and an `Array` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`. >> >> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately. >> >> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc. >> >> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement. >> >> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again. > > Overall this looks good - a lot to digest though, so this is only an initial pass (and I'm not that familiar with the existing code). > > Quite a few minor issues (mainly use of `CHECK` macros), some comments and suggestions. > > Thanks @dholmes-ora, I resolved all of the conversations (and fixed all of the issues). They should still be reachable via "Files Changed" and then "Conversations". If you do continue a conversation in one of the threads, would you mind pinging me in this main thread? I suspect that Github doesn't send e-mails about convos in resolved threads. Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27198#issuecomment-3296674211 From azafari at openjdk.org Tue Sep 16 09:06:42 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 16 Sep 2025 09:06:42 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v5] In-Reply-To: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: > The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. > The acceptable value is changed to 64K. > > Tests: > linux-x64 tier1 Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: uintptr_t -> uint64_t ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26955/files - new: https://git.openjdk.org/jdk/pull/26955/files/251dd986..fffb77a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=03-04 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/26955.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26955/head:pull/26955 PR: https://git.openjdk.org/jdk/pull/26955 From jsjolen at openjdk.org Tue Sep 16 09:16:59 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 16 Sep 2025 09:16:59 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v2] In-Reply-To: References: Message-ID: <81ranBcjj7BhSeZC1PvFODRT8j0W8RiNC0rF67pw6To=.e7c62964-a7b8-4ccb-a184-42ad2ea1e3af@github.com> > Hi, > > This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array` to store the offsets in and an `Array` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`. > > We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately. > > For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc. > > On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement. > > Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: DHolmes comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27198/files - new: https://git.openjdk.org/jdk/pull/27198/files/d7c89176..3adc5898 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=00-01 Stats: 42 lines in 7 files changed: 4 ins; 3 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/27198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27198/head:pull/27198 PR: https://git.openjdk.org/jdk/pull/27198 From iwalulya at openjdk.org Tue Sep 16 09:26:19 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 16 Sep 2025 09:26:19 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v4] In-Reply-To: References: Message-ID: > Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. > > Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. > > Testing: Tier 1-7 Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: Revert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27190/files - new: https://git.openjdk.org/jdk/pull/27190/files/0e45912b..2ebff06c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=02-03 Stats: 5 lines in 2 files changed: 3 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27190.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27190/head:pull/27190 PR: https://git.openjdk.org/jdk/pull/27190 From iwalulya at openjdk.org Tue Sep 16 09:26:21 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 16 Sep 2025 09:26:21 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v4] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 02:58:12 GMT, David Holmes wrote: >> I moved the `Universe::before_exit()` call and also added a timed `wait`. >> @dholmes-ora do you have any concerns with this approach? > > Yes I do have concerns - sorry. Any change to the shutdown sequence needs very careful analysis. You have now changed the circumstances whereby the JVMTI events get posted. Maybe it won't matter, maybe it will - the issue is that it is very hard to determine the impact of such a change until you get notified that someone's code is now broken. I have undone that part of the change. We can revisit it separately, that way it is easier to backout if it is problematic ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2351648194 From adinn at openjdk.org Tue Sep 16 09:28:24 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 16 Sep 2025 09:28:24 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v2] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 23:20:47 GMT, Ioi Lam wrote: >> This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. >> >> This PR annotates a single class, `jdk.internal.math.MathUtils`. More classes will be added in future PRs. >> >> If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to >> - All of `K`'s super classes >> - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` >> >> Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). >> >> This annotation is awfully similar to `@AOTSafeAnnotation`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Exclude more GC heap size tests as AOT cache size has increased for "make test JTREG=AOT_JDK=onestep ..." src/hotspot/share/cds/aotMetaspace.cpp line 806: > 804: AOTClassInitializer::init_test_class(CHECK); > 805: > 806: if (CDSConfig::is_dumping_final_static_archive()) { What is the reason for moving this earlier to before link_all_loaded_classes? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27024#discussion_r2351659530 From phubner at openjdk.org Tue Sep 16 09:35:02 2025 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Tue, 16 Sep 2025 09:35:02 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary [v2] In-Reply-To: References: Message-ID: > Hi all, > > `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: > 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases), > 2) removes `FilteredJavaFieldStream` entirely, and > 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. > > Testing: Oracle tiers 1-3. Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' into JDK-8365858 - Merge branch 'master' into JDK-8365858 - Fix typo. - Refactor to purely use injected fields. - Remove FilteredJavaFieldStream and usages. - Remove constantPoolOop from Java code. - Make constantPoolOop a hidden vmholder field. ------------- Changes: https://git.openjdk.org/jdk/pull/27209/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27209&range=01 Stats: 194 lines in 9 files changed: 9 ins; 166 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/27209.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27209/head:pull/27209 PR: https://git.openjdk.org/jdk/pull/27209 From phubner at openjdk.org Tue Sep 16 09:35:03 2025 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Tue, 16 Sep 2025 09:35:03 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 16:00:41 GMT, Coleen Phillimore wrote: >> Hi all, >> >> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: >> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases), >> 2) removes `FilteredJavaFieldStream` entirely, and >> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. >> >> Testing: Oracle tiers 1-3. > > ConstantPool in the JVM metadata used to be called constantPoolOop, so I think that's what it's looking to not find. Thanks for the reviews, @coleenp @liach @jdksjolen @alexmenkov. I've merged in the latest mainline which had a merge commit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3297070955 From jsjolen at openjdk.org Tue Sep 16 09:55:48 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 16 Sep 2025 09:55:48 GMT Subject: RFR: 8367249: [REDO] MemBaseline accesses VMT without using lock [v3] In-Reply-To: References: Message-ID: > Hi, > > This is a REDO, as the previous attempt caused build failures when merged with latest master. > The only difference is that the copy ctr for the RBTRee had been integrated with a different PR, but it never should have been. I deleted the copy ctr. > > Thanks. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Fix the rest of the incorrect instances ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27170/files - new: https://git.openjdk.org/jdk/pull/27170/files/c6c65a80..41af4eaf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27170&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27170&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27170.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27170/head:pull/27170 PR: https://git.openjdk.org/jdk/pull/27170 From adinn at openjdk.org Tue Sep 16 10:06:46 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 16 Sep 2025 10:06:46 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v2] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 23:20:47 GMT, Ioi Lam wrote: >> This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. >> >> This PR annotates a single class, `jdk.internal.math.MathUtils`. More classes will be added in future PRs. >> >> If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to >> - All of `K`'s super classes >> - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` >> >> Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). >> >> This annotation is awfully similar to `@AOTSafeAnnotation`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Exclude more GC heap size tests as AOT cache size has increased for "make test JTREG=AOT_JDK=onestep ..." > This annotation is awfully similar to @AOTSafeAnnotation, and I am not sure if we need both Maybe we do want both. @AOTSafeAnnotation is weaker than @AOTInitialize because the former only initializes classes optionally when we find it is needed. If we only had @AOTInitialize then we would lose that optionality. It may not make much difference now -- we probably only have these annotations for JDK classes that would need to be class-inited whatever the training regime. However, as we expand use of the annotation might we risk initing classes and including their state in the archive without necessarily seeing any benefit? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27024#issuecomment-3297343820 From jsjolen at openjdk.org Tue Sep 16 10:11:09 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 16 Sep 2025 10:11:09 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v3] In-Reply-To: References: Message-ID: > Hi, > > This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array` to store the offsets in and an `Array` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`. > > We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately. > > For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc. > > On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement. > > Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Fix type name ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27198/files - new: https://git.openjdk.org/jdk/pull/27198/files/3adc5898..ddf8e8f6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27198/head:pull/27198 PR: https://git.openjdk.org/jdk/pull/27198 From jsjolen at openjdk.org Tue Sep 16 10:24:07 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 16 Sep 2025 10:24:07 GMT Subject: RFR: 8367249: [REDO] MemBaseline accesses VMT without using lock [v4] In-Reply-To: References: Message-ID: > Hi, > > This is a REDO, as the previous attempt caused build failures when merged with latest master. > The only difference is that the copy ctr for the RBTRee had been integrated with a different PR, but it never should have been. I deleted the copy ctr. > > Thanks. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: const-ify a bit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27170/files - new: https://git.openjdk.org/jdk/pull/27170/files/41af4eaf..032fc800 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27170&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27170&range=02-03 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27170.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27170/head:pull/27170 PR: https://git.openjdk.org/jdk/pull/27170 From duke at openjdk.org Tue Sep 16 11:09:28 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 16 Sep 2025 11:09:28 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v4] In-Reply-To: References: Message-ID: <37fyY6jq5j6CdWbBJQK94mkR70ik6oINWLiAR6nPY90=.dd5f6d7c-8a02-46f1-99db-bfb3500772fb@github.com> On Tue, 16 Sep 2025 09:26:19 GMT, Ivan Walulya wrote: >> Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. >> >> Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. >> >> Testing: Tier 1-7 > > Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: > > Revert Changes requested by JonasNorlinder at github.com (no known OpenJDK username). src/hotspot/share/memory/universe.cpp line 1347: > 1345: > 1346: void Universe::before_exit() { > 1347: log_cpu_time(); Why did you move `log_cpu_time()`? During the review of CPUTimeUsage refactor (https://github.com/openjdk/jdk/pull/26621) we discussed this choice. Given that it still includes more than just GC I think it should stay in `Universe`. Also the PR title does not reflect that it would include a refactor of CPUTimeUsage. ------------- PR Review: https://git.openjdk.org/jdk/pull/27190#pullrequestreview-3229290160 PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2352019449 From adinn at openjdk.org Tue Sep 16 11:13:17 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 16 Sep 2025 11:13:17 GMT Subject: RFR: 8367532: Declare all stubgen stub entries including internal cross-stub entries In-Reply-To: References: <6N06v2kLnE8xiOzV_Wz09ULHb0EWjQ32Bf8QOuLN8kY=.d86e8952-b240-47b6-b322-6377e88c8d6c@github.com> Message-ID: On Tue, 16 Sep 2025 03:47:53 GMT, Fei Yang wrote: >> @RealFYang Could you check that this patch does works ok on riscv? It should be enough to 1) make images and 2) make test with TEST=test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java and TEST=test/hotspot/jtreg/compiler/unsafe/UnsafeArrayCopy.java > >> @RealFYang Could you check that this patch does works ok on riscv? It should be enough to 1) make images and 2) make test with TEST=test/hotspot/jtreg/compiler/arraycopy/stress/TestStressArrayCopy.java and TEST=test/hotspot/jtreg/compiler/unsafe/UnsafeArrayCopy.java > > Yes, the tests works fine with a fastdebug build. Thanks for the ping! @RealFYang Thanks very much for checking and reviewing. @vnkozlov @ashu-mehra any chance of a second review ------------- PR Comment: https://git.openjdk.org/jdk/pull/27228#issuecomment-3297873472 From duke at openjdk.org Tue Sep 16 11:19:15 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 16 Sep 2025 11:19:15 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v4] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 09:26:19 GMT, Ivan Walulya wrote: >> Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. >> >> Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. >> >> Testing: Tier 1-7 > > Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: > > Revert I think we want either `log_cpu_time` or `gc_threads_do` (which we might want to avoid for performance reasons?) to check `is_shutting_down()` such that we can't query terminated GC workers. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27190#issuecomment-3297922874 From adinn at openjdk.org Tue Sep 16 12:02:59 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 16 Sep 2025 12:02:59 GMT Subject: RFR: 8252582: HotSpot Style Guide should permit variable templates In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 23:47:26 GMT, Kim Barrett wrote: > Anyone else have an opinion? Sorry I am too late to review the PR but I did read the proposal and wish to record approval. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27240#issuecomment-3298236460 From iwalulya at openjdk.org Tue Sep 16 12:17:05 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 16 Sep 2025 12:17:05 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v4] In-Reply-To: <37fyY6jq5j6CdWbBJQK94mkR70ik6oINWLiAR6nPY90=.dd5f6d7c-8a02-46f1-99db-bfb3500772fb@github.com> References: <37fyY6jq5j6CdWbBJQK94mkR70ik6oINWLiAR6nPY90=.dd5f6d7c-8a02-46f1-99db-bfb3500772fb@github.com> Message-ID: On Tue, 16 Sep 2025 11:06:58 GMT, Jonas Norlinder wrote: >> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert > > src/hotspot/share/memory/universe.cpp line 1347: > >> 1345: >> 1346: void Universe::before_exit() { >> 1347: log_cpu_time(); > > Why did you move `log_cpu_time()`? During the review of CPUTimeUsage refactor (https://github.com/openjdk/jdk/pull/26621) we discussed this choice. Given that it still includes more than just GC I think it should stay in `Universe`. Also the PR title does not reflect that it would include a refactor of CPUTimeUsage. Main reason was to have the `log_cpu_time` and `AtomicAccess::release_store(&_is_shutting_down, true)` under same critical section. Otherwise, we have no guarantee that we don't continue GCs after `log_cpu_time`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2352287921 From jsjolen at openjdk.org Tue Sep 16 12:21:17 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 16 Sep 2025 12:21:17 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary [v2] In-Reply-To: References: Message-ID: <8fizZwH_W2n31RiJAJZAxU0dMFs3UaLU0Uk-yoTHST0=.7ab516ac-e506-4635-b08e-f4a3af4cfb7b@github.com> On Tue, 16 Sep 2025 09:35:02 GMT, Paul H?bner wrote: >> Hi all, >> >> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: >> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases), >> 2) removes `FilteredJavaFieldStream` entirely, and >> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. >> >> Testing: Oracle tiers 1-3. > > Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'master' into JDK-8365858 > - Merge branch 'master' into JDK-8365858 > - Fix typo. > - Refactor to purely use injected fields. > - Remove FilteredJavaFieldStream and usages. > - Remove constantPoolOop from Java code. > - Make constantPoolOop a hidden vmholder field. Marked as reviewed by jsjolen (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27209#pullrequestreview-3229698749 From iwalulya at openjdk.org Tue Sep 16 12:35:38 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 16 Sep 2025 12:35:38 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v5] In-Reply-To: References: Message-ID: > Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. > > Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. > > Testing: Tier 1-7 Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - Revert - Thomas Review - return on timeout - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - timed wait - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - space - remove debug logs - remove debug logs - ... and 2 more: https://git.openjdk.org/jdk/compare/35dc4349...edad0efe ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27190/files - new: https://git.openjdk.org/jdk/pull/27190/files/2ebff06c..edad0efe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=03-04 Stats: 4639 lines in 131 files changed: 3502 ins; 611 del; 526 mod Patch: https://git.openjdk.org/jdk/pull/27190.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27190/head:pull/27190 PR: https://git.openjdk.org/jdk/pull/27190 From epeter at openjdk.org Tue Sep 16 12:56:23 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 16 Sep 2025 12:56:23 GMT Subject: RFR: 8367694: Fix jtreg test failure when Intel APX is enabled for KNL platforms [v2] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 20:08:10 GMT, Srinivas Vamsi Parasa wrote: >> This goal of this PR is fix the jtreg test failure observed in compiler test: `test/hotspot/jtreg/compiler/loopopts/superword/TestDependencyOffsets.java` >> >> The test failure is occurring specifically for the tests with ids = {avx512-v064-A, avx512-v064-U, avx512-v032-A, avx512-v032-U}. These tests are run with KNL hardware features enabled (`-XX:+UseKNLSetting`). >> >> The two main causes of test failure are: >> 1. KNL does not support Intel APX. Currently, APX is not turned off when using KNL. This PR fixes this issue. >> 2. BMI2 instructions like sarxl are encoded incorrectly with `uses_vl=true` (use vector length). This PR fixes the encoding to use the correct one:`uses_vl=false`. >> >> After fixing these two bugs, `TestDependencyOffsets.java` is passing using the SDE emulator when APX is enabled. > > Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: > > change the location of APX feature check Tests passed, looks reasonable. Thanks for the work! ------------- Marked as reviewed by epeter (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27299#pullrequestreview-3229857726 From jsjolen at openjdk.org Tue Sep 16 13:15:22 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 16 Sep 2025 13:15:22 GMT Subject: RFR: 8367249: [REDO] MemBaseline accesses VMT without using lock [v4] In-Reply-To: References: Message-ID: <3LJv6uBo_fW8pT1XQ8oGE1XxeGXWhydeXVNphMU77EY=.300798d2-4f61-48a7-a4de-ea1cdb192afd@github.com> On Tue, 9 Sep 2025 11:59:11 GMT, Afshin Zafari wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> const-ify a bit > > LGTM. Thanks! @afshin-zafari , I fixed another couple of bugs. Now I've gone through all of the `VMT::Instance` matches with grep and there seems to be no more issues. linux-x64-static is still reporting an entirely empty Virtual memory map in NMT :-). Who knows why. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27170#issuecomment-3298709777 From stefank at openjdk.org Tue Sep 16 13:25:05 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 16 Sep 2025 13:25:05 GMT Subject: RFR: 8365606: Container code should not be using jlong/julong In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 17:24:58 GMT, Severin Gehwolf wrote: > Please review this refactoring to the container code in Hotspot to no longer use `jlong` and `julong`. Instead this patch proposes to move to `size_t` and `ssize_t` types. In a similar manner as was done with the `os::xxx` APIs in [JDK-8357086](https://bugs.openjdk.org/browse/JDK-8357086). With this patch the use of `OSCONTAINER_ERROR` (`-2`) is largely gone. It's not terribly useful to have to warrant the many special cases throughout the code. > > In this patch failure handling is being done by returning a boolean for success/failure of reading a value from the interface files. The notion of "not supported" is being folded into `-1` (unlimited for limit values, not supported for usage values). Note that the code already treated `-1` and `-2` similarly. The few cases where `-2` was actually used was in `VM.info` output or `hserr` files. Where `-2` was being treated as "not supported". However, file-reading errors would also fall into the `-2` bucket making the "not supported" case not 100% distinguishable either. The simplification here proposes to do away with `-2` (other than in traces) and fold it into the `-1` (unlimited) bucket as that's how the code has been handling those values (even prior to this patch). > > Testing: > - [x] GHA (tier1) > - [x] cgroup gtests and hotspot container tests on cgroup v1 and cgroup v2 (no regressions noted). > > Thoughts? FYI, I've realized that the change in JDK-8357086 to use a size_t to represent the amount of physical memory is problematic for 32-bit JVMs running on 64-bit OSes (or if physical address extensions are used on 32-bit OSes). I've created JDK-8367485 for that issue. We might want to figure out the path forward with that issue before going too far with this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27125#issuecomment-3283906424 From ysuenaga at openjdk.org Tue Sep 16 13:25:44 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 16 Sep 2025 13:25:44 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU [v2] In-Reply-To: References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> Message-ID: On Tue, 9 Sep 2025 11:32:20 GMT, Erik Gahlin wrote: >>> you might want to check the event in JMC just to be sure. >> >> I checked the flight record, but JMC 9.1 showed raw min_jlong value. I think it is a problem on JMC. >> >> image >> >> >>> Problem might be the API, e.g. int cores = event.getInt("cores") or Integer cores = event.getValue("cores"). >> >> I hope the problem would be found by jdk_jfr tests - it passed on both GHA and my Linux box. > >> I checked the flight record, but JMC 9.1 showed raw min_jlong value. I think it is a problem on JMC. > > Interesting, it has worked in the past. > >> I hope the problem would be found by jdk_jfr tests > > Try to add: > > + event.getInt("cores"); > + Integer value = event.getValue("cores"); > > to TestCPUInformation.java. There's no need to check in the changes, but it would be good to know what happens if it is a long value. @egahlin Could you review? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3296425149 From duke at openjdk.org Tue Sep 16 14:06:44 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 16 Sep 2025 14:06:44 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v5] In-Reply-To: References: <37fyY6jq5j6CdWbBJQK94mkR70ik6oINWLiAR6nPY90=.dd5f6d7c-8a02-46f1-99db-bfb3500772fb@github.com> Message-ID: On Tue, 16 Sep 2025 12:14:28 GMT, Ivan Walulya wrote: >> src/hotspot/share/memory/universe.cpp line 1347: >> >>> 1345: >>> 1346: void Universe::before_exit() { >>> 1347: log_cpu_time(); >> >> Why did you move `log_cpu_time()`? During the review of CPUTimeUsage refactor (https://github.com/openjdk/jdk/pull/26621) we discussed this choice. Given that it still includes more than just GC I think it should stay in `Universe`. Also the PR title does not reflect that it would include a refactor of CPUTimeUsage. > > Main reason was to have the `log_cpu_time` and `AtomicAccess::release_store(&_is_shutting_down, true)` under same critical section. Otherwise, we have no guarantee that we don't continue GCs after `log_cpu_time`. I had put `log_cpu_time` right before calling `stop()`. The `stop()` is the method that terminates GC threads, so no synchronization should be needed if I'm not mistaken. Please correct me if you think I got it wrong here. Nevertheless, any user of `gc_threads_do` might still iterate over terminated GC workers thread. Could we consider adding a check or assert in that method? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2352630393 From epeter at openjdk.org Tue Sep 16 14:41:14 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 16 Sep 2025 14:41:14 GMT Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays [v5] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 16:19:33 GMT, Vladimir Ivanov wrote: >> On the SRF platform for runs with intrinsic scores for the ArrayFill test reports ~2x drop for several sizes due to a lot of the 'MEM_UOPS_RETIRED.SPLIT_STORES' events. The 'good' case for the ArraysFill.testCharFill with size=8195 reports numbers like >> MEM_UOPS_RETIRED.SPLIT_LOADS | 22.6711 >> MEM_UOPS_RETIRED.SPLIT_STORES | 4.0859 >> while for 'bad' case these metrics are >> MEM_UOPS_RETIRED.SPLIT_LOADS | 69.1785 >> MEM_UOPS_RETIRED.SPLIT_STORES | 259200.3659 >> >> With alignment on the cache size no score drops due to split_stores but small reduction may be reported due to extra >> SRF 6740E | Size | orig | pathed | pO/orig >> -- | -- | -- | -- | -- >> ArraysFill.testByteFill | 16 | 152031.2 | 157001.2 | 1.03 >> ArraysFill.testByteFill | 31 | 125795.9 | 177399.2 | 1.41 >> ArraysFill.testByteFill | 250 | 57961.69 | 120981.9 | 2.09 >> ArraysFill.testByteFill | 266 | 44900.15 | 147893.8 | 3.29 >> ArraysFill.testByteFill | 511 | 61908.17 | 129830.1 | 2.10 >> ArraysFill.testByteFill | 2047 | 32255.51 | 41986.6 | 1.30 >> ArraysFill.testByteFill | 2048 | 31928.97 | 42154.3 | 1.32 >> ArraysFill.testByteFill | 8195 | 10690.15 | 11036.3 | 1.03 >> ArraysFill.testIntFill | 16 | 145030.7 | 318796.9 | 2.20 >> ArraysFill.testIntFill | 31 | 134138.4 | 212487 | 1.58 >> ArraysFill.testIntFill | 250 | 74179.23 | 79522.66 | 1.07 >> ArraysFill.testIntFill | 266 | 68112.72 | 60116.49 | 0.88 >> ArraysFill.testIntFill | 511 | 39693.28 | 36225.09 | 0.91 >> ArraysFill.testIntFill | 2047 | 11504.14 | 10616.91 | 0.92 >> ArraysFill.testIntFill | 2048 | 11244.71 | 10969.14 | 0.98 >> ArraysFill.testIntFill | 8195 | 2751.289 | 2692.216 | 0.98 >> ArraysFill.testLongFill | 16 | 212532.5 | 212526 | 1.00 >> ArraysFill.testLongFill | 31 | 137432.4 | 137283.3 | 1.00 >> ArraysFill.testLongFill | 250 | 43185 | 43159.78 | 1.00 >> ArraysFill.testLongFill | 266 | 42172.22 | 42170.5 | 1.00 >> ArraysFill.testLongFill | 511 | 23370.15 | 23370.86 | 1.00 >> ArraysFill.testLongFill | 2047 | 6123.008 | 6122.73 | 1.00 >> ArraysFill.testLongFill | 2048 | 5793.722 | 5792.855 | 1.00 >> ArraysFill.testLongFill | 8195 | 616.552 | 616.585 | 1.00 >> ArraysFill.testShortFill | 16 | 152088.6 | 265646.1 | 1.75 >> ArraysFill.testShortFill | 31 | 137369.8 | 185596.4 | 1.35 >> ArraysFill.testShortFill | 250 | 58872.03 | 99621.15 | 1.69 >> ArraysFill.testShortFill | 266 | 91085.31 | 93746.62 | 1.03 >> ArraysFill.testShortFill | 511 | 65331.96 | 78003.83 | 1.19 >> ArraysFill.testShortFill | 2047 | 21716.32 | 21216.81 | 0.98 >> ArraysFill.testShortFill... > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays FYI, I'm working on a benchmark that accounts for alignment over here: https://github.com/openjdk/jdk/pull/27315 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26747#issuecomment-3299083741 From iwalulya at openjdk.org Tue Sep 16 14:46:43 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 16 Sep 2025 14:46:43 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v5] In-Reply-To: References: <37fyY6jq5j6CdWbBJQK94mkR70ik6oINWLiAR6nPY90=.dd5f6d7c-8a02-46f1-99db-bfb3500772fb@github.com> Message-ID: On Tue, 16 Sep 2025 14:03:28 GMT, Jonas Norlinder wrote: >> Main reason was to have the `log_cpu_time` and `AtomicAccess::release_store(&_is_shutting_down, true)` under same critical section. Otherwise, we have no guarantee that we don't continue GCs after `log_cpu_time`. > > I had put `log_cpu_time` right before calling `stop()`. The `stop()` is the method that terminates GC threads, so no synchronization should be needed if I'm not mistaken. > > Please correct me if you think I got it wrong here. > > Nevertheless, any user of `gc_threads_do` might still iterate over terminated GC workers thread. Could we consider adding a check or assert in that method? We can have GCs between `log_cpu_time` and `stop()`. This reduces chances of that happening if we have `log_cpu_time` under same lock as setting `_is_shutting_down`. > Nevertheless, any user of gc_threads_do might still iterate over terminated GC workers thread. Could we consider adding a check or assert in that method? Yes, we can have the assert in `gc_threads_do`, I thought this was going to be done as a follow up. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2352757631 From liach at openjdk.org Tue Sep 16 15:01:24 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 Sep 2025 15:01:24 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary [v2] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 09:35:02 GMT, Paul H?bner wrote: >> Hi all, >> >> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: >> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases), >> 2) removes `FilteredJavaFieldStream` entirely, and >> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. >> >> Testing: Oracle tiers 1-3. > > Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'master' into JDK-8365858 > - Merge branch 'master' into JDK-8365858 > - Fix typo. > - Refactor to purely use injected fields. > - Remove FilteredJavaFieldStream and usages. > - Remove constantPoolOop from Java code. > - Make constantPoolOop a hidden vmholder field. Still looks good ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27209#pullrequestreview-3230428037 From asmehra at openjdk.org Tue Sep 16 15:20:55 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 16 Sep 2025 15:20:55 GMT Subject: RFR: 8367532: Declare all stubgen stub entries including internal cross-stub entries In-Reply-To: References: Message-ID: <0UbRC9KMslpAIK7Y0lMfVmr1JmhXvmRFek4PmRWoG9E=.55aecbe7-21ad-42f9-a2ad-cc2380a354b2@github.com> On Thu, 11 Sep 2025 15:13:07 GMT, Andrew Dinn wrote: > This PR adds declarations for internal entries used to daisy chain memory copy stubs and ensures they are saved to generated fields when produced and accessed via those fields when consumed. This will ensure they are saved and restored correctly when stubgen blobs are included in the AOT Code Cache. > > The PR also fixes a few AArch64 stubs which do not currently have their first entry at offset 0, another thing that will be needed to simplify AOT Code cache save and restore. x86 and aarch64 changes look fine to me. ------------- Marked as reviewed by asmehra (Committer). PR Review: https://git.openjdk.org/jdk/pull/27228#pullrequestreview-3230511707 From coleenp at openjdk.org Tue Sep 16 16:00:22 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 16 Sep 2025 16:00:22 GMT Subject: RFR: 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition() In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 02:44:26 GMT, Ioi Lam wrote: > Simplify the boilerplate code in jvm.cpp that calls `JvmtiThreadState::class_to_verify_considering_redefinition()`, and reduce the number of `InstanceKlass::cast()` calls. > > I also changed a few fields/arguments from `Klass*` to `InstanceKlass*` as these are used exclusively with `InstanceKlass*`. This looks good pending David's and my suggested changes (hope it works). I sort of think there's no need for the Klass* version of get_class_considering_redefinition since its callers seem to really want an InstanceKlass. Since it's jvm.cpp, you can probably verify that it's never Klass in these callers. src/hotspot/share/prims/jvm.cpp line 2265: > 2263: inline Klass* get_klass_considering_redefinition(jclass cls, JavaThread *thread) { > 2264: Klass* k = java_lang_Class::as_Klass(JNIHandles::resolve_non_null(cls)); > 2265: k = JvmtiThreadState::class_to_verify_considering_redefinition(k, thread); Suggestion: return JvmtiThreadState::class_to_verify_considering_redefinition(k, thread); src/hotspot/share/prims/jvm.cpp line 2266: > 2264: Klass* k = java_lang_Class::as_Klass(JNIHandles::resolve_non_null(cls)); > 2265: k = JvmtiThreadState::class_to_verify_considering_redefinition(k, thread); > 2266: return k; Suggestion: src/hotspot/share/prims/jvm.cpp line 2271: > 2269: inline InstanceKlass* get_instance_klass_considering_redefinition(jclass cls, JavaThread *thread) { > 2270: InstanceKlass* ik = java_lang_Class::as_InstanceKlass(JNIHandles::resolve_non_null(cls)); > 2271: ik = JvmtiThreadState::class_to_verify_considering_redefinition(ik, thread); Suggestion: return JvmtiThreadState::class_to_verify_considering_redefinition(ik, thread); src/hotspot/share/prims/jvm.cpp line 2272: > 2270: InstanceKlass* ik = java_lang_Class::as_InstanceKlass(JNIHandles::resolve_non_null(cls)); > 2271: ik = JvmtiThreadState::class_to_verify_considering_redefinition(ik, thread); > 2272: return ik; Suggestion: src/hotspot/share/prims/jvm.cpp line 2291: > 2289: > 2290: JVM_ENTRY(const char*, JVM_GetClassNameUTF(JNIEnv *env, jclass cls)) > 2291: Klass* k = get_klass_considering_redefinition(cls, thread); Even if it's a redefined class, it'll have the same name so this isn't necessary. ------------- PR Review: https://git.openjdk.org/jdk/pull/27303#pullrequestreview-3230659598 PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2352957988 PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2352958544 PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2352959692 PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2352960240 PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2352970204 From lmesnik at openjdk.org Tue Sep 16 16:04:56 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 16 Sep 2025 16:04:56 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked Message-ID: The `SuspendResumeManager::suspend(bool register_vthread_SR)` has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. The fix added some "asymmetry" in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart. ------------- Commit messages: - 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked Changes: https://git.openjdk.org/jdk/pull/27317/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27317&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367725 Stats: 50 lines in 5 files changed: 36 ins; 8 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27317/head:pull/27317 PR: https://git.openjdk.org/jdk/pull/27317 From phubner at openjdk.org Tue Sep 16 16:19:13 2025 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Tue, 16 Sep 2025 16:19:13 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary [v2] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 09:35:02 GMT, Paul H?bner wrote: >> Hi all, >> >> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: >> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases), >> 2) removes `FilteredJavaFieldStream` entirely, and >> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. >> >> Testing: Oracle tiers 1-3. > > Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'master' into JDK-8365858 > - Merge branch 'master' into JDK-8365858 > - Fix typo. > - Refactor to purely use injected fields. > - Remove FilteredJavaFieldStream and usages. > - Remove constantPoolOop from Java code. > - Make constantPoolOop a hidden vmholder field. Thanks for the reviews everyone. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3299475347 From duke at openjdk.org Tue Sep 16 16:22:21 2025 From: duke at openjdk.org (duke) Date: Tue, 16 Sep 2025 16:22:21 GMT Subject: RFR: 8365858: FilteredJavaFieldStream is unnecessary [v2] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 09:35:02 GMT, Paul H?bner wrote: >> Hi all, >> >> `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: >> 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases), >> 2) removes `FilteredJavaFieldStream` entirely, and >> 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. >> >> Testing: Oracle tiers 1-3. > > Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'master' into JDK-8365858 > - Merge branch 'master' into JDK-8365858 > - Fix typo. > - Refactor to purely use injected fields. > - Remove FilteredJavaFieldStream and usages. > - Remove constantPoolOop from Java code. > - Make constantPoolOop a hidden vmholder field. @Arraying Your change (at version 54bc0476fe86c9b1759fff8c0062069ff3e536fa) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27209#issuecomment-3299484854 From azafari at openjdk.org Tue Sep 16 16:26:20 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 16 Sep 2025 16:26:20 GMT Subject: RFR: 8367249: [REDO] MemBaseline accesses VMT without using lock [v4] In-Reply-To: <3LJv6uBo_fW8pT1XQ8oGE1XxeGXWhydeXVNphMU77EY=.300798d2-4f61-48a7-a4de-ea1cdb192afd@github.com> References: <3LJv6uBo_fW8pT1XQ8oGE1XxeGXWhydeXVNphMU77EY=.300798d2-4f61-48a7-a4de-ea1cdb192afd@github.com> Message-ID: On Tue, 16 Sep 2025 13:11:37 GMT, Johan Sj?len wrote: > there seems to be no more issues. The `VMT::find_reserved_region(address p)` (and the other methods that traversing the tree) also should be used within the NMT lock as well. Should we do them here in this PR or a separate one? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27170#issuecomment-3299498443 From fandreuzzi at openjdk.org Tue Sep 16 16:47:30 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Tue, 16 Sep 2025 16:47:30 GMT Subject: RFR: 8367689: Revert removal of several compilation-related vmStructs fields Message-ID: #23782 ([JDK-8315488](https://bugs.openjdk.org/browse/JDK-8315488)) removed several vmStructs fields. A small subset was used in Async-Profiler: CiEnv* _env CompileTask* _task ciMethod* _method I propose a small patch to bring them back. It helps third-party tools in building useful features on the JDK. For example, Async-Profiler uses these fields to display the current method being compiled in a compiler thread. ------------- Commit messages: - ops - remove indent - bring back fields Changes: https://git.openjdk.org/jdk/pull/27318/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27318&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367689 Stats: 108 lines in 15 files changed: 68 ins; 0 del; 40 mod Patch: https://git.openjdk.org/jdk/pull/27318.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27318/head:pull/27318 PR: https://git.openjdk.org/jdk/pull/27318 From iklam at openjdk.org Tue Sep 16 17:27:20 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Sep 2025 17:27:20 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v3] In-Reply-To: References: Message-ID: > This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. > > This PR annotates a single class, `jdk.internal.math.MathUtils` (also the object hierarchy root class, `Object.class`, which has no associated AOT initialization but is required for completeness). More classes will be added in future PRs. > > If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to > - All of `K`'s super classes > - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` > > Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). > > This annotation is awfully similar to `@AOTSafeClassInitializer`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Added comment about the order of FinalImageRecipes::apply_recipes() vs link_all_loaded_classes() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27024/files - new: https://git.openjdk.org/jdk/pull/27024/files/b1ef47dc..15798558 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27024&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27024&range=01-02 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27024.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27024/head:pull/27024 PR: https://git.openjdk.org/jdk/pull/27024 From iklam at openjdk.org Tue Sep 16 17:27:22 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Sep 2025 17:27:22 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v2] In-Reply-To: References: Message-ID: <57rG7_WaUKuvGF296n4V3HUC-tcnnnmLDxs77d1VhqY=.02396658-ea80-481a-a76f-994b8519aa6e@github.com> On Mon, 15 Sep 2025 23:20:47 GMT, Ioi Lam wrote: >> This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. >> >> This PR annotates a single class, `jdk.internal.math.MathUtils` (also the object hierarchy root class, `Object.class`, which has no associated AOT initialization but is required for completeness). More classes will be added in future PRs. >> >> If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to >> - All of `K`'s super classes >> - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` >> >> Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). >> >> This annotation is awfully similar to `@AOTSafeClassInitializer`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Exclude more GC heap size tests as AOT cache size has increased for "make test JTREG=AOT_JDK=onestep ..." > Just for clarity you might want to update the PR description to state that this PR "annotates a single aot initializable class, jdk.internal.math.MathUtils (also the object hierarchy root class, Object.class, which has no associated aot initialization but is required for completeness)". More classes will be added in future PRs. > Also, the PR description refers to @AOTSafeAnnotation -- do you mean @AOTSafeClassInitializer? I updated the PR description as suggested. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27024#issuecomment-3299677921 From iklam at openjdk.org Tue Sep 16 17:40:48 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Sep 2025 17:40:48 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v4] In-Reply-To: References: Message-ID: > This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. > > This PR annotates a single class, `jdk.internal.math.MathUtils` (also the object hierarchy root class, `Object.class`, which has no associated AOT initialization but is required for completeness). More classes will be added in future PRs. > > If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to > - All of `K`'s super classes > - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` > > Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). > > This annotation is awfully similar to `@AOTSafeClassInitializer`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Added logging about @AOTSafeClassInitializer classes that have not been initialized ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27024/files - new: https://git.openjdk.org/jdk/pull/27024/files/15798558..24b52a49 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27024&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27024&range=02-03 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27024.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27024/head:pull/27024 PR: https://git.openjdk.org/jdk/pull/27024 From iklam at openjdk.org Tue Sep 16 17:50:09 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Sep 2025 17:50:09 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v4] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 17:40:48 GMT, Ioi Lam wrote: >> This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. >> >> This PR annotates a single class, `jdk.internal.math.MathUtils` (also the object hierarchy root class, `Object.class`, which has no associated AOT initialization but is required for completeness). More classes will be added in future PRs. >> >> If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to >> - All of `K`'s super classes >> - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` >> >> Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). >> >> This annotation is awfully similar to `@AOTSafeClassInitializer`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Added logging about @AOTSafeClassInitializer classes that have not been initialized > > This annotation is awfully similar to @AOTSafeClassInitializer, and I am not sure if we need both > > Maybe we do want both. @AOTSafeClassInitializer is weaker than @AOTInitialize because the former only initializes classes optionally when we find it is needed. If we only had @AOTInitialize then we would lose that optionality. It may not make much difference now -- we probably only have these annotations for JDK classes that would need to be class-inited whatever the training regime. However, as we expand use of the annotation might we risk initing classes and including their state in the archive without necessarily seeing any benefit? Yes, I think we can experiment with having both annotations for now. I added logging and found: java.util.stream.Collectors is annotated with @AOTSafeClassInitializer but has not been initialized java.lang.invoke.BoundMethodHandle$Species_LLL is annotated with @AOTSafeClassInitializer but has not been initialized java.lang.invoke.BoundMethodHandle$Species_D is annotated with @AOTSafeClassInitializer but has not been initialized java.lang.invoke.BoundMethodHandle$Species_I is annotated with @AOTSafeClassInitializer but has not been initialized java.lang.invoke.BoundMethodHandle$Species_LLLLL is annotated with @AOTSafeClassInitializer but has not been initialized java.lang.invoke.BoundMethodHandle$Species_DL is annotated with @AOTSafeClassInitializer but has not been initialized java.lang.invoke.BoundMethodHandle$Species_LLLL is annotated with @AOTSafeClassInitializer but has not been initialized java.lang.invoke.BoundMethodHandle$Species_IL is annotated with @AOTSafeClassInitializer but has not been initialized java.lang.invoke.VarHandleGuards is annotated with @AOTSafeClassInitializer but has not been initialized So I think the rules for choosing the annotations for class `C` is: - If it's certain that AOT-initialization of `C` is safe and beneficial (considering space/speed tradeoffs), use `@AOTInitialize` - If it's certain that AOT-initialization of `C` is safe, and it's necessary to preserve the effect of `C.` for correctness, use `@AOTSafeClassInitializer` We might prefer `@AOTSafeClassInitializer` if `C.` executes quickly (so there's no start-up benefit for AOT-initialization) but would produce a large amount of data that would increase the footprint of the AOT cache. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27024#issuecomment-3299749941 From iklam at openjdk.org Tue Sep 16 17:50:12 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Sep 2025 17:50:12 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v2] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 09:25:21 GMT, Andrew Dinn wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Exclude more GC heap size tests as AOT cache size has increased for "make test JTREG=AOT_JDK=onestep ..." > > src/hotspot/share/cds/aotMetaspace.cpp line 806: > >> 804: AOTClassInitializer::init_test_class(CHECK); >> 805: >> 806: if (CDSConfig::is_dumping_final_static_archive()) { > > What is the reason for moving this earlier to before link_all_loaded_classes? I added comment about the order of this code vs link_all_loaded_classes(). Before switching the order, I found that in some rare cases classes were removed from the AOT cache because they are unlinked after `FinalImageRecipes::apply_recipes()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27024#discussion_r2353226013 From lmesnik at openjdk.org Tue Sep 16 17:57:39 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 16 Sep 2025 17:57:39 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v2] In-Reply-To: References: Message-ID: > The > `SuspendResumeManager::suspend(bool register_vthread_SR)` > has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. > > Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. > > The fix added some "asymmetry" in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: updated test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27317/files - new: https://git.openjdk.org/jdk/pull/27317/files/5d988b31..3b0b2d76 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27317&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27317&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27317/head:pull/27317 PR: https://git.openjdk.org/jdk/pull/27317 From lmesnik at openjdk.org Tue Sep 16 18:08:31 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 16 Sep 2025 18:08:31 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v3] In-Reply-To: References: Message-ID: > The > `SuspendResumeManager::suspend(bool register_vthread_SR)` > has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. > > Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. > > The fix added some "asymmetry" in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: resume tthread ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27317/files - new: https://git.openjdk.org/jdk/pull/27317/files/3b0b2d76..e5743721 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27317&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27317&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27317/head:pull/27317 PR: https://git.openjdk.org/jdk/pull/27317 From sparasa at openjdk.org Tue Sep 16 18:12:36 2025 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Tue, 16 Sep 2025 18:12:36 GMT Subject: RFR: 8367780: Enable UseAPX on Intel CPUs only when both APX_F and APX_NCI_NDD_NF cpuid features are present Message-ID: The goal of this PR is to enable APX on Intel CPUs (i.e. enable UseAPX) only when both the APX_F and APX_NCI_NDD_NF cpuid feature flags are present. As per the latest update to the Intel APX specification (https://www.intel.com/content/www/us/en/content-details/861610/intel-advanced-performance-extensions-intel-apx-architecture-specification.html ), when APX_F is set, processors also provide CPUID leaf 0x29 (APX Advanced Performance Extensions Leaf). Any Intel processor that enumerates APX_F also enumerates APX_NCI_NDD_NF. This PR enhances the HotSpot x86 CPU feature detection to recognize the APX_NCI_NDD_NF sub-feature of Intel APX and update the enabling logic for UseAPX VM flag. ------------- Commit messages: - clean up - 8367780: Enable UseAPX on Intel CPUs only when both APX_F and APX_NCI_NDD_NF cpuid features are present Changes: https://git.openjdk.org/jdk/pull/27320/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27320&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367780 Stats: 40 lines in 4 files changed: 33 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27320.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27320/head:pull/27320 PR: https://git.openjdk.org/jdk/pull/27320 From sparasa at openjdk.org Tue Sep 16 18:13:28 2025 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Tue, 16 Sep 2025 18:13:28 GMT Subject: RFR: 8367694: Fix jtreg test failure when Intel APX is enabled for KNL platforms [v2] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 12:53:37 GMT, Emanuel Peter wrote: > Tests passed, looks reasonable. Thanks for the work! Thanks Emanuel! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27299#issuecomment-3299832880 From sparasa at openjdk.org Tue Sep 16 18:17:52 2025 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Tue, 16 Sep 2025 18:17:52 GMT Subject: Integrated: 8367694: Fix jtreg test failure when Intel APX is enabled for KNL platforms In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 16:19:29 GMT, Srinivas Vamsi Parasa wrote: > This goal of this PR is fix the jtreg test failure observed in compiler test: `test/hotspot/jtreg/compiler/loopopts/superword/TestDependencyOffsets.java` > > The test failure is occurring specifically for the tests with ids = {avx512-v064-A, avx512-v064-U, avx512-v032-A, avx512-v032-U}. These tests are run with KNL hardware features enabled (`-XX:+UseKNLSetting`). > > The two main causes of test failure are: > 1. KNL does not support Intel APX. Currently, APX is not turned off when using KNL. This PR fixes this issue. > 2. BMI2 instructions like sarxl are encoded incorrectly with `uses_vl=true` (use vector length). This PR fixes the encoding to use the correct one:`uses_vl=false`. > > After fixing these two bugs, `TestDependencyOffsets.java` is passing using the SDE emulator when APX is enabled. This pull request has now been integrated. Changeset: e883dec6 Author: Srinivas Vamsi Parasa URL: https://git.openjdk.org/jdk/commit/e883dec6be8cb2fc44e45a6b4677cca2f4df58ef Stats: 34 lines in 2 files changed: 12 ins; 10 del; 12 mod 8367694: Fix jtreg test failure when Intel APX is enabled for KNL platforms Reviewed-by: sviswanathan, epeter ------------- PR: https://git.openjdk.org/jdk/pull/27299 From lmesnik at openjdk.org Tue Sep 16 18:20:13 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 16 Sep 2025 18:20:13 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v4] In-Reply-To: References: Message-ID: > The > `SuspendResumeManager::suspend(bool register_vthread_SR)` > has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. > > Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. > > The fix added some "asymmetry" in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: typo fixed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27317/files - new: https://git.openjdk.org/jdk/pull/27317/files/e5743721..45ff0b72 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27317&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27317&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27317/head:pull/27317 PR: https://git.openjdk.org/jdk/pull/27317 From fandreuzzi at openjdk.org Tue Sep 16 18:56:19 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Tue, 16 Sep 2025 18:56:19 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v4] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 18:20:13 GMT, Leonid Mesnik wrote: >> The >> `SuspendResumeManager::suspend(bool register_vthread_SR)` >> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. >> >> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. >> >> The fix added some "asymmetry" in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > typo fixed src/hotspot/share/runtime/suspendResumeManager.cpp line 92: > 90: if (register_vthread_SR) { > 91: assert(_target->is_vthread_mounted(), "sanity check"); > 92: JvmtiVTSuspender::register_vthread_suspend(id); Suggestion: JvmtiVTSuspender::register_vthread_suspend(id); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2353373334 From wkemper at openjdk.org Tue Sep 16 19:03:02 2025 From: wkemper at openjdk.org (William Kemper) Date: Tue, 16 Sep 2025 19:03:02 GMT Subject: RFR: 8367476: Shenandoah: Remove use of CollectedHeap::_soft_ref_policy [v2] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 14:23:35 GMT, Francesco Andreuzzi wrote: >> Similarly to what was done in #26496 and #26648, the usages of `CollectedHeap::_soft_ref_policy` in Shenandoah can be replaced with an earlier call to `ShenandoahReferenceProcessor::set_soft_reference_policy`. >> >> This is the last usage of `CollectedHeap::_soft_ref_policy`, so it can be removed. >> >> Passes tier1-2, and tier3_gc_shenandoah. > > Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: > > - eagerly initialize to always-clear > - move to gccause Shenandoah parts look good to me. ------------- Marked as reviewed by wkemper (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27239#pullrequestreview-3231296755 From lmesnik at openjdk.org Tue Sep 16 19:11:49 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 16 Sep 2025 19:11:49 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v5] In-Reply-To: References: Message-ID: > The > `SuspendResumeManager::suspend(bool register_vthread_SR)` > has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. > > Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. > > The fix added some "asymmetry" in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: ident fixed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27317/files - new: https://git.openjdk.org/jdk/pull/27317/files/45ff0b72..024ff23f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27317&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27317&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27317/head:pull/27317 PR: https://git.openjdk.org/jdk/pull/27317 From lmesnik at openjdk.org Tue Sep 16 19:11:51 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 16 Sep 2025 19:11:51 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v4] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 18:53:38 GMT, Francesco Andreuzzi wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> typo fixed > > src/hotspot/share/runtime/suspendResumeManager.cpp line 92: > >> 90: if (register_vthread_SR) { >> 91: assert(_target->is_vthread_mounted(), "sanity check"); >> 92: JvmtiVTSuspender::register_vthread_suspend(id); > > Suggestion: > > JvmtiVTSuspender::register_vthread_suspend(id); Thanks! Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2353404354 From sparasa at openjdk.org Tue Sep 16 19:14:12 2025 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Tue, 16 Sep 2025 19:14:12 GMT Subject: RFR: 8367780: Enable UseAPX on Intel CPUs only when both APX_F and APX_NCI_NDD_NF cpuid features are present [v2] In-Reply-To: References: Message-ID: > The goal of this PR is to enable APX on Intel CPUs (i.e. enable UseAPX) only when both the APX_F and APX_NCI_NDD_NF cpuid feature flags are present. > > As per the latest update to the Intel APX specification (https://www.intel.com/content/www/us/en/content-details/861610/intel-advanced-performance-extensions-intel-apx-architecture-specification.html ), when APX_F is set, processors also provide CPUID leaf 0x29 (APX Advanced Performance Extensions Leaf). Any Intel processor that enumerates APX_F also enumerates APX_NCI_NDD_NF. > > This PR enhances the HotSpot x86 CPU feature detection to recognize the APX_NCI_NDD_NF sub-feature of Intel APX and update the enabling logic for UseAPX VM flag. Srinivas Vamsi Parasa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - integrate latest changes - merge master - clean up - 8367780: Enable UseAPX on Intel CPUs only when both APX_F and APX_NCI_NDD_NF cpuid features are present ------------- Changes: https://git.openjdk.org/jdk/pull/27320/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27320&range=01 Stats: 40 lines in 4 files changed: 33 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27320.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27320/head:pull/27320 PR: https://git.openjdk.org/jdk/pull/27320 From pchilanomate at openjdk.org Tue Sep 16 19:15:00 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 16 Sep 2025 19:15:00 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v5] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 19:11:49 GMT, Leonid Mesnik wrote: >> The >> `SuspendResumeManager::suspend(bool register_vthread_SR)` >> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. >> >> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. >> >> The fix added some "asymmetry" in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > ident fixed Thanks for finding and fixing this Leonid. src/hotspot/share/runtime/suspendResumeManager.cpp line 89: > 87: int64_t id = java_lang_Thread::thread_id(_target->vthread()); > 88: ThreadBlockInVM tbivm(current); > 89: MutexLocker ml(_state_lock, Mutex::_no_safepoint_check_flag); Transitioning to the blocked state and acquiring the monitor should still be executed without JVMTI included. We won?t see any issues today because suspend/resume is only used by JVMTI code. src/hotspot/share/runtime/suspendResumeManager.cpp line 105: > 103: // If target is the current thread we can bypass the handshake machinery > 104: // and just suspend directly > 105: self_suspend(register_vthread_SR, self); Since `self_suspend()` is a very short method and only called from here, I would keep the method as it was and if anything define `set_suspended_with_id(int64_t id, bool register_vthread_SR)` instead. ------------- PR Review: https://git.openjdk.org/jdk/pull/27317#pullrequestreview-3231325205 PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2353407110 PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2353410713 From duke at openjdk.org Tue Sep 16 19:17:59 2025 From: duke at openjdk.org (duke) Date: Tue, 16 Sep 2025 19:17:59 GMT Subject: RFR: 8367476: Shenandoah: Remove use of CollectedHeap::_soft_ref_policy [v2] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 14:23:35 GMT, Francesco Andreuzzi wrote: >> Similarly to what was done in #26496 and #26648, the usages of `CollectedHeap::_soft_ref_policy` in Shenandoah can be replaced with an earlier call to `ShenandoahReferenceProcessor::set_soft_reference_policy`. >> >> This is the last usage of `CollectedHeap::_soft_ref_policy`, so it can be removed. >> >> Passes tier1-2, and tier3_gc_shenandoah. > > Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: > > - eagerly initialize to always-clear > - move to gccause @fandreuz Your change (at version a55b8bd21ffa892b7f045bfe0961773855790661) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27239#issuecomment-3300024331 From kvn at openjdk.org Tue Sep 16 19:17:56 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 16 Sep 2025 19:17:56 GMT Subject: RFR: 8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive [v2] In-Reply-To: References: <9tei5T4Ox7c_zVMGBsROyJTxsdRjKAXDQTOPo3d62sM=.b2331cfb-b759-4552-9a79-6cd0c71097cb@github.com> Message-ID: <0mcWOte-iIlkryKC4UlENZxN2zZvnknukcOMS7CKLEQ=.3abf7c16-b4e4-4424-aebe-860a6e06edaf@github.com> On Tue, 16 Sep 2025 02:38:25 GMT, Ioi Lam wrote: > The default value of AOTClassLinking is false, so if we come here, it must have been set in the command-line. I added an assert (so our ERGO code doesn't set it by mistake). Here AOTClassLinking is set and checked in `check_vm_args_consistency()` https://github.com/openjdk/leyden/blob/master/src/hotspot/share/cds/cdsConfig.cpp#L636 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27242#discussion_r2353419057 From fandreuzzi at openjdk.org Tue Sep 16 19:17:58 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Tue, 16 Sep 2025 19:17:58 GMT Subject: RFR: 8367476: Shenandoah: Remove use of CollectedHeap::_soft_ref_policy [v2] In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 15:18:20 GMT, Albert Mingkun Yang wrote: >> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: >> >> - eagerly initialize to always-clear >> - move to gccause > > I have reviewed all non-Shenandoah code. Thanks for your review @albertnetymk and @earthling-amzn. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27239#issuecomment-3300021618 From phubner at openjdk.org Tue Sep 16 19:20:57 2025 From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=) Date: Tue, 16 Sep 2025 19:20:57 GMT Subject: Integrated: 8365858: FilteredJavaFieldStream is unnecessary In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 08:35:05 GMT, Paul H?bner wrote: > Hi all, > > `FilteredJavaFieldStream` purely exists to hide the field `constantPoolOop` in `jdk.internal.reflect.ConstantPool`. This PR: > 1) refactors `constantPoolOop` to be a hidden VM injected field `vmholder` (name to be consistent with other similar cases), > 2) removes `FilteredJavaFieldStream` entirely, and > 3) updates code previously relying on `FilteredJavaFieldStream` to use `JavaFieldStream` instead. > > Testing: Oracle tiers 1-3. This pull request has now been integrated. Changeset: b75e35cb Author: Paul H?bner Committer: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/b75e35cb94d17a742d88f23dfd1b016c26a5e63c Stats: 194 lines in 9 files changed: 9 ins; 166 del; 19 mod 8365858: FilteredJavaFieldStream is unnecessary Reviewed-by: liach, jsjolen, coleenp, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/27209 From sparasa at openjdk.org Tue Sep 16 19:21:28 2025 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Tue, 16 Sep 2025 19:21:28 GMT Subject: RFR: 8367780: Enable UseAPX on Intel CPUs only when both APX_F and APX_NCI_NDD_NF cpuid features are present [v3] In-Reply-To: References: Message-ID: > The goal of this PR is to enable APX on Intel CPUs (i.e. enable UseAPX) only when both the APX_F and APX_NCI_NDD_NF cpuid feature flags are present. > > As per the latest update to the Intel APX specification (https://www.intel.com/content/www/us/en/content-details/861610/intel-advanced-performance-extensions-intel-apx-architecture-specification.html ), when APX_F is set, processors also provide CPUID leaf 0x29 (APX Advanced Performance Extensions Leaf). Any Intel processor that enumerates APX_F also enumerates APX_NCI_NDD_NF. > > This PR enhances the HotSpot x86 CPU feature detection to recognize the APX_NCI_NDD_NF sub-feature of Intel APX and update the enabling logic for UseAPX VM flag. Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: update KNL check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27320/files - new: https://git.openjdk.org/jdk/pull/27320/files/87e96cca..21560d0b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27320&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27320&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27320.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27320/head:pull/27320 PR: https://git.openjdk.org/jdk/pull/27320 From kvn at openjdk.org Tue Sep 16 19:23:39 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 16 Sep 2025 19:23:39 GMT Subject: RFR: 8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive [v2] In-Reply-To: <0mcWOte-iIlkryKC4UlENZxN2zZvnknukcOMS7CKLEQ=.3abf7c16-b4e4-4424-aebe-860a6e06edaf@github.com> References: <9tei5T4Ox7c_zVMGBsROyJTxsdRjKAXDQTOPo3d62sM=.b2331cfb-b759-4552-9a79-6cd0c71097cb@github.com> <0mcWOte-iIlkryKC4UlENZxN2zZvnknukcOMS7CKLEQ=.3abf7c16-b4e4-4424-aebe-860a6e06edaf@github.com> Message-ID: <0nsyTQlQ9o7jjgwUTRWImOL_0g08xiJhGYKm4M_tRgc=.1dca7305-0ba1-405c-b9e4-6c2668a6debd@github.com> On Tue, 16 Sep 2025 19:15:39 GMT, Vladimir Kozlov wrote: >>> An other thing. I think you need to issue warning only if `AOTClassLinking` is set on command line. >> >> The default value of `AOTClassLinking` is false, so if we come here, it must have been set in the command-line. I added an assert (so our ERGO code doesn't set it by mistake). >> >>> Also what about AOTMode and other AOT flags? setup_compiler_args() are set in check_vm_args_consistency() >> >> AOTMode/AOTConfiguration/AOTCache/AOTCacheOutput needs to be checked in `check_vm_args_consistency()` -> `check_aot_flags()`. If these flags are inconsistent, the JVM will exit. I think the ergo setting of these flags should also be there as well. >> >> The settings of optimization levels, including all the settings in `setup_compiler_args()`, should be moved to `CDSConfig::ergo_initialize()`. If we see any inconsistent settings, they should be correct with `FLAG_SET_ERGO()` (and we don't exit the VM). > >> The default value of AOTClassLinking is false, so if we come here, it must have been set in the command-line. I added an assert (so our ERGO code doesn't set it by mistake). > > Here AOTClassLinking is set and checked in `check_vm_args_consistency()` > https://github.com/openjdk/leyden/blob/master/src/hotspot/share/cds/cdsConfig.cpp#L636 > The settings of optimization levels, including all the settings in setup_compiler_args(), should be moved to CDSConfig::ergo_initialize(). If we see any inconsistent settings, they should be correct with FLAG_SET_ERGO() (and we don't exit the VM). Agree. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27242#discussion_r2353434814 From lmesnik at openjdk.org Tue Sep 16 19:41:29 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 16 Sep 2025 19:41:29 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v6] In-Reply-To: References: Message-ID: > The > `SuspendResumeManager::suspend(bool register_vthread_SR)` > has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. > > Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. > > The fix added some "asymmetry" in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: refactoring ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27317/files - new: https://git.openjdk.org/jdk/pull/27317/files/024ff23f..0aa24558 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27317&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27317&range=04-05 Stats: 31 lines in 2 files changed: 11 ins; 18 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27317/head:pull/27317 PR: https://git.openjdk.org/jdk/pull/27317 From iklam at openjdk.org Tue Sep 16 19:48:04 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Sep 2025 19:48:04 GMT Subject: RFR: 8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive [v2] In-Reply-To: <0nsyTQlQ9o7jjgwUTRWImOL_0g08xiJhGYKm4M_tRgc=.1dca7305-0ba1-405c-b9e4-6c2668a6debd@github.com> References: <9tei5T4Ox7c_zVMGBsROyJTxsdRjKAXDQTOPo3d62sM=.b2331cfb-b759-4552-9a79-6cd0c71097cb@github.com> <0mcWOte-iIlkryKC4UlENZxN2zZvnknukcOMS7CKLEQ=.3abf7c16-b4e4-4424-aebe-860a6e06edaf@github.com> <0nsyTQlQ9o7jjgwUTRWImOL_0g08xiJhGYKm4M_tRgc=.1dca7305-0ba1-405c-b9e4-6c2668a6debd@github.com> Message-ID: <_9nNxBwVLnPtzYDje1iXrVblRea4dLB45_x_uhkj_sc=.daaf7b91-de9f-4a2b-8e23-1797118c5767@github.com> On Tue, 16 Sep 2025 19:21:27 GMT, Vladimir Kozlov wrote: >>> The default value of AOTClassLinking is false, so if we come here, it must have been set in the command-line. I added an assert (so our ERGO code doesn't set it by mistake). >> >> Here AOTClassLinking is set and checked in `check_vm_args_consistency()` >> https://github.com/openjdk/leyden/blob/master/src/hotspot/share/cds/cdsConfig.cpp#L636 > >> The settings of optimization levels, including all the settings in setup_compiler_args(), should be moved to CDSConfig::ergo_initialize(). If we see any inconsistent settings, they should be correct with FLAG_SET_ERGO() (and we don't exit the VM). > > Agree. > Here AOTClassLinking is set and checked in check_vm_args_consistency() https://github.com/openjdk/leyden/blob/master/src/hotspot/share/cds/cdsConfig.cpp#L636 Hmm, for convoluted cases like this, we will actually turn on AOTClassLinking ergomomically for dynamic dump java -XX:ArchiveClassesAtExit=foo.jsa -cp HelloWorld.jar -XX:AOTMode=on -XX:AOTCache=hw.aot HelloWorld I've removed the assert and print the warning only if `FLAG_IS_CMDLINE(AOTClassLinking)` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27242#discussion_r2353496710 From iklam at openjdk.org Tue Sep 16 19:48:02 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Sep 2025 19:48:02 GMT Subject: RFR: 8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive [v4] In-Reply-To: References: Message-ID: > Support of `-XX:+AOTClassLinking` for dynamic CDS archive is not an documented feature of [JEP 483](https://openjdk.org/jeps/483). It has very small performance benefit and complicates the development of future AOT optimizations. > > After this PR, `-XX:+AOTClassLinking` will have no effect when creating a dynamic CDS archive. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @vnkozlov review -- print warning only if -XX:+AOTClassLinking is set in command-line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27242/files - new: https://git.openjdk.org/jdk/pull/27242/files/0ff6fd44..f9c7f9a6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27242&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27242&range=02-03 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27242.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27242/head:pull/27242 PR: https://git.openjdk.org/jdk/pull/27242 From lmesnik at openjdk.org Tue Sep 16 19:49:19 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 16 Sep 2025 19:49:19 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v7] In-Reply-To: References: Message-ID: <9RYDDTZCCNmLgKRAMyzYIFopSIsm5_zy7S9b_C2YsEc=.39e4bb27-655b-4983-a549-4e050cde6188@github.com> > The > `SuspendResumeManager::suspend(bool register_vthread_SR)` > has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. > > Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. > > The fix added some "asymmetry" in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: moved to another method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27317/files - new: https://git.openjdk.org/jdk/pull/27317/files/0aa24558..d80d7cf4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27317&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27317&range=05-06 Stats: 18 lines in 2 files changed: 11 ins; 6 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27317/head:pull/27317 PR: https://git.openjdk.org/jdk/pull/27317 From lmesnik at openjdk.org Tue Sep 16 19:50:38 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 16 Sep 2025 19:50:38 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v5] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 19:12:09 GMT, Patricio Chilano Mateo wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> ident fixed > > src/hotspot/share/runtime/suspendResumeManager.cpp line 105: > >> 103: // If target is the current thread we can bypass the handshake machinery >> 104: // and just suspend directly >> 105: self_suspend(register_vthread_SR, self); > > Since `self_suspend()` is a very short method and only called from here, I would keep the method as it was and if anything define `set_suspended_with_id(int64_t id, bool register_vthread_SR)` instead. Thanks, moved. Also the include defines become correct. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2353501079 From asmehra at openjdk.org Tue Sep 16 20:12:12 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 16 Sep 2025 20:12:12 GMT Subject: RFR: 8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive [v2] In-Reply-To: <_9nNxBwVLnPtzYDje1iXrVblRea4dLB45_x_uhkj_sc=.daaf7b91-de9f-4a2b-8e23-1797118c5767@github.com> References: <9tei5T4Ox7c_zVMGBsROyJTxsdRjKAXDQTOPo3d62sM=.b2331cfb-b759-4552-9a79-6cd0c71097cb@github.com> <0mcWOte-iIlkryKC4UlENZxN2zZvnknukcOMS7CKLEQ=.3abf7c16-b4e4-4424-aebe-860a6e06edaf@github.com> <0nsyTQlQ9o7jjgwUTRWImOL_0g08xiJhGYKm4M_tRgc=.1dca7305-0ba1-405c-b9e4-6c2668a6debd@github.com> <_9nNxBwVLnPtzYDje1iXrVblRea4dLB45_x_uhkj_sc=.daaf7b91-de9f-4a2b-8e23-1797118c5767@github.com> Message-ID: On Tue, 16 Sep 2025 19:45:05 GMT, Ioi Lam wrote: >>> The settings of optimization levels, including all the settings in setup_compiler_args(), should be moved to CDSConfig::ergo_initialize(). If we see any inconsistent settings, they should be correct with FLAG_SET_ERGO() (and we don't exit the VM). >> >> Agree. > >> Here AOTClassLinking is set and checked in check_vm_args_consistency() > https://github.com/openjdk/leyden/blob/master/src/hotspot/share/cds/cdsConfig.cpp#L636 > > Hmm, for convoluted cases like this, we will actually turn on AOTClassLinking ergomomically for dynamic dump > > java -XX:ArchiveClassesAtExit=foo.jsa -cp HelloWorld.jar -XX:AOTMode=on -XX:AOTCache=hw.aot HelloWorld > > > I've removed the assert and print the warning only if `FLAG_IS_CMDLINE(AOTClassLinking)` @iklam > java -XX:ArchiveClassesAtExit=foo.jsa -cp HelloWorld.jar -XX:AOTMode=on -XX:AOTCache=hw.aot HelloWorld What would this command do? Generate `hw.aot` or `foo.jsa`? I think this is, as you said, a convoluted case and it is best to not allow the user to mix the two workflows. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27242#discussion_r2353544448 From iklam at openjdk.org Tue Sep 16 20:34:43 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 16 Sep 2025 20:34:43 GMT Subject: RFR: 8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive [v2] In-Reply-To: References: <9tei5T4Ox7c_zVMGBsROyJTxsdRjKAXDQTOPo3d62sM=.b2331cfb-b759-4552-9a79-6cd0c71097cb@github.com> <0mcWOte-iIlkryKC4UlENZxN2zZvnknukcOMS7CKLEQ=.3abf7c16-b4e4-4424-aebe-860a6e06edaf@github.com> <0nsyTQlQ9o7jjgwUTRWImOL_0g08xiJhGYKm4M_tRgc=.1dca7305-0ba1-405c-b9e4-6c2668a6debd@github.com> <_9nNxBwVLnPtzYDje1iXrVblRea4dLB45_x_uhkj_sc=.daaf7b91-de9f-4a2b-8e23-1797118c5767@github.com> Message-ID: On Tue, 16 Sep 2025 20:09:26 GMT, Ashutosh Mehra wrote: >>> Here AOTClassLinking is set and checked in check_vm_args_consistency() >> https://github.com/openjdk/leyden/blob/master/src/hotspot/share/cds/cdsConfig.cpp#L636 >> >> Hmm, for convoluted cases like this, we will actually turn on AOTClassLinking ergomomically for dynamic dump >> >> java -XX:ArchiveClassesAtExit=foo.jsa -cp HelloWorld.jar -XX:AOTMode=on -XX:AOTCache=hw.aot HelloWorld >> >> >> I've removed the assert and print the warning only if `FLAG_IS_CMDLINE(AOTClassLinking)` > > @iklam >> java -XX:ArchiveClassesAtExit=foo.jsa -cp HelloWorld.jar -XX:AOTMode=on -XX:AOTCache=hw.aot HelloWorld > > What would this command do? Generate `hw.aot` or `foo.jsa`? I think this is, as you said, a convoluted case and it is best to not allow the user to mix the two workflows. Here's a more elaborate example. It works today as `base.aot` is essentially a static CDS archive. $ java -XX:AOTCacheOutput=base.aot --version $ java -cp HelloWorld.jar -XX:AOTCache=base.aot -XX:ArchiveClassesAtExit=dyn.jsa HelloWorld $ java -Xlog:cds -cp HelloWorld.jar -XX:SharedArchiveFile=dyn.jsa HelloWorld ... [0.003s][info][cds] Opened shared archive file base.aot. ... [0.003s][info][cds] Opened shared archive file dyn.jsa. ... Hello World I agree that we should disallow this combination. In JEP 483 we explicitly disallowed mixing `-XX:AOTxxx` with classical CDS flags such as `-XX:SharedArchiveFile`. We should have also disallowed `-XX:ArchiveClassesAtExit` and other flags used by the dynamic archive. This will simplify AOT implementation and also will avoid future incompatibility -- there's no guarantee that the above would work when more optimizations are added to AOT. Maybe I should do it in a follow-up PR? I want to make this PR simple in order to unblock #26375 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27242#discussion_r2353589244 From asmehra at openjdk.org Tue Sep 16 20:43:52 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 16 Sep 2025 20:43:52 GMT Subject: RFR: 8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive [v2] In-Reply-To: References: <9tei5T4Ox7c_zVMGBsROyJTxsdRjKAXDQTOPo3d62sM=.b2331cfb-b759-4552-9a79-6cd0c71097cb@github.com> <0mcWOte-iIlkryKC4UlENZxN2zZvnknukcOMS7CKLEQ=.3abf7c16-b4e4-4424-aebe-860a6e06edaf@github.com> <0nsyTQlQ9o7jjgwUTRWImOL_0g08xiJhGYKm4M_tRgc=.1dca7305-0ba1-405c-b9e4-6c2668a6debd@github.com> <_9nNxBwVLnPtzYDje1iXrVblRea4dLB45_x_uhkj_sc=.daaf7b91-de9f-4a2b-8e23-1797118c5767@github.com> Message-ID: On Tue, 16 Sep 2025 20:32:12 GMT, Ioi Lam wrote: >> @iklam >>> java -XX:ArchiveClassesAtExit=foo.jsa -cp HelloWorld.jar -XX:AOTMode=on -XX:AOTCache=hw.aot HelloWorld >> >> What would this command do? Generate `hw.aot` or `foo.jsa`? I think this is, as you said, a convoluted case and it is best to not allow the user to mix the two workflows. > > Here's a more elaborate example. It works today as `base.aot` is essentially a static CDS archive. > > > $ java -XX:AOTCacheOutput=base.aot --version > $ java -cp HelloWorld.jar -XX:AOTCache=base.aot -XX:ArchiveClassesAtExit=dyn.jsa HelloWorld > $ java -Xlog:cds -cp HelloWorld.jar -XX:SharedArchiveFile=dyn.jsa HelloWorld > ... > [0.003s][info][cds] Opened shared archive file base.aot. > ... > [0.003s][info][cds] Opened shared archive file dyn.jsa. > ... > Hello World > > > I agree that we should disallow this combination. In JEP 483 we explicitly disallowed mixing `-XX:AOTxxx` with classical CDS flags such as `-XX:SharedArchiveFile`. We should have also disallowed `-XX:ArchiveClassesAtExit` and other flags used by the dynamic archive. > > This will simplify AOT implementation and also will avoid future incompatibility -- there's no guarantee that the above would work when more optimizations are added to AOT. > > Maybe I should do it in a follow-up PR? I want to make this PR simple in order to unblock #26375 I get that now. The AOTCache has already been created, and is now used as the base archive for the dynamic archive. > This will simplify AOT implementation and also will avoid future incompatibility -- there's no guarantee that the above would work when more optimizations are added to AOT. > > Maybe I should do it in a follow-up PR? I want to make this PR simple in order to unblock https://github.com/openjdk/jdk/pull/26375 Yup, a follow-up PR should be fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27242#discussion_r2353608306 From lmesnik at openjdk.org Tue Sep 16 21:45:37 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 16 Sep 2025 21:45:37 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v8] In-Reply-To: References: Message-ID: > The > `SuspendResumeManager::suspend(bool register_vthread_SR)` > has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. > > Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. > > The fix added some "asymmetry" in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: test fixed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27317/files - new: https://git.openjdk.org/jdk/pull/27317/files/d80d7cf4..0eb9f404 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27317&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27317&range=06-07 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27317/head:pull/27317 PR: https://git.openjdk.org/jdk/pull/27317 From fandreuzzi at openjdk.org Tue Sep 16 22:25:08 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Tue, 16 Sep 2025 22:25:08 GMT Subject: RFR: 8367689: Revert removal of several compilation-related vmStructs fields [v2] In-Reply-To: References: Message-ID: > #23782 ([JDK-8315488](https://bugs.openjdk.org/browse/JDK-8315488)) removed several vmStructs fields. A small subset was used in Async-Profiler: > > CiEnv* _env > CompileTask* _task > ciMethod* _method > > > I propose a small patch to bring them back. It helps third-party tools in building useful features on the JDK. For example, Async-Profiler uses these fields to display the current method being compiled in a compiler thread. Francesco Andreuzzi has updated the pull request incrementally with six additional commits since the last revision: - note - nn - nn - cc - nn - nn ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27318/files - new: https://git.openjdk.org/jdk/pull/27318/files/5bc13c6c..e8b7849d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27318&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27318&range=00-01 Stats: 95 lines in 14 files changed: 0 ins; 54 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/27318.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27318/head:pull/27318 PR: https://git.openjdk.org/jdk/pull/27318 From coleenp at openjdk.org Tue Sep 16 22:25:10 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 16 Sep 2025 22:25:10 GMT Subject: RFR: 8367689: Revert removal of several compilation-related vmStructs fields [v2] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 22:22:13 GMT, Francesco Andreuzzi wrote: >> #23782 ([JDK-8315488](https://bugs.openjdk.org/browse/JDK-8315488)) removed several vmStructs fields. A small subset was used in Async-Profiler: >> >> CiEnv* _env >> CompileTask* _task >> ciMethod* _method >> >> >> I propose a small patch to bring them back. It helps third-party tools in building useful features on the JDK. For example, Async-Profiler uses these fields to display the current method being compiled in a compiler thread. > > Francesco Andreuzzi has updated the pull request incrementally with six additional commits since the last revision: > > - note > - nn > - nn > - cc > - nn > - nn Changes requested by coleenp (Reviewer). src/hotspot/share/runtime/vmStructs.cpp line 677: > 675: nonstatic_field(CompilerThread, _env, ciEnv*) \ > 676: nonstatic_field(ciEnv, _task, CompileTask*) \ > 677: c2_nonstatic_field(Compile, _method, ciMethod*) \ It would be really easy for someone to notice that these aren't used and delete them again, and it's unfortunate that this macro has to be propagated throughout all the vmStructs macros. I can see some external tool needing CompilerThread env and ciEnv task (the current compile task) but maybe this can not need Compile::_method? Instead of adding the c2 macros, can you change the code to have: COMPILER2_PRESENT(nontstatic_field(Compile, _method, ciMethod*)) COMPILER2_PRESENT(declare_toplevel_type(Compile)) etc. ------------- PR Review: https://git.openjdk.org/jdk/pull/27318#pullrequestreview-3231331939 PR Review Comment: https://git.openjdk.org/jdk/pull/27318#discussion_r2353411773 From coleenp at openjdk.org Tue Sep 16 22:25:11 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 16 Sep 2025 22:25:11 GMT Subject: RFR: 8367689: Revert removal of several compilation-related vmStructs fields [v2] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 19:12:35 GMT, Coleen Phillimore wrote: >> Francesco Andreuzzi has updated the pull request incrementally with six additional commits since the last revision: >> >> - note >> - nn >> - nn >> - cc >> - nn >> - nn > > src/hotspot/share/runtime/vmStructs.cpp line 677: > >> 675: nonstatic_field(CompilerThread, _env, ciEnv*) \ >> 676: nonstatic_field(ciEnv, _task, CompileTask*) \ >> 677: c2_nonstatic_field(Compile, _method, ciMethod*) \ > > It would be really easy for someone to notice that these aren't used and delete them again, and it's unfortunate that this macro has to be propagated throughout all the vmStructs macros. I can see some external tool needing CompilerThread env and ciEnv task (the current compile task) but maybe this can not need Compile::_method? > > Instead of adding the c2 macros, can you change the code to have: > > COMPILER2_PRESENT(nontstatic_field(Compile, _method, ciMethod*)) > COMPILER2_PRESENT(declare_toplevel_type(Compile)) > etc. Add a comment that these fields are needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27318#discussion_r2353414090 From fandreuzzi at openjdk.org Tue Sep 16 22:25:11 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Tue, 16 Sep 2025 22:25:11 GMT Subject: RFR: 8367689: Revert removal of several compilation-related vmStructs fields [v2] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 19:13:39 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/vmStructs.cpp line 677: >> >>> 675: nonstatic_field(CompilerThread, _env, ciEnv*) \ >>> 676: nonstatic_field(ciEnv, _task, CompileTask*) \ >>> 677: c2_nonstatic_field(Compile, _method, ciMethod*) \ >> >> It would be really easy for someone to notice that these aren't used and delete them again, and it's unfortunate that this macro has to be propagated throughout all the vmStructs macros. I can see some external tool needing CompilerThread env and ciEnv task (the current compile task) but maybe this can not need Compile::_method? >> >> Instead of adding the c2 macros, can you change the code to have: >> >> COMPILER2_PRESENT(nontstatic_field(Compile, _method, ciMethod*)) >> COMPILER2_PRESENT(declare_toplevel_type(Compile)) >> etc. > > Add a comment that these fields are needed. > I can see some external tool needing CompilerThread env and ciEnv task (the current compile task) but maybe this can not need Compile::_method? This is how we use `Compile::_method` in Async-Profiler: VMMethod* compiledMethod() { const char* env = *(const char**) at(_comp_env_offset); if (env != NULL) { const char* task = *(const char**) (env + _comp_task_offset); if (task != NULL) { return *(VMMethod**) (task + _comp_method_offset); } } return NULL; } so we can get a `jmethodID` to the method being compiled. That's the only use case we have for these fields. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27318#discussion_r2353458447 From apangin at openjdk.org Tue Sep 16 22:25:12 2025 From: apangin at openjdk.org (Andrei Pangin) Date: Tue, 16 Sep 2025 22:25:12 GMT Subject: RFR: 8367689: Revert removal of several compilation-related vmStructs fields [v2] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 19:13:39 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/vmStructs.cpp line 677: >> >>> 675: nonstatic_field(CompilerThread, _env, ciEnv*) \ >>> 676: nonstatic_field(ciEnv, _task, CompileTask*) \ >>> 677: c2_nonstatic_field(Compile, _method, ciMethod*) \ >> >> It would be really easy for someone to notice that these aren't used and delete them again, and it's unfortunate that this macro has to be propagated throughout all the vmStructs macros. I can see some external tool needing CompilerThread env and ciEnv task (the current compile task) but maybe this can not need Compile::_method? >> >> Instead of adding the c2 macros, can you change the code to have: >> >> COMPILER2_PRESENT(nontstatic_field(Compile, _method, ciMethod*)) >> COMPILER2_PRESENT(declare_toplevel_type(Compile)) >> etc. > > Add a comment that these fields are needed. @coleenp Good catch, thanks. `Compile::_method` is redundant, indeed. `CompileTask::_method` is what async-profiler needs, but it's still in place. @fandreuz I think this PR can do without platform-dependent changes. For the context, it's [this feature](https://github.com/async-profiler/async-profiler/blob/master/docs/AdvancedStacktraceFeatures.md#display-jit-compilation-task) that embeds method name of the current compile task right in the C1/C2 stack traces. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27318#discussion_r2353489167 From fandreuzzi at openjdk.org Tue Sep 16 22:25:13 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Tue, 16 Sep 2025 22:25:13 GMT Subject: RFR: 8367689: Revert removal of several compilation-related vmStructs fields [v2] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 19:42:16 GMT, Andrei Pangin wrote: > Good catch, thanks. Compile::_method is redundant, I see, thanks! 3a263b3843f605eac286ec1c8611479da87f6b93 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27318#discussion_r2353748289 From fandreuzzi at openjdk.org Tue Sep 16 22:25:13 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Tue, 16 Sep 2025 22:25:13 GMT Subject: RFR: 8367689: Revert removal of several compilation-related vmStructs fields [v2] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 21:58:31 GMT, Francesco Andreuzzi wrote: >> @coleenp Good catch, thanks. `Compile::_method` is redundant, indeed. `CompileTask::_method` is what async-profiler needs, but it's still in place. >> @fandreuz I think this PR can do without platform-dependent changes. >> >> For the context, it's [this feature](https://github.com/async-profiler/async-profiler/blob/master/docs/AdvancedStacktraceFeatures.md#display-jit-compilation-task) that embeds method name of the current compile task right in the C1/C2 stack traces. > >> Good catch, thanks. Compile::_method is redundant, > > I see, thanks! 3a263b3843f605eac286ec1c8611479da87f6b93 > I think this PR can do without platform-dependent changes. Right, many things turned out to be unnecessary. Thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27318#discussion_r2353778633 From coleenp at openjdk.org Tue Sep 16 22:34:18 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 16 Sep 2025 22:34:18 GMT Subject: RFR: 8367689: Revert removal of several compilation-related vmStructs fields [v2] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 22:25:08 GMT, Francesco Andreuzzi wrote: >> #23782 ([JDK-8315488](https://bugs.openjdk.org/browse/JDK-8315488)) removed several vmStructs fields. A small subset was used in Async-Profiler: >> >> CiEnv* _env >> CompileTask* _task >> ciMethod* _method >> >> >> I propose a small patch to bring them back. It helps third-party tools in building useful features on the JDK. For example, Async-Profiler uses these fields to display the current method being compiled in a compiler thread. > > Francesco Andreuzzi has updated the pull request incrementally with six additional commits since the last revision: > > - note > - nn > - nn > - cc > - nn > - nn Oh that is much better! Thanks. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27318#pullrequestreview-3231896761 From sviswanathan at openjdk.org Wed Sep 17 00:28:50 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Wed, 17 Sep 2025 00:28:50 GMT Subject: RFR: 8367780: Enable UseAPX on Intel CPUs only when both APX_F and APX_NCI_NDD_NF cpuid features are present [v3] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 19:21:28 GMT, Srinivas Vamsi Parasa wrote: >> The goal of this PR is to enable APX on Intel CPUs (i.e. enable UseAPX) only when both the APX_F and APX_NCI_NDD_NF cpuid feature flags are present. >> >> As per the latest update to the Intel APX specification (https://www.intel.com/content/www/us/en/content-details/861610/intel-advanced-performance-extensions-intel-apx-architecture-specification.html ), when APX_F is set, processors also provide CPUID leaf 0x29 (APX Advanced Performance Extensions Leaf). Any Intel processor that enumerates APX_F also enumerates APX_NCI_NDD_NF. >> >> This PR enhances the HotSpot x86 CPU feature detection to recognize the APX_NCI_NDD_NF sub-feature of Intel APX and update the enabling logic for UseAPX VM flag. > > Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: > > update KNL check src/hotspot/cpu/x86/vm_version_x86.cpp line 1083: > 1081: if (!UseAPX) { > 1082: _features.clear_feature(CPU_APX_F); > 1083: _features.clear_feature(CPU_APX_NCI_NDD_NF); We don't need separate CPU_APX_NCI_NDD_NF feature and the related changes as CPU_APX_F feature is set only when both bits (sefsl1_cpuid7_edx.bits.apx_f and std_cpuid29_ebx.bits.apx_nci_ndd_nf) are set. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27320#discussion_r2353925684 From dholmes at openjdk.org Wed Sep 17 00:58:38 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Sep 2025 00:58:38 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v4] In-Reply-To: <6p7ncBylItu9HEeCINmqu_JFoL6zNXwJuSQaZoQ0J2I=.451526e1-d918-4fee-b1a7-e8193da61545@github.com> References: <6p7ncBylItu9HEeCINmqu_JFoL6zNXwJuSQaZoQ0J2I=.451526e1-d918-4fee-b1a7-e8193da61545@github.com> Message-ID: On Thu, 4 Sep 2025 22:01:57 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 8. >> >> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. > > Christian Stein 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 five additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Update to use correct library directories > > See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files > - 8361950: Set required version to 8+2 > - 8361950: Update to use jtreg 8 I'm happy to see this go in now. Thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3300816267 From dholmes at openjdk.org Wed Sep 17 01:01:35 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Sep 2025 01:01:35 GMT Subject: RFR: 8362561: Remove diagnostic option AllowArchivingWithJavaAgent In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 03:52:16 GMT, Ioi Lam wrote: > Goal: simplify AOT implementation and removed unnecessary tests: > > This PR removes old CDS tests that use java agents during CDS dump (to increase test coverage by triggering conditions, such as GCs, that were not happening during usual `java -Xshare:dump` operations). > > Since AOT assembly is much more complex now, we have enough coverage. These old tests are no longer necessary. > > With these tests removed, we no longer need the `-XX:-AllowArchivingWithJavaAgent` diagnostic flag, which has been abused by users despite the warning that this flag should not be used in production. Seems like a nice cleanup and simplification. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27304#pullrequestreview-3232124747 From dholmes at openjdk.org Wed Sep 17 02:23:35 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Sep 2025 02:23:35 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v3] In-Reply-To: References: <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com> Message-ID: On Tue, 16 Sep 2025 08:05:04 GMT, Johan Sj?len wrote: >> src/hotspot/share/oops/constantPool.cpp line 2348: >> >>> 2346: assert(num_entries + iter._cur_offset <= iter.insert_into->_offsets->length(), "must"); >>> 2347: for (int i = 0; i < num_entries; i++) { >>> 2348: const BSMAttributeEntry* bsmae = entry(i); >> >> Nit: It's okay to use a simple name like `e` to represent `entry` - when you don't have different types of entries involved we don't need to encode the type in the variable name. EDIT: just like in `BSMAttributeEntries::InsertionIterator::reserve_new_entry`. > > In this particular case, the `entry` method will be shadowed so you have to explicitly write `this->entry()` if you want to use that name. The existence of that variable is so short, we can just call it `e`. I don't understand your response sorry. I was simply suggesting that `bsmae` could just be `e`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2354074645 From dholmes at openjdk.org Wed Sep 17 02:33:38 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Sep 2025 02:33:38 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v3] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 10:11:09 GMT, Johan Sj?len wrote: >> Hi, >> >> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array` to store the offsets in and an `Array` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`. >> >> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately. >> >> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc. >> >> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement. >> >> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Fix type name Updates look good - thanks. A couple of follow on nits and comments. Still need to take full second pass through the code. src/hotspot/share/oops/constantPool.cpp line 1830: > 1828: bool ConstantPool::compare_bootstrap_entry_to(int idx1, const constantPoolHandle& cp2, int idx2) { > 1829: const BSMAttributeEntry* const bsmae1 = bsm_attribute_entry(idx1); > 1830: const BSMAttributeEntry* const bsmae2 = cp2->bsm_attribute_entry(idx2); Suggestion: const BSMAttributeEntry* const e1 = bsm_attribute_entry(idx1); const BSMAttributeEntry* const e2 = cp2->bsm_attribute_entry(idx2); Simple names can be used throughout. src/hotspot/share/prims/jvmtiRedefineClasses.hpp line 371: > 369: intArray * _bsm_index_map_p; > 370: > 371: // After merge_constant_pools pass 0, the BSMAttribute entries of merge_cp_p will have been expanded to fit Suggestion: // After merge_constant_pools "Pass 0", the BSMAttribute entries of merge_cp_p will have been expanded to fit ------------- PR Review: https://git.openjdk.org/jdk/pull/27198#pullrequestreview-3232321618 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2354096048 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2354103465 From dholmes at openjdk.org Wed Sep 17 04:09:36 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Sep 2025 04:09:36 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v8] In-Reply-To: References: Message-ID: <2xBFWqJ0rGk0NVEygZw2TTetP4WPuQE-KE9fZCDCxl8=.72f5d56e-5899-491f-960f-66579c9fa38b@github.com> On Tue, 16 Sep 2025 21:45:37 GMT, Leonid Mesnik wrote: >> The >> `SuspendResumeManager::suspend(bool register_vthread_SR)` >> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. >> >> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. >> >> The fix added some "asymmetry" in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > test fixed Good find! Always a worry when lack of test coverage is exposed this way. A couple of suggestions. Thanks src/hotspot/share/runtime/suspendResumeManager.cpp line 100: > 98: // If target is the current thread we can bypass the handshake machinery > 99: // and just suspend directly. > 100: // All required data should be loaded before state is set to _thread_blocked. The comment is a bit vague. Suggestion // The vthread() oop must only be accessed before state is set to _thread_blocked. src/hotspot/share/runtime/suspendResumeManager.cpp line 107: > 105: do_owner_suspend(); > 106: return true; > 107: } I prefer to see the `else` remain. src/hotspot/share/runtime/suspendResumeManager.hpp line 61: > 59: > 60: void set_suspended(bool to, bool register_vthread_SR); > 61: void set_suspended_with_id(int64_t id, bool register_vthread_SR); Some descriptive comments would be useful now due to the difference in meaning for "suspended". Personally I think we should have `set_suspended` and `set_resumed` rather than passing true/false for the suspend state. ------------- PR Review: https://git.openjdk.org/jdk/pull/27317#pullrequestreview-3232561397 PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2354226780 PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2354227402 PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2354243858 From cstein at openjdk.org Wed Sep 17 05:41:55 2025 From: cstein at openjdk.org (Christian Stein) Date: Wed, 17 Sep 2025 05:41:55 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v5] In-Reply-To: References: Message-ID: > Please review the change to update to using jtreg 8. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 - Update to use correct library directories See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files - 8361950: Set required version to 8+2 - 8361950: Update to use jtreg 8 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26261/files - new: https://git.openjdk.org/jdk/pull/26261/files/12b0d0f5..7f2017b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26261&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26261&range=03-04 Stats: 34669 lines in 1054 files changed: 16580 ins; 9869 del; 8220 mod Patch: https://git.openjdk.org/jdk/pull/26261.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26261/head:pull/26261 PR: https://git.openjdk.org/jdk/pull/26261 From kbarrett at openjdk.org Wed Sep 17 05:54:41 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 17 Sep 2025 05:54:41 GMT Subject: RFR: 8367724: Remove Trailing Return Types from undecided list In-Reply-To: References: <46T-RDnR9-S5ksqd56yTDZOrjMp5FtV0nLEcynfSmOE=.efddc6d4-1db6-4b7e-a1df-d857e320c277@github.com> Message-ID: On Tue, 16 Sep 2025 06:35:47 GMT, Stefan Karlsson wrote: >> Please review this trivial editorial change to the HotSpot Style Guide. This >> change removes Trailing Return Types from the undecided list. This should have >> been done as part of JDK-8366057, but was forgotten. > > Marked as reviewed by stefank (Reviewer). Thanks for reviews @stefank and @Arraying ------------- PR Comment: https://git.openjdk.org/jdk/pull/27305#issuecomment-3301406046 From kbarrett at openjdk.org Wed Sep 17 05:54:42 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 17 Sep 2025 05:54:42 GMT Subject: Integrated: 8367724: Remove Trailing Return Types from undecided list In-Reply-To: <46T-RDnR9-S5ksqd56yTDZOrjMp5FtV0nLEcynfSmOE=.efddc6d4-1db6-4b7e-a1df-d857e320c277@github.com> References: <46T-RDnR9-S5ksqd56yTDZOrjMp5FtV0nLEcynfSmOE=.efddc6d4-1db6-4b7e-a1df-d857e320c277@github.com> Message-ID: On Tue, 16 Sep 2025 05:43:16 GMT, Kim Barrett wrote: > Please review this trivial editorial change to the HotSpot Style Guide. This > change removes Trailing Return Types from the undecided list. This should have > been done as part of JDK-8366057, but was forgotten. This pull request has now been integrated. Changeset: c2c44a06 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/c2c44a061a6ba392b4e93eca2c85bd96ab7dcffe Stats: 5 lines in 2 files changed: 0 ins; 5 del; 0 mod 8367724: Remove Trailing Return Types from undecided list Reviewed-by: stefank, phubner ------------- PR: https://git.openjdk.org/jdk/pull/27305 From amitkumar at openjdk.org Wed Sep 17 06:07:22 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 17 Sep 2025 06:07:22 GMT Subject: RFR: 8367325: [s390x] build failure due to JDK-8361376 [v3] In-Reply-To: References: Message-ID: > Fixes the SIGLL caused after [JDK-8361376](https://bugs.openjdk.org/browse/JDK-8361376). > > Issue was with `cs` instruction, which requires the address to be aligned. And after this change address at which operating was not aligned. > > Wisdom from Principle of Z Operations: > > Sytax: CS R1,R3,D2(B2) > > Sytax: CSY R1,R3,D2(B2) > > ` > The second operand of COMPARE AND SWAP (CS, CSY) must be designated on a word boundary. > ` > > > > => 0x3fffc3149ba <_ZN17BarrierSetNMethod15set_guard_valueEP7nmethodii+266>: cs %r1,%r4,0(%r3) > (gdb) i r r3 > r3 0x3ffe500017a 4397593526650 > (gdb) p ($r3 % 8) > $5 = 2 > (gdb) si > > Thread 16 "C1 CompilerThre" received signal SIGILL, Illegal instruction. > NativeMethodBarrier::set_guard_value (bit_mask=2147483647, value=1, this=0x3ffe5000166) > at /home/amit/jdk/src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp:74 > 74 if (v == old_value) break; Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27213/files - new: https://git.openjdk.org/jdk/pull/27213/files/3545cf1b..d7d27bc8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27213&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27213&range=01-02 Stats: 8 lines in 3 files changed: 2 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27213.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27213/head:pull/27213 PR: https://git.openjdk.org/jdk/pull/27213 From amitkumar at openjdk.org Wed Sep 17 06:07:25 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 17 Sep 2025 06:07:25 GMT Subject: RFR: 8367325: [s390x] build failure due to JDK-8361376 [v2] In-Reply-To: <_GxY7fMDVZ1mv50GHTe7__GPvDOxC-vf1V50TDZuIo8=.4840c726-14a9-4311-87e3-2459e42efe3f@github.com> References: <_GxY7fMDVZ1mv50GHTe7__GPvDOxC-vf1V50TDZuIo8=.4840c726-14a9-4311-87e3-2459e42efe3f@github.com> Message-ID: On Mon, 15 Sep 2025 10:49:20 GMT, Martin Doerr wrote: >> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> better fix > > src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.hpp line 70: > >> 68: #endif // COMPILER2 >> 69: >> 70: static const int PATCHABLE_INSTRUCTION_OFFSET = 3 * 6 + 2; > > Maybe better call it `PATCHABLE_BARRIER_VALUE_OFFSET`? > It's no longer the instruction start address. > Or even better: define 2 constants. The version without the +2 is still needed below. I have given name as `PATCHABLE_SEQ_START_OFFSET` and `PATCHABLE_BARRIER_VALUE_OFFSET`. Please let me know if there is better option :) > src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp line 43: > >> 41: address inst_addr = get_barrier_start_address() + BarrierSetAssembler::PATCHABLE_INSTRUCTION_OFFSET; >> 42: >> 43: DEBUG_ONLY(Assembler::is_z_cfi(*((long*)inst_addr))); > > The cfi check needs an adjustment to point to the instruction start, right? Now It is pointing to `z_cfi`: (gdb) x/i inst_addr 0x3ffe500017a: cfi %r0,0 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27213#discussion_r2354402837 PR Review Comment: https://git.openjdk.org/jdk/pull/27213#discussion_r2354399640 From amitkumar at openjdk.org Wed Sep 17 06:18:40 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 17 Sep 2025 06:18:40 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v4] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: <3YcffjFi1BYw2B5BGUywyv0H_0ASrWgSPxvJaGTbfhg=.c83cf0f0-c0dc-460b-add2-decaf841383e@github.com> On Fri, 12 Sep 2025 16:36:56 GMT, Ruben wrote: >> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. >> >> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. > > Ruben has updated the pull request incrementally with two additional commits since the last revision: > > - Offset the deoptimization handler entry point > > Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722 > - Revert "Ensure stub code is not adjacent to a call" on s390, I see couple of test failure with: # Internal Error (/home/amit/jdk/src/hotspot/share/code/nmethod.cpp:669), pid=574704, tid=574714 # guarantee(pd != nullptr) failed: scope must be present # Problematic frame: # V [libjvm.so+0x11253f4] nmethod::scope_desc_at(unsigned char*)+0x14c BT: Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x11253f4] nmethod::scope_desc_at(unsigned char*)+0x14c (nmethod.cpp:669) V [libjvm.so+0x159b46c] compiledVFrame::compiledVFrame(frame const*, RegisterMap const*, JavaThread*, nmethod*)+0x6c (vframe_hp.cpp:305) V [libjvm.so+0x158f354] vframe::new_vframe(frame const*, RegisterMap const*, JavaThread*) [clone .part.0]+0x5c (vframe.cpp:75) V [libjvm.so+0x825f42] Deoptimization::fetch_unroll_info_helper(JavaThread*, int)+0x222 (deoptimization.cpp:517) V [libjvm.so+0x827214] Deoptimization::fetch_unroll_info(JavaThread*, int)+0x64 (deoptimization.cpp:299) v ~DeoptimizationBlob 0x000003ffa064fb92 J 265 c2 java.net.URL.(Ljava/lang/String;Ljava/lang/String;ILjava/lang/String;Ljava/net/URLStreamHandler;)V java.base at 26-internal (417 bytes) @ 0x000003ffa066b08c [0x000003ffa066a680+0x0000000000000a0c] J 256 c2 sun.net.www.ParseUtil.fileToEncodedURL(Ljava/io/File;)Ljava/net/URL; java.base at 26-internal (90 bytes) @ 0x000003ffa06688a0 [0x000003ffa0668740+0x0000000000000160] j jdk.internal.loader.URLClassPath.toFileURL(Ljava/lang/String;)Ljava/net/URL;+13 java.base at 26-internal j jdk.internal.loader.URLClassPath.(Ljava/lang/String;Z)V+96 java.base at 26-internal j jdk.internal.loader.ClassLoaders.()V+153 java.base at 26-internal v ~StubRoutines::Stub Generator call_stub_stub 0x000003ffa0500adc C 0x000003ffb07ff840 V [libjvm.so+0xbec91a] JavaCalls::call(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x42 (javaCalls.cpp:323) V [libjvm.so+0xb9a602] InstanceKlass::call_class_initializer(JavaThread*)+0x2ba (instanceKlass.cpp:1713) V [libjvm.so+0xb9dcec] InstanceKlass::initialize_impl(JavaThread*)+0x60c (instanceKlass.cpp:1321) V [libjvm.so+0xb9e2ea] InstanceKlass::initialize(JavaThread*)+0xb2 (instanceKlass.cpp:819) V [libjvm.so+0xf337f6] LinkResolver::resolve_static_call(CallInfo&, LinkInfo const&, bool, JavaThread*)+0xce (linkResolver.cpp:1115) V [libjvm.so+0xf33ad0] LinkResolver::resolve_invokestatic(CallInfo&, constantPoolHandle const&, int, JavaThread*)+0x88 (linkResolver.cpp:1744) V [libjvm.so+0xf377e4] LinkResolver::resolve_invoke(CallInfo&, Handle, constantPoolHandle const&, int, Bytecodes::Code, JavaThread*)+0xdc (linkResolver.cpp:1703) V [libjvm.so+0xbd1656] InterpreterRuntime::resolve_invoke(JavaThread*, Bytecodes::Code)+0x1ce (interpreterRuntime.cpp:826) V [libjvm.so+0xbd1dc6] InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x96 (interpreterRuntime.cpp:1005) j jdk.internal.module.ModuleBootstrap.boot()Ljava/lang/ModuleLayer;+40 java.base at 26-internal j java.lang.System.initPhase2(ZZ)I+0 java.base at 26-internal v ~StubRoutines::Stub Generator call_stub_stub 0x000003ffa0500adc C 0x000003ffb07fc7c8 V [libjvm.so+0xbeecc4] JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x1ac (javaCalls.cpp:323) V [libjvm.so+0x14dd554] Threads::create_vm(JavaVMInitArgs*, bool*)+0x8ac (threads.cpp:322) V [libjvm.so+0xd3593e] JNI_CreateJavaVM+0x7e (jni.cpp:3589) C [libjli.so+0x4170] JavaMain+0xa0 (java.c:1506) C [libjli.so+0x7f38] ThreadJavaMain+0x20 (java_md.c:646) Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) v ~DeoptimizationBlob 0x000003ffa064fb92 J 265 c2 java.net.URL.(Ljava/lang/String;Ljava/lang/String;ILjava/lang/String;Ljava/net/URLStreamHandler;)V java.base at 26-internal (417 bytes) @ 0x000003ffa066b08c [0x000003ffa066a680+0x0000000000000a0c] ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3301461222 From alanb at openjdk.org Wed Sep 17 06:41:54 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 17 Sep 2025 06:41:54 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v5] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 05:41:55 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 8. >> >> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. > > Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Update to use correct library directories > > See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files > - 8361950: Set required version to 8+2 > - 8361950: Update to use jtreg 8 make/autoconf/lib-tests.m4 line 31: > 29: > 30: # Minimum supported versions > 31: JTREG_MINIMUM_VERSION=8 Is the min version 8 or 8.2? (everywhere else in the PR suggests 8+2 so just curious). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26261#discussion_r2354467094 From cstein at openjdk.org Wed Sep 17 06:45:37 2025 From: cstein at openjdk.org (Christian Stein) Date: Wed, 17 Sep 2025 06:45:37 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v5] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 06:39:17 GMT, Alan Bateman wrote: >> Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 >> - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 >> - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 >> - Update to use correct library directories >> >> See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files >> - 8361950: Set required version to 8+2 >> - 8361950: Update to use jtreg 8 > > make/autoconf/lib-tests.m4 line 31: > >> 29: >> 30: # Minimum supported versions >> 31: JTREG_MINIMUM_VERSION=8 > > Is the min version 8 or 8.2? (everywhere else in the PR suggests 8+2 so just curious). It's 8. The +2 refers to the build number, which is required in other places. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26261#discussion_r2354476356 From alanb at openjdk.org Wed Sep 17 06:52:34 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 17 Sep 2025 06:52:34 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v5] In-Reply-To: References: Message-ID: <166qfREU1L7ZkPFg-uAVlnjoiaysBbGxYRRfAGU147E=.ba03b95e-726e-4e31-b05e-e0a2afebcfd6@github.com> On Wed, 17 Sep 2025 06:43:20 GMT, Christian Stein wrote: >> make/autoconf/lib-tests.m4 line 31: >> >>> 29: >>> 30: # Minimum supported versions >>> 31: JTREG_MINIMUM_VERSION=8 >> >> Is the min version 8 or 8.2? (everywhere else in the PR suggests 8+2 so just curious). > > It's 8. The +2 refers to the build number, which is required in other places. Thanks for clarifying. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26261#discussion_r2354488946 From jsjolen at openjdk.org Wed Sep 17 07:26:34 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 17 Sep 2025 07:26:34 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v4] In-Reply-To: References: Message-ID: <_l9gNHqLkkeioUXxWsXpWKp01ft-E06ucp_s5JUPwMo=.1879d0bf-aefd-4912-9ec5-f6d4989396f5@github.com> > Hi, > > This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array` to store the offsets in and an `Array` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`. > > We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately. > > For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc. > > On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement. > > Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again. Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision: - Update src/hotspot/share/prims/jvmtiRedefineClasses.hpp Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> - Update src/hotspot/share/oops/constantPool.cpp Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27198/files - new: https://git.openjdk.org/jdk/pull/27198/files/ddf8e8f6..0e292522 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=02-03 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27198/head:pull/27198 PR: https://git.openjdk.org/jdk/pull/27198 From jsjolen at openjdk.org Wed Sep 17 07:45:53 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 17 Sep 2025 07:45:53 GMT Subject: RFR: 8367249: [REDO] MemBaseline accesses VMT without using lock [v4] In-Reply-To: References: <3LJv6uBo_fW8pT1XQ8oGE1XxeGXWhydeXVNphMU77EY=.300798d2-4f61-48a7-a4de-ea1cdb192afd@github.com> Message-ID: On Tue, 16 Sep 2025 16:23:39 GMT, Afshin Zafari wrote: > > there seems to be no more issues. > > The `VMT::find_reserved_region(address p)` (and the other methods that traversing the tree) also should be used within the NMT lock as well. Should we do them here in this PR or a separate one? I think that it's only the `find_reserved_region` left. It seems that this *never* took the lock, presumably because we are already killing the VM when this is called. I don't know whether or not this should take the lock, as I suspect the reasoning is a bit subtle. It's best to do this one in a separate PR, because of that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27170#issuecomment-3301709595 From fyang at openjdk.org Wed Sep 17 07:49:38 2025 From: fyang at openjdk.org (Fei Yang) Date: Wed, 17 Sep 2025 07:49:38 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v3] In-Reply-To: <6ZAynMQkqdt6tIryWfsDRCmUSG_JxswlIKfj-YkcvSk=.e4874a70-a97e-43e2-ade8-e023be610a0c@github.com> References: <6ZAynMQkqdt6tIryWfsDRCmUSG_JxswlIKfj-YkcvSk=.e4874a70-a97e-43e2-ade8-e023be610a0c@github.com> Message-ID: On Mon, 15 Sep 2025 13:07:36 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> >> Currently, the cpu features of riscv are stored in separate RVFeature subclasses. >> But to support the store/restore CPU features for aot in the future, we need to store the cpu features in a continuous memory. >> As the riscv extensions are introduced continuously, I think it's better to do it via an simple bitmap at the beginning. >> Currently, just suppose the non-extension features will not be stored in aot image, so I also split the extension and non-extenion features. When we implement the related aot feature in the short future, we can revisit the way of splitting the features. Currently, just change the storage way of cpu features, lay the foundation for future aot. >> >> Thanks > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > refine src/hotspot/cpu/riscv/vm_version_riscv.hpp line 258: > 256: decl(mimpid , ImpId , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \ > 257: decl(satp_mode , SATP , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \ > 258: decl(zicboz_block_size, "ZicbozBlockSize", RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \ Hmm, why is this `"ZicbozBlockSize"` different from friends? Do we need the double quotes? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2354630103 From aboldtch at openjdk.org Wed Sep 17 08:04:45 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 17 Sep 2025 08:04:45 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v5] In-Reply-To: References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: On Tue, 16 Sep 2025 09:06:42 GMT, Afshin Zafari wrote: >> The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. >> The acceptable value is changed to 64K. >> >> Tests: >> linux-x64 tier1 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > uintptr_t -> uint64_t What is the reasoning behind using `uint64_t` rather than `uintptr_t`? I prefer the use of `uintptr_t` for values which describe addresses. While `uint64_t` will always have the same size as `uintptr_t` here (because this is 64-bit only coops code), it does not convey the same meaning to me. If anything the pre-existing type of `unscaled_end` may be wrong. Because end makes sound like an address in this context, but it is describing an offset. And is only used to check for an underflow before we may reinterpret it as an address (0 + offset). That part I think would read much better by checking for the underflow first: ```C++ uintptr_t lowest_start = aligned_heap_base_min_address; if (size <= UnscaledOopHeapMax) { lowest_start = MAX2(lowest_start, UnscaledOopHeapMax - size); } lowest_start = align_up(lowest_start, attach_point_alignment); I think the use of `uint64_t` stems from the `UnscaledOopHeapMax` and `OopEncodingHeapMax` being typed as such. Unclear to me why they are not just `size_t`, as coops is a 64-bit VM feature. ------------- PR Review: https://git.openjdk.org/jdk/pull/26955#pullrequestreview-3233193487 From mli at openjdk.org Wed Sep 17 08:18:24 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 17 Sep 2025 08:18:24 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v4] In-Reply-To: References: Message-ID: > Hi, > Can you help to review this patch? > > Currently, the cpu features of riscv are stored in separate RVFeature subclasses. > But to support the store/restore CPU features for aot in the future, we need to store the cpu features in a continuous memory. > As the riscv extensions are introduced continuously, I think it's better to do it via an simple bitmap at the beginning. > Currently, just suppose the non-extension features will not be stored in aot image, so I also split the extension and non-extenion features. When we implement the related aot feature in the short future, we can revisit the way of splitting the features. Currently, just change the storage way of cpu features, lay the foundation for future aot. > > Thanks Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: fix typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27152/files - new: https://git.openjdk.org/jdk/pull/27152/files/0ef68423..6b33210c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27152&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27152&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27152.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27152/head:pull/27152 PR: https://git.openjdk.org/jdk/pull/27152 From mli at openjdk.org Wed Sep 17 08:18:29 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 17 Sep 2025 08:18:29 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v3] In-Reply-To: References: <6ZAynMQkqdt6tIryWfsDRCmUSG_JxswlIKfj-YkcvSk=.e4874a70-a97e-43e2-ade8-e023be610a0c@github.com> Message-ID: On Wed, 17 Sep 2025 07:46:51 GMT, Fei Yang wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> refine > > src/hotspot/cpu/riscv/vm_version_riscv.hpp line 258: > >> 256: decl(mimpid , ImpId , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \ >> 257: decl(satp_mode , SATP , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \ >> 258: decl(zicboz_block_size, "ZicbozBlockSize", RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \ > > Hmm, why is this `"ZicbozBlockSize"` different from friends? Do we need the double quotes? It's a typo when merging master, thanks for catching! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2354700767 From fandreuzzi at openjdk.org Wed Sep 17 08:22:46 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 17 Sep 2025 08:22:46 GMT Subject: RFR: 8367689: Revert removal of several compilation-related vmStructs fields [v2] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 22:25:08 GMT, Francesco Andreuzzi wrote: >> #23782 ([JDK-8315488](https://bugs.openjdk.org/browse/JDK-8315488)) removed several vmStructs fields. A small subset was used in Async-Profiler: >> >> CiEnv* _env >> CompileTask* _task >> ciMethod* _method >> >> >> I propose a small patch to bring them back. It helps third-party tools in building useful features on the JDK. For example, Async-Profiler uses these fields to display the current method being compiled in a compiler thread. > > Francesco Andreuzzi has updated the pull request incrementally with six additional commits since the last revision: > > - note > - nn > - nn > - cc > - nn > - nn Test failure seems unrelated: https://github.com/fandreuz/jdk/actions/runs/17780614141/job/50541594076#step:10:2426 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27318#issuecomment-3301871690 From fandreuzzi at openjdk.org Wed Sep 17 08:30:12 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 17 Sep 2025 08:30:12 GMT Subject: Integrated: 8367476: Shenandoah: Remove use of CollectedHeap::_soft_ref_policy In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 00:19:05 GMT, Francesco Andreuzzi wrote: > Similarly to what was done in #26496 and #26648, the usages of `CollectedHeap::_soft_ref_policy` in Shenandoah can be replaced with an earlier call to `ShenandoahReferenceProcessor::set_soft_reference_policy`. > > This is the last usage of `CollectedHeap::_soft_ref_policy`, so it can be removed. > > Passes tier1-2, and tier3_gc_shenandoah. This pull request has now been integrated. Changeset: 976207df Author: Francesco Andreuzzi Committer: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/976207df1fcebf76a5f732b26424d6a4896b359e Stats: 101 lines in 20 files changed: 16 ins; 75 del; 10 mod 8367476: Shenandoah: Remove use of CollectedHeap::_soft_ref_policy Reviewed-by: ayang, wkemper ------------- PR: https://git.openjdk.org/jdk/pull/27239 From ayang at openjdk.org Wed Sep 17 08:31:58 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 17 Sep 2025 08:31:58 GMT Subject: RFR: 8367689: Revert removal of several compilation-related vmStructs fields [v2] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 22:25:08 GMT, Francesco Andreuzzi wrote: >> #23782 ([JDK-8315488](https://bugs.openjdk.org/browse/JDK-8315488)) removed several vmStructs fields. A small subset was used in Async-Profiler: >> >> CiEnv* _env >> CompileTask* _task >> ciMethod* _method >> >> >> I propose a small patch to bring them back. It helps third-party tools in building useful features on the JDK. For example, Async-Profiler uses these fields to display the current method being compiled in a compiler thread. > > Francesco Andreuzzi has updated the pull request incrementally with six additional commits since the last revision: > > - note > - nn > - nn > - cc > - nn > - nn src/hotspot/share/runtime/vmStructs.cpp line 670: > 668: \ > 669: /**************/ \ > 670: /* CI (NOTE: these fields should not be removed, they can be used by external tools) */ \ Can you also clarify what "external tools" are in the comment so that when/if those external tools stop using them, we can re-evaluate? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27318#discussion_r2354737188 From ayang at openjdk.org Wed Sep 17 08:38:01 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 17 Sep 2025 08:38:01 GMT Subject: RFR: 8362561: Remove diagnostic option AllowArchivingWithJavaAgent In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 03:52:16 GMT, Ioi Lam wrote: > Goal: simplify AOT implementation and removed unnecessary tests: > > This PR removes old CDS tests that use java agents during CDS dump (to increase test coverage by triggering conditions, such as GCs, that were not happening during usual `java -Xshare:dump` operations). > > Since AOT assembly is much more complex now, we have enough coverage. These old tests are no longer necessary. > > With these tests removed, we no longer need the `-XX:-AllowArchivingWithJavaAgent` diagnostic flag, which has been abused by users despite the warning that this flag should not be used in production. Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27304#pullrequestreview-3233316083 From cnorrbin at openjdk.org Wed Sep 17 08:41:43 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 17 Sep 2025 08:41:43 GMT Subject: RFR: 8367536: Change RBTree to use C++17 features [v3] In-Reply-To: References: Message-ID: > Hi everyone, > > C++17 lets us tidy up som of the ugly templating done in the red-black tree. We can replace the `std::false_type`/`std::true_type` tricks used to discover comparator and verifier signatures with the new `std::is_invocable(_r_v)`, and most of the overload/SFINAE noise can disappear thanks to `if constexpr`. > > We can now write one-liners such as: > ```c++ > static constexpr bool HasKeyComparator = std::is_invocable_r_v; > > > and then select the right branch with > ```c++ > if constexpr (HasKeyComparator) { } > > inside a single function instead of having several `ENABLE_IF` overloads. > > This results in fewer lines, clearer intent, and more readable errors, while keeping behaviour identical. > > Testing: > - Oracle tiers 1-3 Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: change HasNodeVerifier back to struct ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27260/files - new: https://git.openjdk.org/jdk/pull/27260/files/f20fc8e9..6f52cbf1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27260&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27260&range=01-02 Stats: 18 lines in 1 file changed: 2 ins; 3 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/27260.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27260/head:pull/27260 PR: https://git.openjdk.org/jdk/pull/27260 From ihse at openjdk.org Wed Sep 17 08:41:57 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 17 Sep 2025 08:41:57 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v5] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 05:41:55 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 8. >> >> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. > > Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Update to use correct library directories > > See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files > - 8361950: Set required version to 8+2 > - 8361950: Update to use jtreg 8 Marked as reviewed by ihse (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3233332473 From fandreuzzi at openjdk.org Wed Sep 17 08:43:06 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 17 Sep 2025 08:43:06 GMT Subject: RFR: 8367689: Revert removal of several compilation-related vmStructs fields [v2] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 08:28:53 GMT, Albert Mingkun Yang wrote: >> Francesco Andreuzzi has updated the pull request incrementally with six additional commits since the last revision: >> >> - note >> - nn >> - nn >> - cc >> - nn >> - nn > > src/hotspot/share/runtime/vmStructs.cpp line 670: > >> 668: \ >> 669: /**************/ \ >> 670: /* CI (NOTE: these fields should not be removed, they can be used by external tools) */ \ > > Can you also clarify what "external tools" are in the comment so that when/if those external tools stop using them, we can re-evaluate? Do you mean I should explicitly mention Async-Profiler? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27318#discussion_r2354766869 From cnorrbin at openjdk.org Wed Sep 17 08:48:21 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 17 Sep 2025 08:48:21 GMT Subject: RFR: 8367536: Change RBTree to use C++17 features [v3] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 08:41:43 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> C++17 lets us tidy up som of the ugly templating done in the red-black tree. We can replace the `std::false_type`/`std::true_type` tricks used to discover comparator and verifier signatures with the new `std::is_invocable(_r_v)`, and most of the overload/SFINAE noise can disappear thanks to `if constexpr`. >> >> We can now write one-liners such as: >> ```c++ >> static constexpr bool HasKeyComparator = std::is_invocable_r_v; >> >> >> and then select the right branch with >> ```c++ >> if constexpr (HasKeyComparator) { } >> >> inside a single function instead of having several `ENABLE_IF` overloads. >> >> This results in fewer lines, clearer intent, and more readable errors, while keeping behaviour identical. >> >> Testing: >> - Oracle tiers 1-3 > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > change HasNodeVerifier back to struct Thank you both for reviewing! There seems to be a [bug](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71954) in older versions of gcc with partial template specialization of constexpr inside classes. This makes GHA fail on linux since it uses that older version, but works fine on newer versions or other platforms. I think the correct solutions is to make some changes to `HasNodeVerifier` to make GHA pass. I have turned that back into a struct with `std::false_type`/`std::true_type`, similar in style to what it was before. It is still cleaner than the previous solutions, since we can still use `std::is_invocable_r_v`, and now also use `std::bool_constant`. With this we can get rid of the templated constexpr variables. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27260#issuecomment-3301975221 From kevinw at openjdk.org Wed Sep 17 09:43:43 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 17 Sep 2025 09:43:43 GMT Subject: RFR: 8367689: Revert removal of several compilation-related vmStructs fields [v2] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 22:25:08 GMT, Francesco Andreuzzi wrote: >> #23782 ([JDK-8315488](https://bugs.openjdk.org/browse/JDK-8315488)) removed several vmStructs fields. A small subset was used in Async-Profiler: >> >> CiEnv* _env >> CompileTask* _task >> ciMethod* _method >> >> >> I propose a small patch to bring them back. It helps third-party tools in building useful features on the JDK. For example, Async-Profiler uses these fields to display the current method being compiled in a compiler thread. > > Francesco Andreuzzi has updated the pull request incrementally with six additional commits since the last revision: > > - note > - nn > - nn > - cc > - nn > - nn We should clarify: These fields are not a public interface, but the JVM has to maintain them around due to other software's expectation? Async-Profiler is great, but is this change the right solution? Are there other fields which other software would have liked to stay around, and what else can not be removed? Curious how did Async-Profiler break when these are removed? Is it a crash that Async-Profiler needs to workaround, or is there less information in the collected profile. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27318#issuecomment-3302169803 From adinn at openjdk.org Wed Sep 17 09:45:05 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 17 Sep 2025 09:45:05 GMT Subject: RFR: 8367532: Declare all stubgen stub entries including internal cross-stub entries In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 15:13:07 GMT, Andrew Dinn wrote: > This PR adds declarations for internal entries used to daisy chain memory copy stubs and ensures they are saved to generated fields when produced and accessed via those fields when consumed. This will ensure they are saved and restored correctly when stubgen blobs are included in the AOT Code Cache. > > The PR also fixes a few AArch64 stubs which do not currently have their first entry at offset 0, another thing that will be needed to simplify AOT Code cache save and restore. Thanks for the reviews. Pushing this now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27228#issuecomment-3302166887 From adinn at openjdk.org Wed Sep 17 09:45:06 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 17 Sep 2025 09:45:06 GMT Subject: Integrated: 8367532: Declare all stubgen stub entries including internal cross-stub entries In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 15:13:07 GMT, Andrew Dinn wrote: > This PR adds declarations for internal entries used to daisy chain memory copy stubs and ensures they are saved to generated fields when produced and accessed via those fields when consumed. This will ensure they are saved and restored correctly when stubgen blobs are included in the AOT Code Cache. > > The PR also fixes a few AArch64 stubs which do not currently have their first entry at offset 0, another thing that will be needed to simplify AOT Code cache save and restore. This pull request has now been integrated. Changeset: faebec63 Author: Andrew Dinn URL: https://git.openjdk.org/jdk/commit/faebec63a94bb532b9d0ca0736c73ddbf1392ac2 Stats: 533 lines in 8 files changed: 273 ins; 54 del; 206 mod 8367532: Declare all stubgen stub entries including internal cross-stub entries Reviewed-by: fyang, asmehra ------------- PR: https://git.openjdk.org/jdk/pull/27228 From adinn at openjdk.org Wed Sep 17 09:47:10 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 17 Sep 2025 09:47:10 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v4] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 17:40:48 GMT, Ioi Lam wrote: >> This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. >> >> This PR annotates a single class, `jdk.internal.math.MathUtils` (also the object hierarchy root class, `Object.class`, which has no associated AOT initialization but is required for completeness). More classes will be added in future PRs. >> >> If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to >> - All of `K`'s super classes >> - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` >> >> Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). >> >> This annotation is awfully similar to `@AOTSafeClassInitializer`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Added logging about @AOTSafeClassInitializer classes that have not been initialized Thanks for the additions.Looks good! ------------- Marked as reviewed by adinn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27024#pullrequestreview-3233581981 From tschatzl at openjdk.org Wed Sep 17 09:51:44 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 17 Sep 2025 09:51:44 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v5] In-Reply-To: References: Message-ID: <3XLIQ_iY9IEEZ07Fu4ASgqwhfWW8wa_LdJ_O9fT6ipo=.d3f31990-a5ff-4083-912d-0207cb95253a@github.com> On Tue, 16 Sep 2025 12:35:38 GMT, Ivan Walulya wrote: >> Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. >> >> Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. >> >> Testing: Tier 1-7 > > Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - Revert > - Thomas Review > - return on timeout > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - timed wait > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - space > - remove debug logs > - remove debug logs > - ... and 2 more: https://git.openjdk.org/jdk/compare/67035a45...edad0efe Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27190#pullrequestreview-3233596607 From mdoerr at openjdk.org Wed Sep 17 10:11:11 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 17 Sep 2025 10:11:11 GMT Subject: RFR: 8367325: [s390x] build failure due to JDK-8361376 [v2] In-Reply-To: References: <_GxY7fMDVZ1mv50GHTe7__GPvDOxC-vf1V50TDZuIo8=.4840c726-14a9-4311-87e3-2459e42efe3f@github.com> Message-ID: On Wed, 17 Sep 2025 06:01:37 GMT, Amit Kumar wrote: >> src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp line 43: >> >>> 41: address inst_addr = get_barrier_start_address() + BarrierSetAssembler::PATCHABLE_INSTRUCTION_OFFSET; >>> 42: >>> 43: DEBUG_ONLY(Assembler::is_z_cfi(*((long*)inst_addr))); >> >> The cfi check needs an adjustment to point to the instruction start, right? > > Now It is pointing to `z_cfi`: > > > (gdb) x/i inst_addr > 0x3ffe500017a: cfi %r0,0 This line looks broken (already before this PR). Shouldn't it be something like `assert(Assembler::is_z_cfi...)`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27213#discussion_r2354998084 From mdoerr at openjdk.org Wed Sep 17 10:11:14 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 17 Sep 2025 10:11:14 GMT Subject: RFR: 8367325: [s390x] build failure due to JDK-8361376 [v3] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 06:07:22 GMT, Amit Kumar wrote: >> Fixes the SIGLL caused after [JDK-8361376](https://bugs.openjdk.org/browse/JDK-8361376). >> >> Issue was with `cs` instruction, which requires the address to be aligned. And after this change address at which operating was not aligned. >> >> Wisdom from Principle of Z Operations: >> >> Sytax: CS R1,R3,D2(B2) >> >> Sytax: CSY R1,R3,D2(B2) >> >> ` >> The second operand of COMPARE AND SWAP (CS, CSY) must be designated on a word boundary. >> ` >> >> >> >> => 0x3fffc3149ba <_ZN17BarrierSetNMethod15set_guard_valueEP7nmethodii+266>: cs %r1,%r4,0(%r3) >> (gdb) i r r3 >> r3 0x3ffe500017a 4397593526650 >> (gdb) p ($r3 % 8) >> $5 = 2 >> (gdb) si >> >> Thread 16 "C1 CompilerThre" received signal SIGILL, Illegal instruction. >> NativeMethodBarrier::set_guard_value (bit_mask=2147483647, value=1, this=0x3ffe5000166) >> at /home/amit/jdk/src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp:74 >> 74 if (v == old_value) break; > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > update src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp line 44: > 42: > 43: DEBUG_ONLY(Assembler::is_z_cfi(*((long*)inst_addr))); > 44: return inst_addr + 2; Maybe use `get_barrier_start_address() + BarrierSetAssembler:: PATCHABLE_BARRIER_VALUE_OFFSET`? `inst_addr` could be removed. src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp line 48: > 46: > 47: public: > 48: static const int BARRIER_TOTAL_LENGTH = BarrierSetAssembler::PATCHABLE_BARRIER_VALUE_OFFSET + 2*6; // bytes This is very confusing. There are 2 instructions with 6 Bytes and one instruction with 2 Bytes after PATCHABLE_SEQ_START_OFFSET. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27213#discussion_r2354995062 PR Review Comment: https://git.openjdk.org/jdk/pull/27213#discussion_r2354984035 From krk at openjdk.org Wed Sep 17 10:25:21 2025 From: krk at openjdk.org (Kerem Kat) Date: Wed, 17 Sep 2025 10:25:21 GMT Subject: RFR: 8334866: Improve Speed of ElfDecoder source search Message-ID: Right now, looking up source file and line number info is slow because we do a full linear scan of the `.debug_aranges` section for every single call. This can be a major bottleneck on large binaries, especially during frequent native stack walking, e.g. while writing an hs_err. This change fixes that by caching the address ranges on the first lookup, and keeping it in memory for the lifetime of the `DwarfFile` object. All subsequent lookups on that object now use a binary search instead of the slow linear scan. If caching fails for any reason, it just falls back to the old method. ------------- Commit messages: - 8334866: Cache debug_aranges for faster address lookups Changes: https://git.openjdk.org/jdk/pull/27337/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27337&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334866 Stats: 188 lines in 2 files changed: 186 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27337.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27337/head:pull/27337 PR: https://git.openjdk.org/jdk/pull/27337 From fandreuzzi at openjdk.org Wed Sep 17 10:39:46 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 17 Sep 2025 10:39:46 GMT Subject: RFR: 8334866: Improve Speed of ElfDecoder source search In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 10:14:09 GMT, Kerem Kat wrote: > Right now, looking up source file and line number info is slow because we do a full linear scan of the `.debug_aranges` section for every single call. This can be a major bottleneck on large binaries, especially during frequent native stack walking, e.g. while writing an hs_err. > > This change fixes that by caching the address ranges on the first lookup, and keeping it in memory for the lifetime of the `DwarfFile` object. > > All subsequent lookups on that object now use a binary search instead of the slow linear scan. If caching fails for any reason, it just falls back to the old method. src/hotspot/share/utilities/elfFile.hpp line 530: > 528: size_t _capacity; > 529: bool _initialized; > 530: bool _failed; What's the advantage of having `_failed`? It seems that whenever you check `_failed` you also check `_initialized`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2355075391 From amitkumar at openjdk.org Wed Sep 17 10:54:32 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 17 Sep 2025 10:54:32 GMT Subject: RFR: 8367325: [s390x] build failure due to JDK-8361376 [v2] In-Reply-To: References: <_GxY7fMDVZ1mv50GHTe7__GPvDOxC-vf1V50TDZuIo8=.4840c726-14a9-4311-87e3-2459e42efe3f@github.com> Message-ID: On Wed, 17 Sep 2025 10:07:55 GMT, Martin Doerr wrote: >> Now It is pointing to `z_cfi`: >> >> >> (gdb) x/i inst_addr >> 0x3ffe500017a: cfi %r0,0 > > This line looks broken (already before this PR). Shouldn't it be something like `assert(Assembler::is_z_cfi...)`? Will it be good to do something like this and get rid of `PATCHABLE_SEQ_START_OFFSET` ?: diff --git a/src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp b/src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp index 4dc50232c17..807d3cdd899 100644 --- a/src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp +++ b/src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp @@ -38,10 +38,11 @@ class NativeMethodBarrier: public NativeInstruction { } address get_patchable_data_address() const { +#ifdef ASSERT address inst_addr = get_barrier_start_address() + BarrierSetAssembler::PATCHABLE_SEQ_START_OFFSET; - - DEBUG_ONLY(Assembler::is_z_cfi(*((long*)inst_addr))); - return inst_addr + 2; + assert(Assembler::is_z_cfi(*((long*)inst_addr)), "should be"); +#endif // ASSERT + return get_barrier_start_address() + BarrierSetAssembler::PATCHABLE_BARRIER_VALUE_OFFSET; } public: ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27213#discussion_r2355109142 From krk at openjdk.org Wed Sep 17 11:11:17 2025 From: krk at openjdk.org (Kerem Kat) Date: Wed, 17 Sep 2025 11:11:17 GMT Subject: RFR: 8334866: Improve Speed of ElfDecoder source search In-Reply-To: References: Message-ID: <1imedKgVSjyJClRAHocak7H2XZHFNCWtACCfHMWKNqM=.2ddb3733-5cdc-4159-9692-5725e79aeb20@github.com> On Wed, 17 Sep 2025 10:37:14 GMT, Francesco Andreuzzi wrote: >> Right now, looking up source file and line number info is slow because we do a full linear scan of the `.debug_aranges` section for every single call. This can be a major bottleneck on large binaries, especially during frequent native stack walking, e.g. while writing an hs_err. >> >> This change fixes that by caching the address ranges on the first lookup, and keeping it in memory for the lifetime of the `DwarfFile` object. >> >> All subsequent lookups on that object now use a binary search instead of the slow linear scan. If caching fails for any reason, it just falls back to the old method. > > src/hotspot/share/utilities/elfFile.hpp line 530: > >> 528: size_t _capacity; >> 529: bool _initialized; >> 530: bool _failed; > > What's the advantage of having `_failed`? It seems that whenever you check `_failed` you also check `_initialized`. If initialization is failed for some reason, we do not try it again for the same `DwarfFile`, with the check in `ensure_aranges_cache`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2355151876 From krk at openjdk.org Wed Sep 17 11:36:19 2025 From: krk at openjdk.org (Kerem Kat) Date: Wed, 17 Sep 2025 11:36:19 GMT Subject: RFR: 8367862: debug.cpp: Do not print help message for methods not compiled in Message-ID: The `help` command in `debug.cpp` was out of date, listing only a fraction of the available functions. This and other commands callable from gdb via `call help()`. I added all commands to the help message, except `pns2` as it is documented as not being useful when called from gdb. Also fixed is the message for the conditional `pns` command appearing in PRODUCT builds. ------------- Commit messages: - Add all debug.cpp commands to its help - Do not print pns help in PRODUCT builds Changes: https://git.openjdk.org/jdk/pull/27341/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27341&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367862 Stats: 36 lines in 1 file changed: 24 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/27341.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27341/head:pull/27341 PR: https://git.openjdk.org/jdk/pull/27341 From liach at openjdk.org Wed Sep 17 11:51:58 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Sep 2025 11:51:58 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v5] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 05:41:55 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 8. >> >> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. > > Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Update to use correct library directories > > See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files > - 8361950: Set required version to 8+2 > - 8361950: Update to use jtreg 8 Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3234055339 From jsjolen at openjdk.org Wed Sep 17 12:52:17 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 17 Sep 2025 12:52:17 GMT Subject: RFR: 8367249: [REDO] MemBaseline accesses VMT without using lock [v4] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 10:24:07 GMT, Johan Sj?len wrote: >> Hi, >> >> This is a REDO, as the previous attempt caused build failures when merged with latest master. >> The only difference is that the copy ctr for the RBTRee had been integrated with a different PR, but it never should have been. I deleted the copy ctr. >> >> Thanks. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > const-ify a bit Hi @jianglizhou , There's a test failure that only appears in linux-x64-static tier1. I'm looking at running the tests under the static-jdk. So far, I've produced a static-jdk via `make CONF=slow static-jdk-image`. Do you happen to know how to execute the tier1 tests with such a JDK? I've tried `make JDK_UNDER_TEST=build/linux-x64-slowdebug/images/static-jdk/ test TEST=tier1` but it complains about JDK_UNDER_TEST not being a non-control variable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27170#issuecomment-3302835289 From ayang at openjdk.org Wed Sep 17 12:55:53 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 17 Sep 2025 12:55:53 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v61] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 07:18:14 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * iwalulya review > * documentation for a few PSS members > * rename some member variables to contain _ct and _rt suffixes in remembered set verification Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23739#pullrequestreview-3234308768 From apangin at openjdk.org Wed Sep 17 13:01:31 2025 From: apangin at openjdk.org (Andrei Pangin) Date: Wed, 17 Sep 2025 13:01:31 GMT Subject: RFR: 8367689: Revert removal of several compilation-related vmStructs fields [v2] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 09:41:00 GMT, Kevin Walls wrote: >> Francesco Andreuzzi has updated the pull request incrementally with six additional commits since the last revision: >> >> - note >> - nn >> - nn >> - cc >> - nn >> - nn > > We should clarify: > These fields are not a public interface, but the JVM has to maintain them due to other software's expectations? > > Async-Profiler is great, but is this change the right solution? Are there other fields which other software would have liked to stay around, and what else can not be removed? > > Curious how did Async-Profiler break when these are removed? Is it a crash that Async-Profiler needs to workaround, or is there less information in the collected profile. @kevinjwalls Right, VMStructs is not a public supported interface, the JVM is not obliged to maintain it. Yet, some external tools (async-profiler and eBPF based profilers) softly rely on that in the lack of standard supported alternatives. At the same time, we are improving OpenJDK built-in capabilities that can eventually serve as such an alternative. A recent example is JEP 509: JFR CPU-Time Profiling. It's still a long path until JFR or other built-in tools can satisfy today's demand; in the meantime, VMStructs provides a temporary solution. VMStructs is a reasonable trade-off, very cheap from the maintenance perspective as opposed to AsyncGetCallTrace (async-profiler no longer depends on the latter). To emphasize, we do not expect others to maintain VM structures that async-profiler relies on, that is our (profiler + Corretto) responsibility. Infrequent changes will be small, localized and safe, like in this PR. As for the question how async-profiler breaks: if it is an optional feature (like here), it gracefully reduces functionality. Async-profiler attempts to detect essential VM changes and fail fast to prevent from crashing at runtime. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27318#issuecomment-3302889663 From iwalulya at openjdk.org Wed Sep 17 13:56:08 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 17 Sep 2025 13:56:08 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v5] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 09:21:59 GMT, Ivan Walulya wrote: >> Yes I do have concerns - sorry. Any change to the shutdown sequence needs very careful analysis. You have now changed the circumstances whereby the JVMTI events get posted. Maybe it won't matter, maybe it will - the issue is that it is very hard to determine the impact of such a change until you get notified that someone's code is now broken. > > I have undone that part of the change. We can revisit it separately, that way it is easier to backout if it is problematic Created [JDK-8367902](https://bugs.openjdk.org/browse/JDK-8367902) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2355608908 From kevinw at openjdk.org Wed Sep 17 14:05:35 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 17 Sep 2025 14:05:35 GMT Subject: RFR: 8367689: Revert removal of several compilation-related vmStructs fields [v2] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 12:59:13 GMT, Andrei Pangin wrote: >> We should clarify: >> These fields are not a public interface, but the JVM has to maintain them due to other software's expectations? >> >> Async-Profiler is great, but is this change the right solution? Are there other fields which other software would have liked to stay around, and what else can not be removed? >> >> Curious how did Async-Profiler break when these are removed? Is it a crash that Async-Profiler needs to workaround, or is there less information in the collected profile. > > @kevinjwalls Right, VMStructs is not a public supported interface, the JVM is not obliged to maintain it. Yet, some external tools (async-profiler and eBPF based profilers) softly rely on that in the lack of standard supported alternatives. At the same time, we are improving OpenJDK built-in capabilities that can eventually serve as such an alternative. A recent example is JEP 509: JFR CPU-Time Profiling. It's still a long path until JFR or other built-in tools can satisfy today's demand; in the meantime, VMStructs provides a temporary solution. > > VMStructs is a reasonable trade-off, very cheap from the maintenance perspective as opposed to AsyncGetCallTrace (async-profiler no longer depends on the latter). To emphasize, we do not expect others to maintain VM structures that async-profiler relies on, that is our (profiler + Corretto) responsibility. Infrequent changes will be small, localized and safe, like in this PR. > > As for the question how async-profiler breaks: if it is an optional feature (like here), it gracefully reduces functionality. Async-profiler attempts to detect essential VM changes and fail fast to prevent from crashing at runtime. Thanks @apangin Andrei I thought we should be open and explicit about this, good to have that exchange in the review. Async-Profiler knew what it was getting into. 8-) In the comment being added above, what is it appropriate to say... Saying "should not removed... they can be used by external tools" as an instruction seems like an overreach. Maybe more like: "These CI fields are retained in VMStructs for the benefit of external tools, to ease their migration to a future alternative." ------------- PR Comment: https://git.openjdk.org/jdk/pull/27318#issuecomment-3303157325 From sgehwolf at openjdk.org Wed Sep 17 14:42:26 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 17 Sep 2025 14:42:26 GMT Subject: RFR: 8360651: Create OSContainer API for memory limit [v2] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 16:12:42 GMT, Thomas Stuefe wrote: > Is the copyright still correct? I'll update to the IBM one. > test/hotspot/jtreg/containers/docker/TestContainerMemory.java line 62: > >> 60: try { >> 61: testWithMemoryLimit(); >> 62: testWithoutMemoryLimit(); > > Just a remark, if you do these as separate tests (separate `@test` blocks), you can parallelize their execution and start them separately via jtreg command line if needed. I'm not sure if this would work for the container tests, which build a container image first and then run the tests on it. But it's good to know otherwise. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26020#issuecomment-3303334929 PR Review Comment: https://git.openjdk.org/jdk/pull/26020#discussion_r2355763774 From sgehwolf at openjdk.org Wed Sep 17 14:47:08 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 17 Sep 2025 14:47:08 GMT Subject: RFR: 8360651: Create OSContainer API for memory limit [v2] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 17:54:10 GMT, Severin Gehwolf wrote: >> Please review this small addition to add a new `OSContainer::has_memory_limit()` API (Linux only - as with the entire OSContainer API) in preparation for [JDK-8350596](https://bugs.openjdk.org/browse/JDK-8350596) which proposes to increase the default `MaxRAMPercentage` when this new API returns true. The patch is pretty trivial. It's only the testing which amounts to the most lines in this patch. >> >> Testing: >> - [x] GHA >> - [x] Hotspot container tests on x86_64 Linux on cgroup v1 and cgroup v2 (including the new tests). >> >> Thoughts? > > Severin Gehwolf 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 four additional commits since the last revision: > > - Merge branch 'master' into jdk-8360651-mem-limit-api > - MemoryLimitTest whitespace fixes. > - TestContainerMemory whitespace fixes. > - 8360651: Create OSContainer API for memory limit Thanks for the review! Looking for a second reviewer. @kstefanj perhaps as this in preparation for https://bugs.openjdk.org/browse/JDK-8350596? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26020#issuecomment-3303353369 From kvn at openjdk.org Wed Sep 17 14:55:27 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 17 Sep 2025 14:55:27 GMT Subject: RFR: 8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive [v4] In-Reply-To: References: Message-ID: <3BYwPU47V7W9HpAgUtDx1SNwkOUQfM8Bx_ebGeNPnx0=.3ae19512-d717-4fc1-aae7-f9b46a45b941@github.com> On Tue, 16 Sep 2025 19:48:02 GMT, Ioi Lam wrote: >> Support of `-XX:+AOTClassLinking` for dynamic CDS archive is not an documented feature of [JEP 483](https://openjdk.org/jeps/483). It has very small performance benefit and complicates the development of future AOT optimizations. >> >> After this PR, `-XX:+AOTClassLinking` will have no effect when creating a dynamic CDS archive. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @vnkozlov review -- print warning only if -XX:+AOTClassLinking is set in command-line Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27242#pullrequestreview-3234891614 From lmesnik at openjdk.org Wed Sep 17 14:56:47 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 17 Sep 2025 14:56:47 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v9] In-Reply-To: References: Message-ID: > The > `SuspendResumeManager::suspend(bool register_vthread_SR)` > has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. > > Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. > > The fix added some "asymmetry" in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: updated after David's feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27317/files - new: https://git.openjdk.org/jdk/pull/27317/files/0eb9f404..96dced29 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27317&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27317&range=07-08 Stats: 10 lines in 2 files changed: 6 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27317/head:pull/27317 PR: https://git.openjdk.org/jdk/pull/27317 From lmesnik at openjdk.org Wed Sep 17 14:56:50 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 17 Sep 2025 14:56:50 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v8] In-Reply-To: <2xBFWqJ0rGk0NVEygZw2TTetP4WPuQE-KE9fZCDCxl8=.72f5d56e-5899-491f-960f-66579c9fa38b@github.com> References: <2xBFWqJ0rGk0NVEygZw2TTetP4WPuQE-KE9fZCDCxl8=.72f5d56e-5899-491f-960f-66579c9fa38b@github.com> Message-ID: On Wed, 17 Sep 2025 04:05:58 GMT, David Holmes wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> test fixed > > src/hotspot/share/runtime/suspendResumeManager.hpp line 61: > >> 59: >> 60: void set_suspended(bool to, bool register_vthread_SR); >> 61: void set_suspended_with_id(int64_t id, bool register_vthread_SR); > > Some descriptive comments would be useful now due to the difference in meaning for "suspended". Personally I think we should have `set_suspended` and `set_resumed` rather than passing true/false for the suspend state. I added comment. The set_suspended(bool..) -> set_suspended/set_resumed makes sense since we usually have have suspend/resume pair. I'll look on this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2355815267 From iwalulya at openjdk.org Wed Sep 17 14:59:05 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 17 Sep 2025 14:59:05 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v6] In-Reply-To: References: Message-ID: > Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. > > Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. > > Testing: Tier 1-7 Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - Revert - Thomas Review - return on timeout - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - timed wait - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - space - remove debug logs - ... and 3 more: https://git.openjdk.org/jdk/compare/d7eeacf2...ab94789c ------------- Changes: https://git.openjdk.org/jdk/pull/27190/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=05 Stats: 178 lines in 15 files changed: 110 ins; 62 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27190.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27190/head:pull/27190 PR: https://git.openjdk.org/jdk/pull/27190 From kvn at openjdk.org Wed Sep 17 15:17:57 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 17 Sep 2025 15:17:57 GMT Subject: RFR: 8365823: Revert storing abstract and interface Klasses to non-class metaspace [v3] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 14:38:03 GMT, Coleen Phillimore wrote: >> This change removes the optimization to not store abstract and interface Klass metadata to non-class metaspace. Now all Klass metadata is in the Klass metaspace. This is simpler and less bug prone, and didn't help with the limitation of classes that can be stored in class metaspace materially. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove CFP.is_abstract(). Good. This is not 1-to-1 back-out of #19157 . I assume it is because there were several additional follow up fixes. Will 25u backport be the same? ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27295#pullrequestreview-3234989383 From jsjolen at openjdk.org Wed Sep 17 15:42:10 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 17 Sep 2025 15:42:10 GMT Subject: RFR: 8367249: [REDO] MemBaseline accesses VMT without using lock [v5] In-Reply-To: References: Message-ID: > Hi, > > This is a REDO, as the previous attempt caused build failures when merged with latest master. > The only difference is that the copy ctr for the RBTRee had been integrated with a different PR, but it never should have been. I deleted the copy ctr. > > Thanks. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: How did this even work in any release build? ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27170/files - new: https://git.openjdk.org/jdk/pull/27170/files/032fc800..c07e5cc3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27170&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27170&range=03-04 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27170.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27170/head:pull/27170 PR: https://git.openjdk.org/jdk/pull/27170 From jsjolen at openjdk.org Wed Sep 17 15:42:11 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 17 Sep 2025 15:42:11 GMT Subject: RFR: 8367249: [REDO] MemBaseline accesses VMT without using lock [v4] In-Reply-To: References: Message-ID: <-yNuE19yVGNMaxSrIkcE4GuUZlnzOAKB6lZrQ0XZGII=.3a86413a-bcf0-4a6d-be1a-ebd995b564a2@github.com> On Tue, 16 Sep 2025 10:24:07 GMT, Johan Sj?len wrote: >> Hi, >> >> This is a REDO, as the previous attempt caused build failures when merged with latest master. >> The only difference is that the copy ctr for the RBTRee had been integrated with a different PR, but it never should have been. I deleted the copy ctr. >> >> Thanks. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > const-ify a bit Well, that was a very embarrassing bug :-). I had code in an `assert` which needed to run regardless if in a debug build or not. Why didn't all release builds fail? No clue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27170#issuecomment-3303579270 From ayang at openjdk.org Wed Sep 17 15:56:53 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 17 Sep 2025 15:56:53 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v6] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 14:59:05 GMT, Ivan Walulya wrote: >> Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. >> >> Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. >> >> Testing: Tier 1-7 > > Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - Revert > - Thomas Review > - return on timeout > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - timed wait > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - space > - remove debug logs > - ... and 3 more: https://git.openjdk.org/jdk/compare/d7eeacf2...ab94789c Should `CollectedHeap::satisfy_failed_metadata_allocation` also call `stall_for_vm_shutdown`? (Looking through all subclasses of `VM_GC_Collect_Operation`.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27190#issuecomment-3303632008 From sjohanss at openjdk.org Wed Sep 17 16:47:43 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Wed, 17 Sep 2025 16:47:43 GMT Subject: RFR: 8366716: Move SmapsParser from runtime/os/TestTracePageSizes.java into testlib [v3] In-Reply-To: <1DpnUSHf7W4kL6Xg-AfFX0iWBVSZ5-AVTIBGgWWGk5M=.1cae7869-d51c-4beb-8f5a-65ea5e96c9c5@github.com> References: <2T3bok5LCvyT4TYhEfMuVG_CpSPWpeL2jqcdG7vNFBs=.e4fda680-e679-4032-9370-b79938b92099@github.com> <1DpnUSHf7W4kL6Xg-AfFX0iWBVSZ5-AVTIBGgWWGk5M=.1cae7869-d51c-4beb-8f5a-65ea5e96c9c5@github.com> Message-ID: <5dc7WZjOY4ymVSZcN7ixLlg4rGahTo9ObDSwW-xbpRQ=.7c749ebc-4b70-4492-b565-27922bfb9f78@github.com> On Mon, 15 Sep 2025 12:51:40 GMT, jonghoonpark wrote: >> related jira issue: https://bugs.openjdk.org/browse/JDK-8366716 >> >> --- >> >> Following the direction outlined in the issue description, >> I've extracted the common parts from `TestTracePageSizes` and `TestTransparentHugePagesHeap` to implement the `SmapsParser` test library. >> >> I've confirmed that it works without issues in my local tests. >> >> Reviews and feedback are welcome. > > jonghoonpark has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Refactor: Introduce Smaps class for testing > > Signed-off-by: jonghoonpark Found some time to look closer at this. I would prefer if we could clean up the `Smaps` class even more when moving it to the testlib. We might want to go even further than this: https://github.com/openjdk/jdk/compare/master...kstefanj:jdk:pull/27273-v2 I felt it was easier to show you my ideas this way rather than just giving comment. Some names might need improving and some more polishing, but what do you think about the general structure [here](https://github.com/openjdk/jdk/commit/4550eb677d74803935be64a1cc321c671f91adc7)? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27273#issuecomment-3303806697 From bulasevich at openjdk.org Wed Sep 17 17:34:32 2025 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Wed, 17 Sep 2025 17:34:32 GMT Subject: RFR: 8359378: aarch64: crash when using -XX:+UseFPUForSpilling Message-ID: <0MbLaZYRoz-raa9x1eZycxeHE7mvPiGJujQpg8vBdek=.e3483c47-ad65-4d09-baf5-2db9b780669d@github.com> AArch64 BarrierSetAssembler path assumes only FP/vector ideal regs reach the FP spill/restore encoding. With -XX:+UseFPUForSpilling Register Allocator may allocate scalar values in FP registers. When such values (Op_RegI/Op_RegN/Op_RegL/Op_RegP) hit `BarrierSetAssembler::encode_float_vector_register_size`, we trip ShouldNotReachHere in release build and **"unexpected ideal register"** assertion in debug build. Fix: teach the encoder to handle scalar ideal regs when they physically live in FP regs: - treat Op_RegI / Op_RegN as 32-bit (single slot) - same class as Op_RegF - treat Op_RegL / Op_RegP as 64-bit (two slots) - same class as Op_RegD Related: - reproduced since #19746 - spilling logic: - #18967 - #17977 Testing: tier1-3 with javaoptions -Xcomp -Xbatch -XX:+UseFPUForSpilling on AARCH ------------- Commit messages: - 8359378: arch64: crash when using -XX:+UseFPUForSpilling Changes: https://git.openjdk.org/jdk/pull/27350/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27350&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359378 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27350.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27350/head:pull/27350 PR: https://git.openjdk.org/jdk/pull/27350 From coleenp at openjdk.org Wed Sep 17 17:36:56 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 17 Sep 2025 17:36:56 GMT Subject: RFR: 8365823: Revert storing abstract and interface Klasses to non-class metaspace [v3] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 14:38:03 GMT, Coleen Phillimore wrote: >> This change removes the optimization to not store abstract and interface Klass metadata to non-class metaspace. Now all Klass metadata is in the Klass metaspace. This is simpler and less bug prone, and didn't help with the limitation of classes that can be stored in class metaspace materially. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove CFP.is_abstract(). Yes, this wasn't just a backout. I stayed away from the JFR code refactoring, and there were other fixes for hidden classes that are already in JDK 25. And we added then backported a diagnostic flag, that this change removes. Yes, this change should backport cleanly to JDK 25 pending approval. Thanks for reviewing Aleksey and Vladimir. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27295#issuecomment-3303955655 PR Comment: https://git.openjdk.org/jdk/pull/27295#issuecomment-3303957791 From sparasa at openjdk.org Wed Sep 17 17:54:49 2025 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Wed, 17 Sep 2025 17:54:49 GMT Subject: RFR: 8367780: Enable UseAPX on Intel CPUs only when both APX_F and APX_NCI_NDD_NF cpuid features are present [v4] In-Reply-To: References: Message-ID: <-cYOL5wwp8oSisK5utj0B7mHi0D_Ne0i_N_RI-bsbLk=.87c1bc5f-a6a3-4d4e-9530-fc91e676656f@github.com> > The goal of this PR is to enable APX on Intel CPUs (i.e. enable UseAPX) only when both the APX_F and APX_NCI_NDD_NF cpuid feature flags are present. > > As per the latest update to the Intel APX specification (https://www.intel.com/content/www/us/en/content-details/861610/intel-advanced-performance-extensions-intel-apx-architecture-specification.html ), when APX_F is set, processors also provide CPUID leaf 0x29 (APX Advanced Performance Extensions Leaf). Any Intel processor that enumerates APX_F also enumerates APX_NCI_NDD_NF. > > This PR enhances the HotSpot x86 CPU feature detection to recognize the APX_NCI_NDD_NF sub-feature of Intel APX and update the enabling logic for UseAPX VM flag. Srinivas Vamsi Parasa has updated the pull request incrementally with two additional commits since the last revision: - Update CPUInfoTest.java - Remove APX_NCI_NDD_NF as an explicit feature ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27320/files - new: https://git.openjdk.org/jdk/pull/27320/files/21560d0b..91f589ab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27320&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27320&range=02-03 Stats: 12 lines in 4 files changed: 0 ins; 8 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27320.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27320/head:pull/27320 PR: https://git.openjdk.org/jdk/pull/27320 From sparasa at openjdk.org Wed Sep 17 17:54:51 2025 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Wed, 17 Sep 2025 17:54:51 GMT Subject: RFR: 8367780: Enable UseAPX on Intel CPUs only when both APX_F and APX_NCI_NDD_NF cpuid features are present [v3] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 00:26:32 GMT, Sandhya Viswanathan wrote: >> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: >> >> update KNL check > > src/hotspot/cpu/x86/vm_version_x86.cpp line 1083: > >> 1081: if (!UseAPX) { >> 1082: _features.clear_feature(CPU_APX_F); >> 1083: _features.clear_feature(CPU_APX_NCI_NDD_NF); > > We don't need separate CPU_APX_NCI_NDD_NF feature and the related changes as CPU_APX_F feature is set only when both bits (sefsl1_cpuid7_edx.bits.apx_f and std_cpuid29_ebx.bits.apx_nci_ndd_nf) are set. Please see the updated changes which removes CPU_APX_NCI_NDD_NF as an explicit feature. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27320#discussion_r2356297066 From alanb at openjdk.org Wed Sep 17 18:05:03 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 17 Sep 2025 18:05:03 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v5] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 05:41:55 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 8. >> >> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. > > Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Merge branch 'openjdk:master' into JDK-8361950-jtreg-8 > - Update to use correct library directories > > See also: https://openjdk.org/jtreg/faq.html#how-do-i-find-the-path-for-the-testng-or-junit-jar-files > - 8361950: Set required version to 8+2 > - 8361950: Update to use jtreg 8 I assume you'll do another run of all tiers before integrating. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3235634542 From fandreuzzi at openjdk.org Wed Sep 17 18:54:19 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 17 Sep 2025 18:54:19 GMT Subject: RFR: 8367689: Revert removal of several compilation-related vmStructs fields [v3] In-Reply-To: References: Message-ID: <7zcjZi3Kb4EoOhhH5hDHdAkJ_YvwbDNwn0VjveCwmno=.c8a860fa-ef49-474e-b7cb-cb82ed7f229b@github.com> > #23782 ([JDK-8315488](https://bugs.openjdk.org/browse/JDK-8315488)) removed several vmStructs fields. A small subset was used in Async-Profiler: > > CiEnv* _env > CompileTask* _task > ciMethod* _method > > > I propose a small patch to bring them back. It helps third-party tools in building useful features on the JDK. For example, Async-Profiler uses these fields to display the current method being compiled in a compiler thread. Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27318/files - new: https://git.openjdk.org/jdk/pull/27318/files/e8b7849d..194a9d6f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27318&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27318&range=01-02 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27318.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27318/head:pull/27318 PR: https://git.openjdk.org/jdk/pull/27318 From asmehra at openjdk.org Wed Sep 17 19:11:48 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 17 Sep 2025 19:11:48 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v4] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 17:40:48 GMT, Ioi Lam wrote: >> This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. >> >> This PR annotates a single class, `jdk.internal.math.MathUtils` (also the object hierarchy root class, `Object.class`, which has no associated AOT initialization but is required for completeness). More classes will be added in future PRs. >> >> If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to >> - All of `K`'s super classes >> - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` >> >> Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). >> >> This annotation is awfully similar to `@AOTSafeClassInitializer`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Added logging about @AOTSafeClassInitializer classes that have not been initialized > Note, the check of the above requirement has been moved to AOTClassInitializer::check_aot_annotations(). The previous check in ClassFileParser was not executed because the class is loaded in the AOT training run, where CDSConfig::is_initing_classes_at_dump_time() returns false (this function returns true only in the AOT assembly phase). So this is a bug already present in the code and effectively disables super type checks for AOTSafeClassInitializer annotation, is that right? There is a reference to ClassFileParser in the documentation for AOTSafeClassInitializer. I think it needs to be updated as well: https://github.com/openjdk/jdk/blob/18dc186a8f4820ed78c21173713dd127ef512e1f/src/java.base/share/classes/jdk/internal/vm/annotation/AOTSafeClassInitializer.java#L124-L129 src/hotspot/share/cds/aotClassInitializer.cpp line 53: > 51: > 52: if (ik->force_aot_initialization()) { > 53: assert(ik->is_initialized(), "must have been initialized before this check"); Is it not possible for a jdk class to be loaded but not initialized during an application run? If such a jdk class is marked with AOTInitialize annotation, this assert would trigger during the assembly phase. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27024#issuecomment-3304237468 PR Review Comment: https://git.openjdk.org/jdk/pull/27024#discussion_r2356493896 From sspitsyn at openjdk.org Wed Sep 17 19:16:30 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 17 Sep 2025 19:16:30 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v9] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 14:56:47 GMT, Leonid Mesnik wrote: >> The >> `SuspendResumeManager::suspend(bool register_vthread_SR)` >> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. >> >> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. >> >> The fix added some "asymmetry" in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > updated after David's feedback src/hotspot/share/runtime/suspendResumeManager.cpp line 104: > 102: ThreadBlockInVM tbivm(self); > 103: MutexLocker ml(_state_lock, Mutex::_no_safepoint_check_flag); > 104: set_suspended_with_id(id, register_vthread_SR); Nit: I'd prefer to have the same function name overloaded with a different parameter type. There can be different opinions here, of course. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2356512510 From cstein at openjdk.org Wed Sep 17 19:24:13 2025 From: cstein at openjdk.org (Christian Stein) Date: Wed, 17 Sep 2025 19:24:13 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v5] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 18:02:32 GMT, Alan Bateman wrote: > I assume you'll do another run of all tiers before integrating. Yes. A run of tier 1-9 is in progress, with tier 1-5 already looking very promising. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26261#issuecomment-3304276125 From sspitsyn at openjdk.org Wed Sep 17 19:48:20 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 17 Sep 2025 19:48:20 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v9] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 14:56:47 GMT, Leonid Mesnik wrote: >> The >> `SuspendResumeManager::suspend(bool register_vthread_SR)` >> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. >> >> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. >> >> The fix added some "asymmetry" in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > updated after David's feedback I agree with David, it is a good find. Thank you for adding a test coverage and catching it! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27317#issuecomment-3304349859 From sspitsyn at openjdk.org Wed Sep 17 19:51:22 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 17 Sep 2025 19:51:22 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v9] In-Reply-To: References: Message-ID: <6jVRMYkRQjvB0q4MlOzqW4MS-0d7NkIplrMJkMKS0Nk=.c9d46ced-f217-41c1-8e52-4f7bf0d446ec@github.com> On Wed, 17 Sep 2025 19:13:37 GMT, Serguei Spitsyn wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> updated after David's feedback > > src/hotspot/share/runtime/suspendResumeManager.cpp line 104: > >> 102: ThreadBlockInVM tbivm(self); >> 103: MutexLocker ml(_state_lock, Mutex::_no_safepoint_check_flag); >> 104: set_suspended_with_id(id, register_vthread_SR); > > Nit: I'd prefer to have the same function name overloaded with a different parameter type. Then it will be consistent with `JvmtiVTSuspender::register_vthread_suspend(*)` overloaded functions. > There can be different opinions here, of course. Renaming it to `self_suspend()` is also a good choice IMHO. :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2356612043 From sspitsyn at openjdk.org Wed Sep 17 20:09:44 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 17 Sep 2025 20:09:44 GMT Subject: RFR: 8362561: Remove diagnostic option AllowArchivingWithJavaAgent In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 03:52:16 GMT, Ioi Lam wrote: > Goal: simplify AOT implementation and removed unnecessary tests: > > This PR removes old CDS tests that use java agents during CDS dump (to increase test coverage by triggering conditions, such as GCs, that were not happening during usual `java -Xshare:dump` operations). > > Since AOT assembly is much more complex now, we have enough coverage. These old tests are no longer necessary. > > With these tests removed, we no longer need the `-XX:-AllowArchivingWithJavaAgent` diagnostic flag, which has been abused by users despite the warning that this flag should not be used in production. This looks good, nice cleanup. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27304#pullrequestreview-3236101444 From lmesnik at openjdk.org Wed Sep 17 20:14:46 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 17 Sep 2025 20:14:46 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v9] In-Reply-To: <6jVRMYkRQjvB0q4MlOzqW4MS-0d7NkIplrMJkMKS0Nk=.c9d46ced-f217-41c1-8e52-4f7bf0d446ec@github.com> References: <6jVRMYkRQjvB0q4MlOzqW4MS-0d7NkIplrMJkMKS0Nk=.c9d46ced-f217-41c1-8e52-4f7bf0d446ec@github.com> Message-ID: On Wed, 17 Sep 2025 19:48:21 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/runtime/suspendResumeManager.cpp line 104: >> >>> 102: ThreadBlockInVM tbivm(self); >>> 103: MutexLocker ml(_state_lock, Mutex::_no_safepoint_check_flag); >>> 104: set_suspended_with_id(id, register_vthread_SR); >> >> Nit: I'd prefer to have the same function name overloaded with a different parameter type. Then it will be consistent with `JvmtiVTSuspender::register_vthread_suspend(*)` overloaded functions. >> There can be different opinions here, of course. > > Renaming it to `self_suspend()` is also a good choice IMHO. :) The 'self_suspend' is the first attempt, but I agree with @pchilano that it is better to have something similar to 'set_suspended' since the method is doing the same. It not fully suspend but only set status. The another possible name that might be: 'set_suspended_current_thread' to make clear that it is for "self suspension" purpose only. while the 'with_id' part is clear from the parameters. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2356664409 From dholmes at openjdk.org Wed Sep 17 20:44:47 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Sep 2025 20:44:47 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v9] In-Reply-To: References: <6jVRMYkRQjvB0q4MlOzqW4MS-0d7NkIplrMJkMKS0Nk=.c9d46ced-f217-41c1-8e52-4f7bf0d446ec@github.com> Message-ID: On Wed, 17 Sep 2025 20:11:39 GMT, Leonid Mesnik wrote: >> Renaming it to `self_suspend()` is also a good choice IMHO. :) > > The 'self_suspend' is the first attempt, but I agree with @pchilano that it is better to have something similar to > 'set_suspended' since the method is doing the same. It not fully suspend but only set status. > The another possible name that might be: > 'set_suspended_current_thread' > to make clear that it is for "self suspension" purpose only. > while the 'with_id' part is clear from the parameters. Given the asymmetry (we don't need a resume path that works with id) I think what you have will do. I just suggest some altered comments below. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2356729138 From dholmes at openjdk.org Wed Sep 17 20:44:50 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Sep 2025 20:44:50 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v9] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 14:56:47 GMT, Leonid Mesnik wrote: >> The >> `SuspendResumeManager::suspend(bool register_vthread_SR)` >> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. >> >> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. >> >> The fix added some "asymmetry" in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > updated after David's feedback src/hotspot/share/runtime/suspendResumeManager.hpp line 63: > 61: > 62: // The specific 'set_suspended' implementation for self suspend. > 63: void set_suspended_with_id(int64_t id, bool register_vthread_SR); Suggestion: // Sets the suspended state to `to`, applying to vthreads if `register_vthread_SR` is true. void set_suspended(bool to, bool register_vthread_SR); // Sets the suspended state to true, applying to vthreads if `register_vthread_SR` is true. // Applied to the thread with the given `id` and used when we can't extract the thread oop safely. void set_suspended_with_id(int64_t id, bool register_vthread_SR); These comments are far from perfect as it is actually hard to explain exactly what `thread` is being operated on - if any! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2356737184 From lmesnik at openjdk.org Wed Sep 17 21:09:29 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 17 Sep 2025 21:09:29 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v9] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 20:41:28 GMT, David Holmes wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> updated after David's feedback > > src/hotspot/share/runtime/suspendResumeManager.hpp line 63: > >> 61: >> 62: // The specific 'set_suspended' implementation for self suspend. >> 63: void set_suspended_with_id(int64_t id, bool register_vthread_SR); > > Suggestion: > > // Sets the suspended state to `to`, applying to vthreads if `register_vthread_SR` is true. > void set_suspended(bool to, bool register_vthread_SR); > > // Sets the suspended state to true, applying to vthreads if `register_vthread_SR` is true. > // Applied to the thread with the given `id` and used when we can't extract the thread oop safely. > void set_suspended_with_id(int64_t id, bool register_vthread_SR); > > These comments are far from perfect as it is actually hard to explain exactly what `thread` is being operated on - if any! Really the comment ```// Sets the suspended state to `to`, applying to vthreads if `register_vthread_SR` is true.``` looks incorrect to me. One might decide that the method doesn't set suspend state if for vthreads if `register_vthread_SR` is false. While the method always set suspend and might register or not vthreads to support SuspendAllVirtualThreads. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2356783702 From lmesnik at openjdk.org Wed Sep 17 21:23:42 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 17 Sep 2025 21:23:42 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v10] In-Reply-To: References: Message-ID: > The > `SuspendResumeManager::suspend(bool register_vthread_SR)` > has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. > > Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. > > The fix added some "asymmetry" in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: renamed method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27317/files - new: https://git.openjdk.org/jdk/pull/27317/files/96dced29..d2587051 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27317&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27317&range=08-09 Stats: 8 lines in 2 files changed: 3 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27317/head:pull/27317 PR: https://git.openjdk.org/jdk/pull/27317 From dholmes at openjdk.org Wed Sep 17 21:29:59 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 17 Sep 2025 21:29:59 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing In-Reply-To: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> Message-ID: <93ro1DNd1rt6ugTIpPqFl15-9ZcUzT3LW4J7TV9lAgc=.50b7e0a7-f805-4a9c-b780-56ca27085abb@github.com> On Mon, 15 Sep 2025 12:17:13 GMT, Johannes Bechberger wrote: > This change hopefully fixes the test failures by making the test cases more resilient. Added hotspot-jfr label ------------- PR Comment: https://git.openjdk.org/jdk/pull/27293#issuecomment-3304617964 From kbarrett at openjdk.org Wed Sep 17 21:33:01 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 17 Sep 2025 21:33:01 GMT Subject: RFR: 8367536: Change RBTree to use C++17 features [v3] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 08:45:45 GMT, Casper Norrbin wrote: > There seems to be a [bug](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71954) in older versions of gcc with partial template specialization of constexpr inside classes. This makes GHA fail on linux since it uses that older version, but works fine on newer versions or other platforms. I think the correct solutions is to make some changes to `HasNodeVerifier` to make GHA pass. Well that's annoying. Good job tracking down the issue. This looks like a relatively narrow bug, only affecting static data member templates with specializations. That's not a case I'd used in experiments and ongoing work that have used variable templates, so thankfully I don't need to rewrite any of those. Sorry I seem to have not explicitly tested for this case when I proposed permitting variable templates. It's very hard to test new features thoroughly, and I mostly rely on compilers doing their own testing. We could add a note to the style guide about it, though I'm reluctant to clutter that document with this kind of thing. The fix is in gcc14, so quite recent, even though the bug has been around for quite a while. My inclination is to just leave things be, as it's a pretty narrow issue that seems to me unlikely to come up often. And someday it will be moot, because we'll be requiring a more recent version of gcc. Of course, there's the contrary argument that you hit this pretty much right out of the gate... Maybe leave a comment with `has_not_verifier` about the issue, referring to that gcc bug? Oh, and `has_node_verifier` is a type, so should normally be studly capped. Add an "Impl" suffix to avoid collision with the constant, and also make it more obvious other code shouldn't be referencing it directly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27260#issuecomment-3304624393 From egahlin at openjdk.org Wed Sep 17 21:43:25 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 17 Sep 2025 21:43:25 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing In-Reply-To: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> Message-ID: <9XVUwAuoeQY1SlNtUkKK7y3K16raaY_vbN2GpNT2baU=.dbed2741-5029-485e-927a-97f661534967@github.com> On Mon, 15 Sep 2025 12:17:13 GMT, Johannes Bechberger wrote: > This change hopefully fixes the test failures by making the test cases more resilient. This test causes noise. Can @jbachorik or @apangin take a look? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27293#issuecomment-3304646592 From jiangli at openjdk.org Thu Sep 18 00:07:38 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 18 Sep 2025 00:07:38 GMT Subject: RFR: 8367249: [REDO] MemBaseline accesses VMT without using lock [v4] In-Reply-To: References: Message-ID: <6d8wA4BIp_annO6-NML8ve44SB2bSwk2geKXOUXd0To=.7d834576-f1bf-4fc2-9f29-2fdf6cfe62be@github.com> On Wed, 17 Sep 2025 12:49:00 GMT, Johan Sj?len wrote: > Hi @jianglizhou , > > There's a test failure that only appears in linux-x64-static tier1. I'm looking at running the tests under the static-jdk. So far, I've produced a static-jdk via `make CONF=slow static-jdk-image`. Do you happen to know how to execute the tier1 tests with such a JDK? > > I've tried `make JDK_UNDER_TEST=build/linux-x64-slowdebug/images/static-jdk/ test TEST=tier1` but it complains about JDK_UNDER_TEST not being a non-control variable. Hi @jdksjolen, to run jtreg tests on a `static-jdk` binary, you can set `JDK_FOR_COMPILE=`, `JDK_FOR_COMPILE=` and `extra-problem-lists` options in jtreg command line. The GHA testing on static JDK setup those to run tier1 tests: https://github.com/openjdk/jdk/blob/aa36799acb5834d730400fb073a9a3a8ee3c28ef/.github/workflows/test.yml#L185 https://bugs.openjdk.org/browse/JDK-8303796?focusedId=14745789&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14745789 has a command line example for running tier1 tests on static-jdk. To build a static JDK: `make static-jdk-image`. Hope those are helpful. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27170#issuecomment-3304902481 From jiangli at openjdk.org Thu Sep 18 00:14:35 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 18 Sep 2025 00:14:35 GMT Subject: RFR: 8367249: [REDO] MemBaseline accesses VMT without using lock [v4] In-Reply-To: <-yNuE19yVGNMaxSrIkcE4GuUZlnzOAKB6lZrQ0XZGII=.3a86413a-bcf0-4a6d-be1a-ebd995b564a2@github.com> References: <-yNuE19yVGNMaxSrIkcE4GuUZlnzOAKB6lZrQ0XZGII=.3a86413a-bcf0-4a6d-be1a-ebd995b564a2@github.com> Message-ID: On Wed, 17 Sep 2025 15:39:22 GMT, Johan Sj?len wrote: > I had code in an `assert` which needed to run regardless if in a debug build or not. Why didn't all release builds fail? No clue. The GHA teir1 testing on static JDK is only enabled for release builds currently. We haven't setup testing on debug builds for static JDK due to resource limit in GHA build environment. @magicus and the build team have solution(s) to address the issue with https://bugs.openjdk.org/browse/JDK-8350450. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27170#issuecomment-3304916212 From apangin at openjdk.org Thu Sep 18 02:09:35 2025 From: apangin at openjdk.org (Andrei Pangin) Date: Thu, 18 Sep 2025 02:09:35 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing In-Reply-To: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> Message-ID: On Mon, 15 Sep 2025 12:17:13 GMT, Johannes Bechberger wrote: > This change hopefully fixes the test failures by making the test cases more resilient. test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 99: > 97: } > 98: > 99: public static void main(String[] args) throws Exception { A brief high-level explanation of what the test does would be useful. >From what I understood, the test starts CPU time sampling with a short interval (1ms), temporarily disables processing of native samples to cause queue overflow, then enables it back to report lost samples. Repeats the cycle 5 times and verifies that the queue has grown by the time of the last iteration, thereby decreasing the amount of losses. test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 103: > 101: // setup recording > 102: AtomicLong burstThreadId = new AtomicLong(); > 103: final long startTimeMillis = System.currentTimeMillis(); Do not use `System.currentTimeMillis()` for time intervals: 1) it suffers from rounding errors due to low resolution; 2) it is not guaranteed to be monotonic. Use `System.nanoTime()` or `Instant.now()` instead. test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 119: > 117: rs.startAsync(); > 118: // this thread runs all along > 119: Thread burstThread = new Thread(() -> WHITE_BOX.busyWaitCPUTime(8000)); Instead of having a magic constant, is it possible to run `busyWaitCPUTime` continuously until explicitly stopped? test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 154: > 152: ThreadMXBean bean = ManagementFactory.getThreadMXBean(); > 153: long start = bean.getCurrentThreadCpuTime(); > 154: while (bean.getCurrentThreadCpuTime() - start < millis * 1_000_000) { Isn't this method supposed to check CPU time of the passed `thread` rather than current thread? test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 165: > 163: } > 164: // check that there are at least 3 time boxes > 165: Asserts.assertTrue(timeBoxedLosses.size() > 3); Not sure what this assert means. From what I see, the size of `timeBoxedLosses` should be exactly equal to the number of main loop iterations (5). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2357301273 PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2357230947 PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2357285587 PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2357280422 PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2357246767 From apangin at openjdk.org Thu Sep 18 02:09:36 2025 From: apangin at openjdk.org (Andrei Pangin) Date: Thu, 18 Sep 2025 02:09:36 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing In-Reply-To: References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> Message-ID: <9faaJWDTc4hOBRJ5p1ZZcX879KV1385Njd4IAL7Bu-c=.3cc8526c-a553-446f-8c90-8cc7c446a437@github.com> On Thu, 18 Sep 2025 01:55:28 GMT, Andrei Pangin wrote: >> This change hopefully fixes the test failures by making the test cases more resilient. > > test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 154: > >> 152: ThreadMXBean bean = ManagementFactory.getThreadMXBean(); >> 153: long start = bean.getCurrentThreadCpuTime(); >> 154: while (bean.getCurrentThreadCpuTime() - start < millis * 1_000_000) { > > Isn't this method supposed to check CPU time of the passed `thread` rather than current thread? BTW, is there a specific reason to burn cpu in a separate thread? It can be done in the same `main` thread, isn't it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2357283696 From dholmes at openjdk.org Thu Sep 18 02:44:34 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 18 Sep 2025 02:44:34 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v9] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 21:05:26 GMT, Leonid Mesnik wrote: >> src/hotspot/share/runtime/suspendResumeManager.hpp line 63: >> >>> 61: >>> 62: // The specific 'set_suspended' implementation for self suspend. >>> 63: void set_suspended_with_id(int64_t id, bool register_vthread_SR); >> >> Suggestion: >> >> // Sets the suspended state to `to`, applying to vthreads if `register_vthread_SR` is true. >> void set_suspended(bool to, bool register_vthread_SR); >> >> // Sets the suspended state to true, applying to vthreads if `register_vthread_SR` is true. >> // Applied to the thread with the given `id` and used when we can't extract the thread oop safely. >> void set_suspended_with_id(int64_t id, bool register_vthread_SR); >> >> These comments are far from perfect as it is actually hard to explain exactly what `thread` is being operated on - if any! > > Really the comment > ```// Sets the suspended state to `to`, applying to vthreads if `register_vthread_SR` is true.``` > looks incorrect to me. One might decide that the method doesn't set suspend state if for vthreads if `register_vthread_SR` is false. While the method always set suspend and might register or not vthreads to support SuspendAllVirtualThreads. Okay I was trying to understand exactly what these methods were doing but I'm finding it somewhat difficult to explain that. But my point is to document that the first method sets the state to true/false as directed, whilst the second always sets to true. But it gets harder to describe things when the id variant is only needed when `register_vthread_SR` is true. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2357369469 From dholmes at openjdk.org Thu Sep 18 02:48:45 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 18 Sep 2025 02:48:45 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v10] In-Reply-To: References: Message-ID: <5iVFEcNvcbry683t2HizWDraAcyf9j39LAwnoM5rm0E=.7270f60d-5427-4d8c-a69a-75bf60bf5e98@github.com> On Wed, 17 Sep 2025 21:23:42 GMT, Leonid Mesnik wrote: >> The >> `SuspendResumeManager::suspend(bool register_vthread_SR)` >> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. >> >> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. >> >> The fix added some "asymmetry" in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > renamed method src/hotspot/share/runtime/suspendResumeManager.cpp line 84: > 82: } > 83: > 84: void SuspendResumeManager::set_suspended_current_thread(int64_t vthread_id, bool register_vthread_SR) { It was totally not at all apparent that `_target` had to be the current thread here! Is it always the current thread? Won't this variant only ever get called when `register_vthread_SR` would be true - in which case we don't need that parameter? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2357373281 From iklam at openjdk.org Thu Sep 18 02:51:42 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 18 Sep 2025 02:51:42 GMT Subject: RFR: 8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 15:13:35 GMT, Ashutosh Mehra wrote: >> Support of `-XX:+AOTClassLinking` for dynamic CDS archive is not an documented feature of [JEP 483](https://openjdk.org/jeps/483). It has very small performance benefit and complicates the development of future AOT optimizations. >> >> After this PR, `-XX:+AOTClassLinking` will have no effect when creating a dynamic CDS archive. > > This looks good. Just wondering if we should report any message if `-XX:+AOTClassLinking` is specified when creating a dynamic archive? I think this patch silently ignores it. Thanks @ashu-mehra @vnkozlov for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/27242#issuecomment-3305216792 From iklam at openjdk.org Thu Sep 18 02:51:44 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 18 Sep 2025 02:51:44 GMT Subject: Integrated: 8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 03:31:02 GMT, Ioi Lam wrote: > Support of `-XX:+AOTClassLinking` for dynamic CDS archive is not an documented feature of [JEP 483](https://openjdk.org/jeps/483). It has very small performance benefit and complicates the development of future AOT optimizations. > > After this PR, `-XX:+AOTClassLinking` will have no effect when creating a dynamic CDS archive. This pull request has now been integrated. Changeset: 91a97943 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/91a979430e2516b5853c397a336837799928f478 Stats: 109 lines in 15 files changed: 15 ins; 68 del; 26 mod 8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive Reviewed-by: kvn, asmehra ------------- PR: https://git.openjdk.org/jdk/pull/27242 From lmesnik at openjdk.org Thu Sep 18 03:15:47 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 18 Sep 2025 03:15:47 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v10] In-Reply-To: <5iVFEcNvcbry683t2HizWDraAcyf9j39LAwnoM5rm0E=.7270f60d-5427-4d8c-a69a-75bf60bf5e98@github.com> References: <5iVFEcNvcbry683t2HizWDraAcyf9j39LAwnoM5rm0E=.7270f60d-5427-4d8c-a69a-75bf60bf5e98@github.com> Message-ID: On Thu, 18 Sep 2025 02:45:46 GMT, David Holmes wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> renamed method > > src/hotspot/share/runtime/suspendResumeManager.cpp line 84: > >> 82: } >> 83: >> 84: void SuspendResumeManager::set_suspended_current_thread(int64_t vthread_id, bool register_vthread_SR) { > > It was totally not at all apparent that `_target` had to be the current thread here! Is it always the current thread? Won't this variant only ever get called when `register_vthread_SR` would be true - in which case we don't need that parameter? The `set_suspended_current_thread` is called after check ` if (_target == self) {` in `void SuspendResumeManager::set_suspended_current_thread(int64_t vthread_id, bool register_vthread_SR) {` The goal of this specialized method is to "pre-load"`thread_id = _target->vthread()` before current thread became blocked. It is not planned to use this method for any other purpose. And the value 'register_vthread_SR' depends on which jvmti method is used : - true for SuspenAllVirutalThrreads - false for SuspendThread/SuspendThreadList In both cases we can try to suspend current thread. So this method is called in both cases, even thread_id is really used only for SuspenAllVirutalThrreads. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2357403213 From iklam at openjdk.org Thu Sep 18 03:35:19 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 18 Sep 2025 03:35:19 GMT Subject: RFR: 8362561: Remove diagnostic option AllowArchivingWithJavaAgent [v2] In-Reply-To: References: Message-ID: <4rXsdT80fqT4ZXSAbEjCVeIcLq42E8c8aZmaioXvMyU=.685afea0-beb1-44ea-a5e9-d0667f567c05@github.com> > Goal: simplify AOT implementation and removed unnecessary tests: > > This PR removes old CDS tests that use java agents during CDS dump (to increase test coverage by triggering conditions, such as GCs, that were not happening during usual `java -Xshare:dump` operations). > > Since AOT assembly is much more complex now, we have enough coverage. These old tests are no longer necessary. > > With these tests removed, we no longer need the `-XX:-AllowArchivingWithJavaAgent` diagnostic flag, which has been abused by users despite the warning that this flag should not be used in production. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into 8362561-remove-diagnostic-option-AllowArchivingWithJavaAgent - Added test case for dynamic archive with -javaagent - 8362561: Remove diagnostic option AllowArchivingWithJavaAgent ------------- Changes: https://git.openjdk.org/jdk/pull/27304/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27304&range=01 Stats: 1197 lines in 25 files changed: 41 ins; 1146 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/27304.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27304/head:pull/27304 PR: https://git.openjdk.org/jdk/pull/27304 From dholmes at openjdk.org Thu Sep 18 04:45:33 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 18 Sep 2025 04:45:33 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v10] In-Reply-To: References: <5iVFEcNvcbry683t2HizWDraAcyf9j39LAwnoM5rm0E=.7270f60d-5427-4d8c-a69a-75bf60bf5e98@github.com> Message-ID: On Thu, 18 Sep 2025 03:13:01 GMT, Leonid Mesnik wrote: >> src/hotspot/share/runtime/suspendResumeManager.cpp line 84: >> >>> 82: } >>> 83: >>> 84: void SuspendResumeManager::set_suspended_current_thread(int64_t vthread_id, bool register_vthread_SR) { >> >> It was totally not at all apparent that `_target` had to be the current thread here! Is it always the current thread? Won't this variant only ever get called when `register_vthread_SR` would be true - in which case we don't need that parameter? > > Yes, the purpose of this specialized method is to "pre-load"`thread_id = _target->vthread()` before current thread became blocked. It is not planned to use this method for any other purpose. > The `set_suspended_current_thread` is called after check > ` if (_target == self) {` in `void SuspendResumeManager::set_suspended_current_thread(int64_t vthread_id, bool register_vthread_SR) {` > > > And the value 'register_vthread_SR' doesn't correlate with this method. It depends on which jvmti method is used : > - true for SuspenAllVirutalThrreads > - false for SuspendThread/SuspendThreadList > In both cases we can try to suspend current thread. So this method is called in both cases, even thread_id is really used only for SuspenAllVirutalThrreads. > > Hope it makes clearer. Thanks - though I find this code rather convoluted. We now always extract the `id` even though we only need it in the `register_vthread_SR == true` case. I tried different re-arrangements of the code to see if it could be cleaner, but the JVMTI part is just messy. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2357499435 From dholmes at openjdk.org Thu Sep 18 04:45:36 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 18 Sep 2025 04:45:36 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v10] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 21:23:42 GMT, Leonid Mesnik wrote: >> The >> `SuspendResumeManager::suspend(bool register_vthread_SR)` >> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. >> >> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. >> >> The fix added some "asymmetry" in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > renamed method src/hotspot/share/runtime/suspendResumeManager.cpp line 88: > 86: if (register_vthread_SR) { > 87: assert(_target->is_vthread_mounted(), "sanity check"); > 88: assert(_target == JavaThread::current(), "should be current thread"); So this assert should be outside the INCLUDE_JVMTI section - right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2357499917 From iklam at openjdk.org Thu Sep 18 04:46:33 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 18 Sep 2025 04:46:33 GMT Subject: RFR: 8362561: Remove diagnostic option AllowArchivingWithJavaAgent [v2] In-Reply-To: <4rXsdT80fqT4ZXSAbEjCVeIcLq42E8c8aZmaioXvMyU=.685afea0-beb1-44ea-a5e9-d0667f567c05@github.com> References: <4rXsdT80fqT4ZXSAbEjCVeIcLq42E8c8aZmaioXvMyU=.685afea0-beb1-44ea-a5e9-d0667f567c05@github.com> Message-ID: On Thu, 18 Sep 2025 03:35:19 GMT, Ioi Lam wrote: >> Goal: simplify AOT implementation and removed unnecessary tests: >> >> This PR removes old CDS tests that use java agents during CDS dump (to increase test coverage by triggering conditions, such as GCs, that were not happening during usual `java -Xshare:dump` operations). >> >> Since AOT assembly is much more complex now, we have enough coverage. These old tests are no longer necessary. >> >> With these tests removed, we no longer need the `-XX:-AllowArchivingWithJavaAgent` diagnostic flag, which has been abused by users despite the warning that this flag should not be used in production. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into 8362561-remove-diagnostic-option-AllowArchivingWithJavaAgent > - Added test case for dynamic archive with -javaagent > - 8362561: Remove diagnostic option AllowArchivingWithJavaAgent I have merged manually to fix conflicts in TEST.groups. No other changes. Please re-review. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27304#issuecomment-3305406551 From lmesnik at openjdk.org Thu Sep 18 04:52:32 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 18 Sep 2025 04:52:32 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v10] In-Reply-To: References: <5iVFEcNvcbry683t2HizWDraAcyf9j39LAwnoM5rm0E=.7270f60d-5427-4d8c-a69a-75bf60bf5e98@github.com> Message-ID: On Thu, 18 Sep 2025 04:42:15 GMT, David Holmes wrote: >> Yes, the purpose of this specialized method is to "pre-load"`thread_id = _target->vthread()` before current thread became blocked. It is not planned to use this method for any other purpose. >> The `set_suspended_current_thread` is called after check >> ` if (_target == self) {` in `void SuspendResumeManager::set_suspended_current_thread(int64_t vthread_id, bool register_vthread_SR) {` >> >> >> And the value 'register_vthread_SR' doesn't correlate with this method. It depends on which jvmti method is used : >> - true for SuspenAllVirutalThrreads >> - false for SuspendThread/SuspendThreadList >> In both cases we can try to suspend current thread. So this method is called in both cases, even thread_id is really used only for SuspenAllVirutalThrreads. >> >> Hope it makes clearer. > > Thanks - though I find this code rather convoluted. We now always extract the `id` even though we only need it in the `register_vthread_SR == true` case. I tried different re-arrangements of the code to see if it could be cleaner, but the JVMTI part is just messy. Yes, the id is always extracted and the exposure of "raw" id on this level is not the good desing. However, I don't know how to implement this better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2357508462 From lmesnik at openjdk.org Thu Sep 18 05:12:14 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 18 Sep 2025 05:12:14 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v11] In-Reply-To: References: Message-ID: > The > `SuspendResumeManager::suspend(bool register_vthread_SR)` > has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. > > Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. > > The fix added some "asymmetry" in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: asseriton moved out ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27317/files - new: https://git.openjdk.org/jdk/pull/27317/files/d2587051..63392d0b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27317&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27317&range=09-10 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27317/head:pull/27317 PR: https://git.openjdk.org/jdk/pull/27317 From lmesnik at openjdk.org Thu Sep 18 05:12:16 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 18 Sep 2025 05:12:16 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v10] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 04:42:47 GMT, David Holmes wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> renamed method > > src/hotspot/share/runtime/suspendResumeManager.cpp line 88: > >> 86: if (register_vthread_SR) { >> 87: assert(_target->is_vthread_mounted(), "sanity check"); >> 88: assert(_target == JavaThread::current(), "should be current thread"); > > So this assert should be outside the INCLUDE_JVMTI section - right? ough, yes, should be outside INCLUDE_JVMTI However, I just can't understand how those methods could be called if JVMTI is not included. Do we still have any mechanisms to suspend thread without jvmti nowdays? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2357528204 From lmesnik at openjdk.org Thu Sep 18 05:16:33 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 18 Sep 2025 05:16:33 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v9] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 02:42:16 GMT, David Holmes wrote: >> Really the comment >> ```// Sets the suspended state to `to`, applying to vthreads if `register_vthread_SR` is true.``` >> looks incorrect to me. One might decide that the method doesn't set suspend state if for vthreads if `register_vthread_SR` is false. While the method always set suspend and might register or not vthreads to support SuspendAllVirtualThreads. > > Okay I was trying to understand exactly what these methods were doing but I'm finding it somewhat difficult to explain that. But my point is to document that the first method sets the state to true/false as directed, whilst the second always sets to true. But it gets harder to describe things when the id variant is only needed when `register_vthread_SR` is true. The `set_suspended` maintained _suspended flag for individual flags. While to support fast suspending of all virtual threads it uses additional mechanisms. So, it is rather `set_suspended_status` or something like this. I don't know what would be good name for this logic. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2357537396 From dholmes at openjdk.org Thu Sep 18 05:22:39 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 18 Sep 2025 05:22:39 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v6] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 14:59:05 GMT, Ivan Walulya wrote: >> Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. >> >> Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. >> >> Testing: Tier 1-7 > > Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - Revert > - Thomas Review > - return on timeout > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - timed wait > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - space > - remove debug logs > - ... and 3 more: https://git.openjdk.org/jdk/compare/d7eeacf2...ab94789c As this doesn't seem to perturb the general shutdown process I have no further comment and will leave it to GC folk to approve. Though I still wonder if this aspect of shutdown should be part of "Heap" (or Universe) rather than G1 specific. ------------- PR Review: https://git.openjdk.org/jdk/pull/27190#pullrequestreview-3237321918 From iwalulya at openjdk.org Thu Sep 18 05:25:46 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 18 Sep 2025 05:25:46 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v61] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 07:18:14 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * iwalulya review > * documentation for a few PSS members > * rename some member variables to contain _ct and _rt suffixes in remembered set verification LGTM! ------------- Marked as reviewed by iwalulya (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23739#pullrequestreview-3237327044 From dholmes at openjdk.org Thu Sep 18 05:44:33 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 18 Sep 2025 05:44:33 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v10] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 05:07:16 GMT, Leonid Mesnik wrote: >> src/hotspot/share/runtime/suspendResumeManager.cpp line 88: >> >>> 86: if (register_vthread_SR) { >>> 87: assert(_target->is_vthread_mounted(), "sanity check"); >>> 88: assert(_target == JavaThread::current(), "should be current thread"); >> >> So this assert should be outside the INCLUDE_JVMTI section - right? > > ough, > yes, should be outside INCLUDE_JVMTI > However, I just can't understand how those methods could be called if JVMTI is not included. Do we still have any mechanisms to suspend thread without jvmti nowdays? No we don't but we are left with a lot of historical code organization. JVMTI is the only client of the `JavaThread::java_suspend/java_resume` API but that code already existed independent of JVMTI. The current INCLUDE_JVMTI guards are what is needed to make a non-JVMTI configuration build. If we were so inclined we could push those guards right up to JavaThread and then exclude compiling files like `suspendResumeManager.cpp`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2357574737 From cstein at openjdk.org Thu Sep 18 05:54:50 2025 From: cstein at openjdk.org (Christian Stein) Date: Thu, 18 Sep 2025 05:54:50 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v6] In-Reply-To: References: Message-ID: > Please review the change to update to using jtreg 8. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Fix copyright header [skip ci] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26261/files - new: https://git.openjdk.org/jdk/pull/26261/files/7f2017b4..fd7bf6fd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26261&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26261&range=04-05 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26261.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26261/head:pull/26261 PR: https://git.openjdk.org/jdk/pull/26261 From jpai at openjdk.org Thu Sep 18 05:54:51 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 18 Sep 2025 05:54:51 GMT Subject: RFR: 8361950: Update to use jtreg 8 [v6] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 05:52:07 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 8. >> >> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright header > > [skip ci] The latest changes in `fd7bf6f` look good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26261#pullrequestreview-3237379113 From dholmes at openjdk.org Thu Sep 18 06:16:33 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 18 Sep 2025 06:16:33 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v10] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 05:42:01 GMT, David Holmes wrote: >> ough, >> yes, should be outside INCLUDE_JVMTI >> However, I just can't understand how those methods could be called if JVMTI is not included. Do we still have any mechanisms to suspend thread without jvmti nowdays? > > No we don't but we are left with a lot of historical code organization. JVMTI is the only client of the `JavaThread::java_suspend/java_resume` API but that code already existed independent of JVMTI. The current INCLUDE_JVMTI guards are what is needed to make a non-JVMTI configuration build. If we were so inclined we could push those guards right up to JavaThread and then exclude compiling files like `suspendResumeManager.cpp`. Except the notion of "suspend" permeates the handshake code and is impossible to disentangle. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2357624527 From sjohanss at openjdk.org Thu Sep 18 06:38:53 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Thu, 18 Sep 2025 06:38:53 GMT Subject: RFR: 8360651: Create OSContainer API for memory limit [v2] In-Reply-To: References: Message-ID: <4Awg5IrIFcuTz0E9RhPMRCz08Qam_zZZHa3X58PwC60=.9ac226e2-f1d2-4d8e-ba93-815be4bde6f0@github.com> On Mon, 8 Sep 2025 17:54:10 GMT, Severin Gehwolf wrote: >> Please review this small addition to add a new `OSContainer::has_memory_limit()` API (Linux only - as with the entire OSContainer API) in preparation for [JDK-8350596](https://bugs.openjdk.org/browse/JDK-8350596) which proposes to increase the default `MaxRAMPercentage` when this new API returns true. The patch is pretty trivial. It's only the testing which amounts to the most lines in this patch. >> >> Testing: >> - [x] GHA >> - [x] Hotspot container tests on x86_64 Linux on cgroup v1 and cgroup v2 (including the new tests). >> >> Thoughts? > > Severin Gehwolf 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 four additional commits since the last revision: > > - Merge branch 'master' into jdk-8360651-mem-limit-api > - MemoryLimitTest whitespace fixes. > - TestContainerMemory whitespace fixes. > - 8360651: Create OSContainer API for memory limit Is it correct to only look at `memory_limit_in_bytes()`? We also have `memory_and_swap_limit_in_bytes()` and `memory_soft_limit_in_bytes()`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26020#issuecomment-3305624187 From rcastanedalo at openjdk.org Thu Sep 18 07:06:36 2025 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 18 Sep 2025 07:06:36 GMT Subject: RFR: 8359378: aarch64: crash when using -XX:+UseFPUForSpilling In-Reply-To: <0MbLaZYRoz-raa9x1eZycxeHE7mvPiGJujQpg8vBdek=.e3483c47-ad65-4d09-baf5-2db9b780669d@github.com> References: <0MbLaZYRoz-raa9x1eZycxeHE7mvPiGJujQpg8vBdek=.e3483c47-ad65-4d09-baf5-2db9b780669d@github.com> Message-ID: On Wed, 17 Sep 2025 16:19:12 GMT, Boris Ulasevich wrote: > AArch64 BarrierSetAssembler path assumes only FP/vector ideal regs reach the FP spill/restore encoding. With -XX:+UseFPUForSpilling Register Allocator may allocate scalar values in FP registers. When such values (Op_RegI/Op_RegN/Op_RegL/Op_RegP) hit `BarrierSetAssembler::encode_float_vector_register_size`, we trip ShouldNotReachHere in release build and **"unexpected ideal register"** assertion in debug build. > > Fix: teach the encoder to handle scalar ideal regs when they physically live in FP regs: > - treat Op_RegI / Op_RegN as 32-bit (single slot) - same class as Op_RegF > - treat Op_RegL / Op_RegP as 64-bit (two slots) - same class as Op_RegD > > Related: > - reproduced since #19746 > - spilling logic: > - #18967 > - #17977 > > Testing: tier1-3 with javaoptions -Xcomp -Xbatch -XX:+UseFPUForSpilling on AARCH Hi @bulasevich, thanks for working on this issue, but please note that it was already assigned to me ([JDK-8359378](https://bugs.openjdk.org/browse/JDK-8359378)). I am fine with re-assigning it to you, but [next time please ask first, to avoid work duplication](https://openjdk.org/guide/#i-found-an-issue-in-jbs-that-i-want-to-fix). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27350#issuecomment-3305714305 From tschatzl at openjdk.org Thu Sep 18 07:39:27 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 18 Sep 2025 07:39:27 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v59] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 07:38:56 GMT, Fei Yang wrote: >>> @tschatzl : Hi, would you mind adding a small cleanup change for riscv? This also adds back the assertion about the registers. Still test good on linux-riscv64 platform. [riscv-addon.diff.txt](https://github.com/user-attachments/files/22356611/riscv-addon.diff.txt) >> >> This is the `end` -> `count` transformation in the barrier I suggested earlier for RISC-V, isn't it? Thanks for contributing that, but would you mind me holding off this until @theRealAph acks that similar change for aarch64? It would be unfortunate imo if the implementations diverge too much. > >> > @tschatzl : Hi, would you mind adding a small cleanup change for riscv? This also adds back the assertion about the registers. Still test good on linux-riscv64 platform. [riscv-addon.diff.txt](https://github.com/user-attachments/files/22356611/riscv-addon.diff.txt) >> >> This is the `end` -> `count` transformation in the barrier I suggested earlier for RISC-V, isn't it? Thanks for contributing that, but would you mind me holding off this until @theRealAph acks that similar change for aarch64? It would be unfortunate imo if the implementations diverge too much. > > Yes, sure! The purpose is to minimize the difference to avoid possible issues in the future. @RealFYang : going to wait for the response of @theRealAph about the `end->count` matter until early next week, otherwise I'll move this change to cleanups/further enhancements like (JDK-8352069)[https://bugs.openjdk.org/browse/JDK-8352069] already planned. Just want to be "done" at some point with this change :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3305851845 From jsjolen at openjdk.org Thu Sep 18 07:41:31 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 18 Sep 2025 07:41:31 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v5] In-Reply-To: References: Message-ID: > Hi, > > This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array` to store the offsets in and an `Array` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`. > > We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately. > > For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc. > > On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement. > > Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Fix rename ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27198/files - new: https://git.openjdk.org/jdk/pull/27198/files/0e292522..6f47508b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=03-04 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27198/head:pull/27198 PR: https://git.openjdk.org/jdk/pull/27198 From azafari at openjdk.org Thu Sep 18 07:46:21 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 18 Sep 2025 07:46:21 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v5] In-Reply-To: References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: On Wed, 17 Sep 2025 08:01:36 GMT, Axel Boldt-Christmas wrote: > What is the reasoning behind using `uint64_t` rather than `uintptr_t`? I follow (IIUC) your comments on replacing uintptr_t and uint64_t because of differences in platforms. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3305900059 From shade at openjdk.org Thu Sep 18 07:51:23 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 18 Sep 2025 07:51:23 GMT Subject: RFR: 8362561: Remove diagnostic option AllowArchivingWithJavaAgent [v2] In-Reply-To: <4rXsdT80fqT4ZXSAbEjCVeIcLq42E8c8aZmaioXvMyU=.685afea0-beb1-44ea-a5e9-d0667f567c05@github.com> References: <4rXsdT80fqT4ZXSAbEjCVeIcLq42E8c8aZmaioXvMyU=.685afea0-beb1-44ea-a5e9-d0667f567c05@github.com> Message-ID: On Thu, 18 Sep 2025 03:35:19 GMT, Ioi Lam wrote: >> Goal: simplify AOT implementation and removed unnecessary tests: >> >> This PR removes old CDS tests that use java agents during CDS dump (to increase test coverage by triggering conditions, such as GCs, that were not happening during usual `java -Xshare:dump` operations). >> >> Since AOT assembly is much more complex now, we have enough coverage. These old tests are no longer necessary. >> >> With these tests removed, we no longer need the `-XX:-AllowArchivingWithJavaAgent` diagnostic flag, which has been abused by users despite the warning that this flag should not be used in production. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into 8362561-remove-diagnostic-option-AllowArchivingWithJavaAgent > - Added test case for dynamic archive with -javaagent > - 8362561: Remove diagnostic option AllowArchivingWithJavaAgent Looks reasonable. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27304#pullrequestreview-3237906570 From aph at openjdk.org Thu Sep 18 07:53:06 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 18 Sep 2025 07:53:06 GMT Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1 volatile field loads [v2] In-Reply-To: References: Message-ID: <7rOmFYwzssNyo-r4sU_9563VootV4M61h-6MYsNU7Zc=.23d773f2-43a3-4ea0-8a1d-f1b740bdcdbb@github.com> On Wed, 20 Aug 2025 12:37:27 GMT, Samuel Chee wrote: >> Samuel Chee has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address review comments >> >> Change-Id: Ica13be8094ac0f057066042ef0a5ec5927b98dfd >> - Refine code generation for mem2reg_volatile >> >> The patch is contributed by @theRealAph. >> >> Change-Id: I7ab1854dd238cdce72a4ab218b5b4ee84ad39586 > > Also have just finished running jcstress and it seems to pass fine. @spchee , are you still working on this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26748#issuecomment-3305931445 From aph at openjdk.org Thu Sep 18 08:03:18 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 18 Sep 2025 08:03:18 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v55] In-Reply-To: <63y80KoZ7oXdnFLRmK28Z8wcOSSAMXHx91akDn0tcLc=.981add6e-0b3f-423f-9b5f-87bb7d9fad9a@github.com> References: <63y80KoZ7oXdnFLRmK28Z8wcOSSAMXHx91akDn0tcLc=.981add6e-0b3f-423f-9b5f-87bb7d9fad9a@github.com> Message-ID: On Fri, 12 Sep 2025 08:27:01 GMT, Martin Doerr wrote: > Other idea: set count = noreg to prevent usage after it is used under the other name. That wouldn't have solved the aliasing problem, because count and end were being used as aliases for a register in _the same instruction_! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2357941045 From kevinw at openjdk.org Thu Sep 18 08:03:04 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 18 Sep 2025 08:03:04 GMT Subject: RFR: 8367689: Revert removal of several compilation-related vmStructs fields [v3] In-Reply-To: <7zcjZi3Kb4EoOhhH5hDHdAkJ_YvwbDNwn0VjveCwmno=.c8a860fa-ef49-474e-b7cb-cb82ed7f229b@github.com> References: <7zcjZi3Kb4EoOhhH5hDHdAkJ_YvwbDNwn0VjveCwmno=.c8a860fa-ef49-474e-b7cb-cb82ed7f229b@github.com> Message-ID: On Wed, 17 Sep 2025 18:54:19 GMT, Francesco Andreuzzi wrote: >> #23782 ([JDK-8315488](https://bugs.openjdk.org/browse/JDK-8315488)) removed several vmStructs fields. A small subset was used in Async-Profiler: >> >> CiEnv* _env >> CompileTask* _task >> ciMethod* _method >> >> >> I propose a small patch to bring them back. It helps third-party tools in building useful features on the JDK. For example, Async-Profiler uses these fields to display the current method being compiled in a compiler thread. > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > comment src/hotspot/share/runtime/vmStructs.cpp line 673: > 671: /* to ease their migration to a future alternative. */ \ > 672: /******************************************************************************************/ \ > 673: \ oops just a missing close ), but yes other than that I think we're done 8-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27318#discussion_r2357942557 From aph at openjdk.org Thu Sep 18 08:03:17 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 18 Sep 2025 08:03:17 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v61] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 07:18:14 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * iwalulya review > * documentation for a few PSS members > * rename some member variables to contain _ct and _rt suffixes in remembered set verification Marked as reviewed by aph (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/23739#pullrequestreview-3237979731 From fandreuzzi at openjdk.org Thu Sep 18 08:18:49 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 18 Sep 2025 08:18:49 GMT Subject: RFR: 8367689: Revert removal of several compilation-related vmStructs fields [v4] In-Reply-To: References: Message-ID: > #23782 ([JDK-8315488](https://bugs.openjdk.org/browse/JDK-8315488)) removed several vmStructs fields. A small subset was used in Async-Profiler: > > CiEnv* _env > CompileTask* _task > ciMethod* _method > > > I propose a small patch to bring them back. It helps third-party tools in building useful features on the JDK. For example, Async-Profiler uses these fields to display the current method being compiled in a compiler thread. Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: missing close ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27318/files - new: https://git.openjdk.org/jdk/pull/27318/files/194a9d6f..d7c4db00 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27318&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27318&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27318.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27318/head:pull/27318 PR: https://git.openjdk.org/jdk/pull/27318 From kevinw at openjdk.org Thu Sep 18 08:18:49 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 18 Sep 2025 08:18:49 GMT Subject: RFR: 8367689: Revert removal of several compilation-related vmStructs fields [v4] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 08:15:26 GMT, Francesco Andreuzzi wrote: >> #23782 ([JDK-8315488](https://bugs.openjdk.org/browse/JDK-8315488)) removed several vmStructs fields. A small subset was used in Async-Profiler: >> >> CiEnv* _env >> CompileTask* _task >> ciMethod* _method >> >> >> I propose a small patch to bring them back. It helps third-party tools in building useful features on the JDK. For example, Async-Profiler uses these fields to display the current method being compiled in a compiler thread. > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > missing close OK, thanks! ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27318#pullrequestreview-3238053151 From duke at openjdk.org Thu Sep 18 08:18:51 2025 From: duke at openjdk.org (duke) Date: Thu, 18 Sep 2025 08:18:51 GMT Subject: RFR: 8367689: Revert removal of several compilation-related vmStructs fields [v3] In-Reply-To: <7zcjZi3Kb4EoOhhH5hDHdAkJ_YvwbDNwn0VjveCwmno=.c8a860fa-ef49-474e-b7cb-cb82ed7f229b@github.com> References: <7zcjZi3Kb4EoOhhH5hDHdAkJ_YvwbDNwn0VjveCwmno=.c8a860fa-ef49-474e-b7cb-cb82ed7f229b@github.com> Message-ID: On Wed, 17 Sep 2025 18:54:19 GMT, Francesco Andreuzzi wrote: >> #23782 ([JDK-8315488](https://bugs.openjdk.org/browse/JDK-8315488)) removed several vmStructs fields. A small subset was used in Async-Profiler: >> >> CiEnv* _env >> CompileTask* _task >> ciMethod* _method >> >> >> I propose a small patch to bring them back. It helps third-party tools in building useful features on the JDK. For example, Async-Profiler uses these fields to display the current method being compiled in a compiler thread. > > Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: > > comment @fandreuz Your change (at version d7c4db008e15d00889ebacf9acc2d48689d2402e) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27318#issuecomment-3306071264 From fandreuzzi at openjdk.org Thu Sep 18 08:18:53 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 18 Sep 2025 08:18:53 GMT Subject: RFR: 8367689: Revert removal of several compilation-related vmStructs fields [v3] In-Reply-To: References: <7zcjZi3Kb4EoOhhH5hDHdAkJ_YvwbDNwn0VjveCwmno=.c8a860fa-ef49-474e-b7cb-cb82ed7f229b@github.com> Message-ID: On Thu, 18 Sep 2025 08:00:37 GMT, Kevin Walls wrote: >> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: >> >> comment > > src/hotspot/share/runtime/vmStructs.cpp line 673: > >> 671: /* to ease their migration to a future alternative. */ \ >> 672: /******************************************************************************************/ \ >> 673: \ > > oops just a missing close ), but yes other than that I think we're done 8-) Thanks, fixed in d7c4db008e15d00889ebacf9acc2d48689d2402e ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27318#discussion_r2357974342 From azafari at openjdk.org Thu Sep 18 08:25:16 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 18 Sep 2025 08:25:16 GMT Subject: RFR: 8367249: [REDO] MemBaseline accesses VMT without using lock [v5] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 15:42:10 GMT, Johan Sj?len wrote: >> Hi, >> >> This is a REDO, as the previous attempt caused build failures when merged with latest master. >> The only difference is that the copy ctr for the RBTRee had been integrated with a different PR, but it never should have been. I deleted the copy ctr. >> >> Thanks. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > How did this even work in any release build? The changes in `VMATree::copy_into` of this PR, are only seen if we test/check the allocation_sites after a baseline. As I checked the gTest/JTREG tests, none of them check the sites that is written out to the report. So, the code for `copy_into` is never run in release builds and no allocation_site will be stored in a baseline nor written out in the report. No test will check it to discover it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27170#issuecomment-3306125209 From fandreuzzi at openjdk.org Thu Sep 18 08:28:41 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 18 Sep 2025 08:28:41 GMT Subject: Integrated: 8367689: Revert removal of several compilation-related vmStructs fields In-Reply-To: References: Message-ID: <3VJwDsTsSPLGMQYO_0KlqXnL8HAttwGAQUm-1u315Uc=.b2ca96b1-c7ca-4a9e-890a-19b4283688b2@github.com> On Tue, 16 Sep 2025 16:40:05 GMT, Francesco Andreuzzi wrote: > #23782 ([JDK-8315488](https://bugs.openjdk.org/browse/JDK-8315488)) removed several vmStructs fields. A small subset was used in Async-Profiler: > > CiEnv* _env > CompileTask* _task > ciMethod* _method > > > I propose a small patch to bring them back. It helps third-party tools in building useful features on the JDK. For example, Async-Profiler uses these fields to display the current method being compiled in a compiler thread. This pull request has now been integrated. Changeset: 4c5e901c Author: Francesco Andreuzzi Committer: Kevin Walls URL: https://git.openjdk.org/jdk/commit/4c5e901c96dee3885e1b29a53d3400174f9bba09 Stats: 15 lines in 2 files changed: 15 ins; 0 del; 0 mod 8367689: Revert removal of several compilation-related vmStructs fields Reviewed-by: kevinw, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/27318 From azafari at openjdk.org Thu Sep 18 08:52:23 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 18 Sep 2025 08:52:23 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v5] In-Reply-To: References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: On Tue, 16 Sep 2025 09:06:42 GMT, Afshin Zafari wrote: >> The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. >> The acceptable value is changed to 64K. >> >> Tests: >> linux-x64 tier1 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > uintptr_t -> uint64_t I used `uintptr_t` for addresses, but there are pre-existing uses of `uint64_t` in the code that are used for addresses: #define SIZE_64K ((uint64_t) UCONST64( 0x10000)) #define SIZE_256M ((uint64_t) UCONST64( 0x10000000)) #define SIZE_32G ((uint64_t) UCONST64( 0x800000000)) // Helper for heap allocation. Returns an array with addresses // (OS-specific) which are suited for disjoint base mode. Array is // null terminated. static char** get_attach_addresses_for_disjoint_mode() { static uint64_t addresses[] = {``` > f anything the pre-existing type of `unscaled_end` may be wrong. Because end makes sound like an address in this context, but it is describing an offset. And is only used to check for an underflow before we may reinterpret it as an address (0 + offset). > > That part I think would read much better by checking for the underflow first: > > ```c++ > uintptr_t lowest_start = aligned_heap_base_min_address; > if (size <= UnscaledOopHeapMax) { > lowest_start = MAX2(lowest_start, UnscaledOopHeapMax - size); > } > lowest_start = align_up(lowest_start, attach_point_alignment); > ``` Done. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3306322492 PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3306327411 From azafari at openjdk.org Thu Sep 18 08:57:48 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 18 Sep 2025 08:57:48 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v6] In-Reply-To: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: > The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. > The acceptable value is changed to 64K. > > Tests: > linux-x64 tier1 Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: fixes. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26955/files - new: https://git.openjdk.org/jdk/pull/26955/files/fffb77a4..649f59d2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=04-05 Stats: 11 lines in 1 file changed: 0 ins; 1 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/26955.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26955/head:pull/26955 PR: https://git.openjdk.org/jdk/pull/26955 From azafari at openjdk.org Thu Sep 18 08:57:50 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 18 Sep 2025 08:57:50 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v5] In-Reply-To: References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: <5CIoOI6iDMRNQqfhVURZIQZ30sEVBOKbDBFrXXEMvTo=.389fadc8-720d-41b9-8754-b6ef082615c7@github.com> On Wed, 17 Sep 2025 08:01:36 GMT, Axel Boldt-Christmas wrote: > I think the use of `uint64_t` stems from the `UnscaledOopHeapMax` and `OopEncodingHeapMax` being typed as such. Unclear to me why they are not just `size_t`, as coops is a 64-bit VM feature. Same to me. There are some/many cases of mixing type arithmetic like ` address + size_t < uint64_t`. It may not be any problem, but it'd been better if we can define a coding rule for these cases. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3306342645 From ayang at openjdk.org Thu Sep 18 09:07:23 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 18 Sep 2025 09:07:23 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v6] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 05:19:25 GMT, David Holmes wrote: > Though I still wonder if this aspect of shutdown should be part of "Heap" (or Universe) rather than G1 specific. Why is it G1 specific? The new `bool _is_shutting_down` lives inside `CollectedHeap` -- Serial/Parallel/G1 are all updated to use it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27190#issuecomment-3306378857 From jsjolen at openjdk.org Thu Sep 18 09:10:30 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 18 Sep 2025 09:10:30 GMT Subject: RFR: 8367249: [REDO] MemBaseline accesses VMT without using lock [v4] In-Reply-To: References: <-yNuE19yVGNMaxSrIkcE4GuUZlnzOAKB6lZrQ0XZGII=.3a86413a-bcf0-4a6d-be1a-ebd995b564a2@github.com> Message-ID: <741YdwqE2wsCYXJvYZROn_TPpOqjxR_9U6XAH2Q68mM=.ccdaa623-6263-4981-adc6-f1d0220b790e@github.com> On Thu, 18 Sep 2025 00:12:20 GMT, Jiangli Zhou wrote: >> Well, that was a very embarrassing bug :-). I had code in an `assert` which needed to run regardless if in a debug build or not. Why didn't all release builds fail? No clue. > >> I had code in an `assert` which needed to run regardless if in a debug build or not. Why didn't all release builds fail? No clue. > > The GHA teir1 testing on static JDK is only enabled for release builds currently. We haven't setup testing on debug builds for static JDK due to resource limit in GHA build environment. @magicus and the build team have solution(s) to address the issue with https://bugs.openjdk.org/browse/JDK-8350450. > > Hi @jianglizhou , > > There's a test failure that only appears in linux-x64-static tier1. I'm looking at running the tests under the static-jdk. So far, I've produced a static-jdk via `make CONF=slow static-jdk-image`. Do you happen to know how to execute the tier1 tests with such a JDK? > > I've tried `make JDK_UNDER_TEST=build/linux-x64-slowdebug/images/static-jdk/ test TEST=tier1` but it complains about JDK_UNDER_TEST not being a non-control variable. > > Hi @jdksjolen, to run jtreg tests on a `static-jdk` binary, you can set `JDK_FOR_COMPILE=`, `JDK_FOR_COMPILE=` and `extra-problem-lists` options in jtreg command line. The GHA testing on static JDK setup those to run tier1 tests: > > https://github.com/openjdk/jdk/blob/aa36799acb5834d730400fb073a9a3a8ee3c28ef/.github/workflows/test.yml#L185 > > https://bugs.openjdk.org/browse/JDK-8303796?focusedId=14745789&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14745789 has a command line example for running tier1 tests on static-jdk. > > To build a static JDK: `make static-jdk-image`. > > Hope those are helpful. Thank you for your help! I did something akin to this, and it worked: $ make CONF=linux-x64 static-jdk-image $ make CONF=linux-x64 jdk-image $ make CONF=linux-x64 JDK_FOR_COMPILE='/home/jsjolen/jdk/build/linux-x64/images/jdk/' JDK_UNDER_TEST=/home/jsjolen/jdk/build/linux-x64/images/static-jdk/ test TEST='jtreg:runtime/NMT/ThreadedVirtualAllocTestType.java' This did reproduce the test failure on linux-x64-static :-). > The changes in `VMATree::copy_into` of this PR, are only seen if we test/check the allocation_sites after a baseline. As I checked the gTest/JTREG tests, none of them check the sites that is written out to the report. So, the code for `copy_into` is never run in release builds and no allocation_site will be stored in a baseline nor written out in the report. No test will check it to discover it. The test `ThreadedVirtualAllocTestType` does run NMT under detailed mode and was tested in release for all platforms. This was the one that failed in linux-x64-static. The weird thing is that the test succeeded in all other release platforms, even though they should have had the same assert problem. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27170#issuecomment-3306388800 From sgehwolf at openjdk.org Thu Sep 18 09:16:42 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 18 Sep 2025 09:16:42 GMT Subject: RFR: 8360651: Create OSContainer API for memory limit [v2] In-Reply-To: <4Awg5IrIFcuTz0E9RhPMRCz08Qam_zZZHa3X58PwC60=.9ac226e2-f1d2-4d8e-ba93-815be4bde6f0@github.com> References: <4Awg5IrIFcuTz0E9RhPMRCz08Qam_zZZHa3X58PwC60=.9ac226e2-f1d2-4d8e-ba93-815be4bde6f0@github.com> Message-ID: <0_YebDJnzFfU4XyklQyUnWkYY2Nu2mtZTcdlB4ypxaA=.c860f4ec-8dcc-441c-ba4d-2c7b6ca50fec@github.com> On Thu, 18 Sep 2025 06:35:54 GMT, Stefan Johansson wrote: > Is it correct to only look at `memory_limit_in_bytes()`? We also have `memory_and_swap_limit_in_bytes()` and `memory_soft_limit_in_bytes()`. Only `memory_limit_in_bytes()` is being used for the `os::physical_memory()` calculation when in a container. So yes. We should only bump MaxRAMPercentage when that's changed. `memory_and_swap_limit_in_bytes` is strictly `>= memory_limit_in_bytes`. `memory_soft_limit_in_bytes` is informative only. Showing up in `hs_error` files and `VM.info` output. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26020#issuecomment-3306409598 From jsjolen at openjdk.org Thu Sep 18 09:20:18 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 18 Sep 2025 09:20:18 GMT Subject: RFR: 8367249: [REDO] MemBaseline accesses VMT without using lock [v6] In-Reply-To: References: Message-ID: <1rc6_LNVUKcswi210ITCC8dND2a2h29jCQWH33dfzHU=.e37e11b3-7a3d-48ac-a5ee-a1c52f0933d7@github.com> > Hi, > > This is a REDO, as the previous attempt caused build failures when merged with latest master. > The only difference is that the copy ctr for the RBTRee had been integrated with a different PR, but it never should have been. I deleted the copy ctr. > > Thanks. Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: - Merge remote-tracking branch 'openjdk/master' into cleanup-membaseline - How did this even work in any release build? - const-ify a bit - Fix the rest of the incorrect instances - Merge remote-tracking branch 'openjdk/master' into cleanup-membaseline - Delete unneeded copy ctr - Merge remote-tracking branch 'openjdk/master' into cleanup-membaseline - Missed const-ness - Move into rbTree.inline.hpp file - Merge remote-tracking branch 'openjdk/master' into cleanup-membaseline - ... and 15 more: https://git.openjdk.org/jdk/compare/4c7c009d...993416dc ------------- Changes: https://git.openjdk.org/jdk/pull/27170/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27170&range=05 Stats: 239 lines in 12 files changed: 163 ins; 50 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/27170.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27170/head:pull/27170 PR: https://git.openjdk.org/jdk/pull/27170 From azafari at openjdk.org Thu Sep 18 09:26:12 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 18 Sep 2025 09:26:12 GMT Subject: RFR: 8367249: [REDO] MemBaseline accesses VMT without using lock [v6] In-Reply-To: <1rc6_LNVUKcswi210ITCC8dND2a2h29jCQWH33dfzHU=.e37e11b3-7a3d-48ac-a5ee-a1c52f0933d7@github.com> References: <1rc6_LNVUKcswi210ITCC8dND2a2h29jCQWH33dfzHU=.e37e11b3-7a3d-48ac-a5ee-a1c52f0933d7@github.com> Message-ID: On Thu, 18 Sep 2025 09:20:18 GMT, Johan Sj?len wrote: >> Hi, >> >> This is a REDO, as the previous attempt caused build failures when merged with latest master. >> The only difference is that the copy ctr for the RBTRee had been integrated with a different PR, but it never should have been. I deleted the copy ctr. >> >> Thanks. > > Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: > > - Merge remote-tracking branch 'openjdk/master' into cleanup-membaseline > - How did this even work in any release build? > - const-ify a bit > - Fix the rest of the incorrect instances > - Merge remote-tracking branch 'openjdk/master' into cleanup-membaseline > - Delete unneeded copy ctr > - Merge remote-tracking branch 'openjdk/master' into cleanup-membaseline > - Missed const-ness > - Move into rbTree.inline.hpp file > - Merge remote-tracking branch 'openjdk/master' into cleanup-membaseline > - ... and 15 more: https://git.openjdk.org/jdk/compare/4c7c009d...993416dc Good that you found the problem. Thanks. ------------- Marked as reviewed by azafari (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27170#pullrequestreview-3238409248 From sjohanss at openjdk.org Thu Sep 18 09:40:28 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Thu, 18 Sep 2025 09:40:28 GMT Subject: RFR: 8360651: Create OSContainer API for memory limit [v2] In-Reply-To: <0_YebDJnzFfU4XyklQyUnWkYY2Nu2mtZTcdlB4ypxaA=.c860f4ec-8dcc-441c-ba4d-2c7b6ca50fec@github.com> References: <4Awg5IrIFcuTz0E9RhPMRCz08Qam_zZZHa3X58PwC60=.9ac226e2-f1d2-4d8e-ba93-815be4bde6f0@github.com> <0_YebDJnzFfU4XyklQyUnWkYY2Nu2mtZTcdlB4ypxaA=.c860f4ec-8dcc-441c-ba4d-2c7b6ca50fec@github.com> Message-ID: On Thu, 18 Sep 2025 09:13:45 GMT, Severin Gehwolf wrote: > Only `memory_limit_in_bytes()` is being used for the `os::physical_memory()` calculation when in a container. So yes. We should only bump MaxRAMPercentage when that's changed. Thanks for the clarification, makes sense. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26020#issuecomment-3306494180 From amitkumar at openjdk.org Thu Sep 18 10:21:16 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 18 Sep 2025 10:21:16 GMT Subject: RFR: 8367325: [s390x] build failure due to JDK-8361376 [v4] In-Reply-To: References: Message-ID: <_q9_SaNqO8fLIfsbtDFD1LuqqfMv11wXm_X9yNPfVyU=.61d3faf9-a02f-433f-921c-3f8abad96346@github.com> > Fixes the SIGLL caused after [JDK-8361376](https://bugs.openjdk.org/browse/JDK-8361376). > > Issue was with `cs` instruction, which requires the address to be aligned. And after this change address at which operating was not aligned. > > Wisdom from Principle of Z Operations: > > Sytax: CS R1,R3,D2(B2) > > Sytax: CSY R1,R3,D2(B2) > > ` > The second operand of COMPARE AND SWAP (CS, CSY) must be designated on a word boundary. > ` > > > > => 0x3fffc3149ba <_ZN17BarrierSetNMethod15set_guard_valueEP7nmethodii+266>: cs %r1,%r4,0(%r3) > (gdb) i r r3 > r3 0x3ffe500017a 4397593526650 > (gdb) p ($r3 % 8) > $5 = 2 > (gdb) si > > Thread 16 "C1 CompilerThre" received signal SIGILL, Illegal instruction. > NativeMethodBarrier::set_guard_value (bit_mask=2147483647, value=1, this=0x3ffe5000166) > at /home/amit/jdk/src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp:74 > 74 if (v == old_value) break; Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: refactor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27213/files - new: https://git.openjdk.org/jdk/pull/27213/files/d7d27bc8..e328dccb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27213&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27213&range=02-03 Stats: 24 lines in 3 files changed: 13 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/27213.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27213/head:pull/27213 PR: https://git.openjdk.org/jdk/pull/27213 From mdoerr at openjdk.org Thu Sep 18 10:28:41 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 18 Sep 2025 10:28:41 GMT Subject: RFR: 8367325: [s390x] build failure due to JDK-8361376 [v4] In-Reply-To: <_q9_SaNqO8fLIfsbtDFD1LuqqfMv11wXm_X9yNPfVyU=.61d3faf9-a02f-433f-921c-3f8abad96346@github.com> References: <_q9_SaNqO8fLIfsbtDFD1LuqqfMv11wXm_X9yNPfVyU=.61d3faf9-a02f-433f-921c-3f8abad96346@github.com> Message-ID: <9thXZIz-9XDVOhvkflDfW4tIt_SIPDUNi5-r1mOisOw=.c2070092-b3a7-4198-a5a6-77b8e2b69919@github.com> On Thu, 18 Sep 2025 10:21:16 GMT, Amit Kumar wrote: >> Fixes the SIGLL caused after [JDK-8361376](https://bugs.openjdk.org/browse/JDK-8361376). >> >> Issue was with `cs` instruction, which requires the address to be aligned. And after this change address at which operating was not aligned. >> >> Wisdom from Principle of Z Operations: >> >> Sytax: CS R1,R3,D2(B2) >> >> Sytax: CSY R1,R3,D2(B2) >> >> ` >> The second operand of COMPARE AND SWAP (CS, CSY) must be designated on a word boundary. >> ` >> >> >> >> => 0x3fffc3149ba <_ZN17BarrierSetNMethod15set_guard_valueEP7nmethodii+266>: cs %r1,%r4,0(%r3) >> (gdb) i r r3 >> r3 0x3ffe500017a 4397593526650 >> (gdb) p ($r3 % 8) >> $5 = 2 >> (gdb) si >> >> Thread 16 "C1 CompilerThre" received signal SIGILL, Illegal instruction. >> NativeMethodBarrier::set_guard_value (bit_mask=2147483647, value=1, this=0x3ffe5000166) >> at /home/amit/jdk/src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp:74 >> 74 if (v == old_value) break; > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > refactor src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp line 174: > 172: void BarrierSetAssembler::nmethod_entry_barrier(MacroAssembler* masm) { > 173: BarrierSetNMethod* bs_nm = BarrierSet::barrier_set()->barrier_set_nmethod(); > 174: __ align(4, __ offset() + BARRIER_TOTAL_LENGTH); // must align the following block which requires atomic updates Now, this is confusing. We don't want to align the end of the barrier. We need to align the patchable field which is the immediate field of the cfi instruction. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27213#discussion_r2358407462 From sjohanss at openjdk.org Thu Sep 18 10:39:58 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Thu, 18 Sep 2025 10:39:58 GMT Subject: RFR: 8360651: Create OSContainer API for memory limit [v2] In-Reply-To: References: Message-ID: <7XSB57f_DXZSJ4lN7UYkAD4ATp9pqXZheANqOiWfnp8=.1decc855-e6ef-47b2-bc47-655b49b4470b@github.com> On Mon, 8 Sep 2025 17:54:10 GMT, Severin Gehwolf wrote: >> Please review this small addition to add a new `OSContainer::has_memory_limit()` API (Linux only - as with the entire OSContainer API) in preparation for [JDK-8350596](https://bugs.openjdk.org/browse/JDK-8350596) which proposes to increase the default `MaxRAMPercentage` when this new API returns true. The patch is pretty trivial. It's only the testing which amounts to the most lines in this patch. >> >> Testing: >> - [x] GHA >> - [x] Hotspot container tests on x86_64 Linux on cgroup v1 and cgroup v2 (including the new tests). >> >> Thoughts? > > Severin Gehwolf 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 four additional commits since the last revision: > > - Merge branch 'master' into jdk-8360651-mem-limit-api > - MemoryLimitTest whitespace fixes. > - TestContainerMemory whitespace fixes. > - 8360651: Create OSContainer API for memory limit If you agree with my cleanup suggestion below feel free to incorporate it. Otherwise I'm ok with the change as is. src/hotspot/os/linux/osContainer_linux.cpp line 81: > 79: bool any_mem_cpu_limit_present = false; > 80: bool controllers_read_only = cgroup_subsystem->is_containerized(); > 81: _has_memory_limit = cgroup_subsystem->memory_limit_in_bytes() > 0; I found those local `bool` a bit confusing and I don't really think they are needed. Played around a bit with also adding a _has_cpu_limit and ended up with the code below. To me that's a bit more readable, but a slightly larger change also adding has_cpu_limit. What do you think? * Step 1.) covers the basic in container use-cases. Step 2.) ensures * that limits enforced by other means (e.g. systemd slice) are properly * detected. */ check_and_set_limits(); const char *reason; if (cgroup_subsystem->is_containerized()) { // in-container case _is_containerized = true; reason = " because all controllers are mounted read-only (container case)"; } else { // We can be in one of two cases: // 1.) On a physical Linux system without any limit // 2.) On a physical Linux system with a limit enforced by other means (like systemd slice) if (has_cpu_limit() || has_memory_limit()) { _is_containerized = true; reason = " because either a cpu or a memory limit is present"; } else { // Not containerized reason = " because no cpu or memory limit is present"; } } log_debug(os, container)("OSContainer::init: is_containerized() = %s%s", _is_containerized ? "true" : "false", reason); } void OSContainer::check_and_set_limits() { // Check for CPU limit if (os::Linux::active_processor_count() != cgroup_subsystem->active_processor_count()) { _has_cpu_limit = true; } // Check for memory limit if (cgroup_subsystem->memory_limit_in_bytes() > 0) { _has_memory_limit = true; } } ------------- Marked as reviewed by sjohanss (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26020#pullrequestreview-3238630631 PR Review Comment: https://git.openjdk.org/jdk/pull/26020#discussion_r2358359868 From bulasevich at openjdk.org Thu Sep 18 10:47:15 2025 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Thu, 18 Sep 2025 10:47:15 GMT Subject: RFR: 8359378: aarch64: crash when using -XX:+UseFPUForSpilling In-Reply-To: References: <0MbLaZYRoz-raa9x1eZycxeHE7mvPiGJujQpg8vBdek=.e3483c47-ad65-4d09-baf5-2db9b780669d@github.com> Message-ID: <0hDCgQdHVY_yIY00TsLYZlcI7aKnw992z_x0DhqvhIY=.a5ef47d5-cfa8-4117-85b2-9e4c45d50975@github.com> On Thu, 18 Sep 2025 07:03:52 GMT, Roberto Casta?eda Lozano wrote: >> AArch64 BarrierSetAssembler path assumes only FP/vector ideal regs reach the FP spill/restore encoding. With -XX:+UseFPUForSpilling Register Allocator may allocate scalar values in FP registers. When such values (Op_RegI/Op_RegN/Op_RegL/Op_RegP) hit `BarrierSetAssembler::encode_float_vector_register_size`, we trip ShouldNotReachHere in release build and **"unexpected ideal register"** assertion in debug build. >> >> Fix: teach the encoder to handle scalar ideal regs when they physically live in FP regs: >> - treat Op_RegI / Op_RegN as 32-bit (single slot) - same class as Op_RegF >> - treat Op_RegL / Op_RegP as 64-bit (two slots) - same class as Op_RegD >> >> Related: >> - reproduced since #19746 >> - spilling logic: >> - #18967 >> - #17977 >> >> Testing: tier1-3 with javaoptions -Xcomp -Xbatch -XX:+UseFPUForSpilling on AARCH > > Hi @bulasevich, thanks for working on this issue, but please note that it was already assigned to me ([JDK-8359378](https://bugs.openjdk.org/browse/JDK-8359378)). I am fine with re-assigning it to you, but [next time please ask first, to avoid work duplication](https://openjdk.org/guide/#i-found-an-issue-in-jbs-that-i-want-to-fix). Right, @robcasloz, I started investigating this issue thinking it was something wrong in my own code. Once I realized it was a common issue already assigned, I decided to propose a fix since it looked a bit abandoned. I didn?t mean to bypass your work -- you?re right, I should have contacted you first. Anyway, I?d appreciate your review. Do you think my change is reasonable? If not, let me close this PR and leave it to you. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27350#issuecomment-3306764696 From aph at openjdk.org Thu Sep 18 10:57:17 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 18 Sep 2025 10:57:17 GMT Subject: RFR: 8359378: aarch64: crash when using -XX:+UseFPUForSpilling In-Reply-To: <0MbLaZYRoz-raa9x1eZycxeHE7mvPiGJujQpg8vBdek=.e3483c47-ad65-4d09-baf5-2db9b780669d@github.com> References: <0MbLaZYRoz-raa9x1eZycxeHE7mvPiGJujQpg8vBdek=.e3483c47-ad65-4d09-baf5-2db9b780669d@github.com> Message-ID: On Wed, 17 Sep 2025 16:19:12 GMT, Boris Ulasevich wrote: > AArch64 BarrierSetAssembler path assumes only FP/vector ideal regs reach the FP spill/restore encoding. With -XX:+UseFPUForSpilling Register Allocator may allocate scalar values in FP registers. When such values (Op_RegI/Op_RegN/Op_RegL/Op_RegP) hit `BarrierSetAssembler::encode_float_vector_register_size`, we trip ShouldNotReachHere in release build and **"unexpected ideal register"** assertion in debug build. > > Fix: teach the encoder to handle scalar ideal regs when they physically live in FP regs: > - treat Op_RegI / Op_RegN as 32-bit (single slot) - same class as Op_RegF > - treat Op_RegL / Op_RegP as 64-bit (two slots) - same class as Op_RegD > > Related: > - reproduced since #19746 > - spilling logic: > - #18967 > - #17977 > > Testing: tier1-3 with javaoptions -Xcomp -Xbatch -XX:+UseFPUForSpilling on AARCH Given that you're looking at this, I'd appreciate it if you could form an opinion bout whether this option is of any use. `UseFPUForSpilling` on AArch64 is showing signs of code rot. If it has advantages on some machine we should turn it on by default; if it does not, why support it at all? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27350#issuecomment-3306800418 From bulasevich at openjdk.org Thu Sep 18 11:57:18 2025 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Thu, 18 Sep 2025 11:57:18 GMT Subject: RFR: 8359378: aarch64: crash when using -XX:+UseFPUForSpilling In-Reply-To: References: <0MbLaZYRoz-raa9x1eZycxeHE7mvPiGJujQpg8vBdek=.e3483c47-ad65-4d09-baf5-2db9b780669d@github.com> Message-ID: <6rmFXFPH5a9AnoLqSQa5XBplICEu961cu-6HuXh4EX4=.30793abf-cfb4-49dc-8733-e5e17357f1a8@github.com> On Thu, 18 Sep 2025 10:54:58 GMT, Andrew Haley wrote: >> AArch64 BarrierSetAssembler path assumes only FP/vector ideal regs reach the FP spill/restore encoding. With -XX:+UseFPUForSpilling Register Allocator may allocate scalar values in FP registers. When such values (Op_RegI/Op_RegN/Op_RegL/Op_RegP) hit `BarrierSetAssembler::encode_float_vector_register_size`, we trip ShouldNotReachHere in release build and **"unexpected ideal register"** assertion in debug build. >> >> Fix: teach the encoder to handle scalar ideal regs when they physically live in FP regs: >> - treat Op_RegI / Op_RegN as 32-bit (single slot) - same class as Op_RegF >> - treat Op_RegL / Op_RegP as 64-bit (two slots) - same class as Op_RegD >> >> Related: >> - reproduced since #19746 >> - spilling logic: >> - #18967 >> - #17977 >> >> Testing: tier1-3 with javaoptions -Xcomp -Xbatch -XX:+UseFPUForSpilling on AARCH > > Given that you're looking at this, I'd appreciate it if you could form an opinion bout whether this option is of any use. > > `UseFPUForSpilling` on AArch64 is showing signs of code rot. If it has advantages on some machine we should turn it on by default; if it does not, why support it at all? @theRealAph Andrew, I agree with you. From my experience it is useless on Cortex-A72, Neoverse N1, Neoverse V1. I have now also checked on Neoverse V2 and Apple M4 - in both cases UseFPUForSpilling shows a clear performance degradation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27350#issuecomment-3307050077 From rcastanedalo at openjdk.org Thu Sep 18 12:00:16 2025 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 18 Sep 2025 12:00:16 GMT Subject: RFR: 8359378: aarch64: crash when using -XX:+UseFPUForSpilling In-Reply-To: References: <0MbLaZYRoz-raa9x1eZycxeHE7mvPiGJujQpg8vBdek=.e3483c47-ad65-4d09-baf5-2db9b780669d@github.com> Message-ID: On Thu, 18 Sep 2025 07:03:52 GMT, Roberto Casta?eda Lozano wrote: >> AArch64 BarrierSetAssembler path assumes only FP/vector ideal regs reach the FP spill/restore encoding. With -XX:+UseFPUForSpilling Register Allocator may allocate scalar values in FP registers. When such values (Op_RegI/Op_RegN/Op_RegL/Op_RegP) hit `BarrierSetAssembler::encode_float_vector_register_size`, we trip ShouldNotReachHere in release build and **"unexpected ideal register"** assertion in debug build. >> >> Fix: teach the encoder to handle scalar ideal regs when they physically live in FP regs: >> - treat Op_RegI / Op_RegN as 32-bit (single slot) - same class as Op_RegF >> - treat Op_RegL / Op_RegP as 64-bit (two slots) - same class as Op_RegD >> >> Related: >> - reproduced since #19746 >> - spilling logic: >> - #18967 >> - #17977 >> >> Testing: tier1-3 with javaoptions -Xcomp -Xbatch -XX:+UseFPUForSpilling on AARCH > > Hi @bulasevich, thanks for working on this issue, but please note that it was already assigned to me ([JDK-8359378](https://bugs.openjdk.org/browse/JDK-8359378)). I am fine with re-assigning it to you, but [next time please ask first, to avoid work duplication](https://openjdk.org/guide/#i-found-an-issue-in-jbs-that-i-want-to-fix). > Right, @robcasloz, I started investigating this issue thinking it was something wrong in my own code. Once I realized it was a common issue already assigned, I decided to propose a fix since it looked a bit abandoned. I didn?t mean to bypass your work -- you?re right, I should have contacted you first. Anyway, I?d appreciate your review. Do you think my change is reasonable? If not, let me close this PR and leave it to you. Thanks, I had planned to look at this in the upcoming weeks but did not start yet. I just reassigned the issue to you, will have a look at your fix within the next days. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27350#issuecomment-3307058150 From amitkumar at openjdk.org Thu Sep 18 12:09:31 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 18 Sep 2025 12:09:31 GMT Subject: RFR: 8367325: [s390x] build failure due to JDK-8361376 [v5] In-Reply-To: References: Message-ID: > Fixes the SIGLL caused after [JDK-8361376](https://bugs.openjdk.org/browse/JDK-8361376). > > Issue was with `cs` instruction, which requires the address to be aligned. And after this change address at which operating was not aligned. > > Wisdom from Principle of Z Operations: > > Sytax: CS R1,R3,D2(B2) > > Sytax: CSY R1,R3,D2(B2) > > ` > The second operand of COMPARE AND SWAP (CS, CSY) must be designated on a word boundary. > ` > > > > => 0x3fffc3149ba <_ZN17BarrierSetNMethod15set_guard_valueEP7nmethodii+266>: cs %r1,%r4,0(%r3) > (gdb) i r r3 > r3 0x3ffe500017a 4397593526650 > (gdb) p ($r3 % 8) > $5 = 2 > (gdb) si > > Thread 16 "C1 CompilerThre" received signal SIGILL, Illegal instruction. > NativeMethodBarrier::set_guard_value (bit_mask=2147483647, value=1, this=0x3ffe5000166) > at /home/amit/jdk/src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp:74 > 74 if (v == old_value) break; Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27213/files - new: https://git.openjdk.org/jdk/pull/27213/files/e328dccb..6684ea01 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27213&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27213&range=03-04 Stats: 15 lines in 3 files changed: 8 ins; 3 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27213.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27213/head:pull/27213 PR: https://git.openjdk.org/jdk/pull/27213 From amitkumar at openjdk.org Thu Sep 18 12:09:33 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 18 Sep 2025 12:09:33 GMT Subject: RFR: 8367325: [s390x] build failure due to JDK-8361376 [v4] In-Reply-To: <9thXZIz-9XDVOhvkflDfW4tIt_SIPDUNi5-r1mOisOw=.c2070092-b3a7-4198-a5a6-77b8e2b69919@github.com> References: <_q9_SaNqO8fLIfsbtDFD1LuqqfMv11wXm_X9yNPfVyU=.61d3faf9-a02f-433f-921c-3f8abad96346@github.com> <9thXZIz-9XDVOhvkflDfW4tIt_SIPDUNi5-r1mOisOw=.c2070092-b3a7-4198-a5a6-77b8e2b69919@github.com> Message-ID: On Thu, 18 Sep 2025 10:25:34 GMT, Martin Doerr wrote: >> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> refactor > > src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp line 174: > >> 172: void BarrierSetAssembler::nmethod_entry_barrier(MacroAssembler* masm) { >> 173: BarrierSetNMethod* bs_nm = BarrierSet::barrier_set()->barrier_set_nmethod(); >> 174: __ align(4, __ offset() + BARRIER_TOTAL_LENGTH); // must align the following block which requires atomic updates > > Now, this is confusing. We don't want to align the end of the barrier. We need to align the patchable field which is the immediate field of the cfi instruction. I couldn't find out better way to keep the main code free from magic numbers, so now there are three constants: 1. holding offset to the instruction (cfi) 2. holding the offset the the patchable data 3. total barrier length. I guess explanation in .hpp is enough to explain the usecase. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27213#discussion_r2358878758 From cstein at openjdk.org Thu Sep 18 12:12:31 2025 From: cstein at openjdk.org (Christian Stein) Date: Thu, 18 Sep 2025 12:12:31 GMT Subject: Integrated: 8361950: Update to use jtreg 8 In-Reply-To: References: Message-ID: On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 8. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. This pull request has now been integrated. Changeset: 5db1dfe5 Author: Christian Stein URL: https://git.openjdk.org/jdk/commit/5db1dfe5c8b5df40779bb450849e6433aa9825ab Stats: 41 lines in 11 files changed: 9 ins; 19 del; 13 mod 8361950: Update to use jtreg 8 Reviewed-by: jpai, iris, joehw, erikj, ihse, liach, alanb ------------- PR: https://git.openjdk.org/jdk/pull/26261 From mdoerr at openjdk.org Thu Sep 18 12:29:38 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 18 Sep 2025 12:29:38 GMT Subject: RFR: 8367325: [s390x] build failure due to JDK-8361376 [v5] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 12:09:31 GMT, Amit Kumar wrote: >> Fixes the SIGLL caused after [JDK-8361376](https://bugs.openjdk.org/browse/JDK-8361376). >> >> Issue was with `cs` instruction, which requires the address to be aligned. And after this change address at which operating was not aligned. >> >> Wisdom from Principle of Z Operations: >> >> Sytax: CS R1,R3,D2(B2) >> >> Sytax: CSY R1,R3,D2(B2) >> >> ` >> The second operand of COMPARE AND SWAP (CS, CSY) must be designated on a word boundary. >> ` >> >> >> >> => 0x3fffc3149ba <_ZN17BarrierSetNMethod15set_guard_valueEP7nmethodii+266>: cs %r1,%r4,0(%r3) >> (gdb) i r r3 >> r3 0x3ffe500017a 4397593526650 >> (gdb) p ($r3 % 8) >> $5 = 2 >> (gdb) si >> >> Thread 16 "C1 CompilerThre" received signal SIGILL, Illegal instruction. >> NativeMethodBarrier::set_guard_value (bit_mask=2147483647, value=1, this=0x3ffe5000166) >> at /home/amit/jdk/src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp:74 >> 74 if (v == old_value) break; > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > update Looks correct to me. I only have some minor comments. src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.hpp line 75: > 73: // first 2 bytes are for cfi instruction opcode and next 4 bytes will be the value/data to be patched, > 74: // so we are skipping first 2 bytes and returning the address of value/data field > 75: static const int OFFSET_TO_PATCHABLE_DATA = 6 + 6 + 6 + 2; // iihf(6) + iilf(6) + lg(6) + CFI_OPCODE(2) `OFFSET_TO_PATCHABLE_DATA_INSTRUCTION` could be used, here. src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp line 54: > 52: > 53: public: > 54: static const int BARRIER_TOTAL_LENGTH = BarrierSetAssembler::BARRIER_TOTAL_LENGTH; Is it necessary to replicate it? src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp line 98: > 96: offset += Assembler::instr_len(&start[offset]); > 97: > 98: // it will be assignment operation, So it doesn't matter what value is already present in instr I don't understand what you mean by "it will be assignment operation". ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27213#pullrequestreview-3239335399 PR Review Comment: https://git.openjdk.org/jdk/pull/27213#discussion_r2358967293 PR Review Comment: https://git.openjdk.org/jdk/pull/27213#discussion_r2358976887 PR Review Comment: https://git.openjdk.org/jdk/pull/27213#discussion_r2358979384 From jsjolen at openjdk.org Thu Sep 18 12:29:49 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 18 Sep 2025 12:29:49 GMT Subject: RFR: 8367249: [REDO] MemBaseline accesses VMT without using lock [v6] In-Reply-To: <1rc6_LNVUKcswi210ITCC8dND2a2h29jCQWH33dfzHU=.e37e11b3-7a3d-48ac-a5ee-a1c52f0933d7@github.com> References: <1rc6_LNVUKcswi210ITCC8dND2a2h29jCQWH33dfzHU=.e37e11b3-7a3d-48ac-a5ee-a1c52f0933d7@github.com> Message-ID: On Thu, 18 Sep 2025 09:20:18 GMT, Johan Sj?len wrote: >> Hi, >> >> This is a REDO, as the previous attempt caused build failures when merged with latest master. >> The only difference is that the copy ctr for the RBTRee had been integrated with a different PR, but it never should have been. I deleted the copy ctr. >> >> Thanks. > > Johan Sj?len has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: > > - Merge remote-tracking branch 'openjdk/master' into cleanup-membaseline > - How did this even work in any release build? > - const-ify a bit > - Fix the rest of the incorrect instances > - Merge remote-tracking branch 'openjdk/master' into cleanup-membaseline > - Delete unneeded copy ctr > - Merge remote-tracking branch 'openjdk/master' into cleanup-membaseline > - Missed const-ness > - Move into rbTree.inline.hpp file > - Merge remote-tracking branch 'openjdk/master' into cleanup-membaseline > - ... and 15 more: https://git.openjdk.org/jdk/compare/4c7c009d...993416dc Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27170#issuecomment-3307174482 From jsjolen at openjdk.org Thu Sep 18 12:29:50 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 18 Sep 2025 12:29:50 GMT Subject: Integrated: 8367249: [REDO] MemBaseline accesses VMT without using lock In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 11:53:41 GMT, Johan Sj?len wrote: > Hi, > > This is a REDO, as the previous attempt caused build failures when merged with latest master. > The only difference is that the copy ctr for the RBTRee had been integrated with a different PR, but it never should have been. I deleted the copy ctr. > > Thanks. This pull request has now been integrated. Changeset: feaa654b Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/feaa654b1bb5a1187785320603ccb17e2c43222d Stats: 239 lines in 12 files changed: 163 ins; 50 del; 26 mod 8367249: [REDO] MemBaseline accesses VMT without using lock Reviewed-by: azafari, cnorrbin ------------- PR: https://git.openjdk.org/jdk/pull/27170 From epeter at openjdk.org Thu Sep 18 12:31:52 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Thu, 18 Sep 2025 12:31:52 GMT Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays [v5] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 16:22:32 GMT, Vladimir Ivanov wrote: >> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays > > The align cycle was updated to counted loop with alignment for 32 bytes (The main loop operates by 32 bytes values and 32bytes alignment enough to have no split_stores). Reported scores on the Xeon 6740E for the compiled version vs intrinsic are: > > SRF | size | jdk26, comp | patched | p/jdk_comp > -- | -- | -- | -- | -- > ArraysFill.testByteFill | 16 | 152077.563 | 168535.8 | 1.11 > ArraysFill.testByteFill | 31 | 125702.057 | 212504.2 | 1.69 > ArraysFill.testByteFill | 250 | 57965.263 | 127806.6 | 2.20 > ArraysFill.testByteFill | 266 | 44901.157 | 145742 | 3.25 > ArraysFill.testByteFill | 511 | 61918.237 | 109917.3 | 1.78 > ArraysFill.testByteFill | 2047 | 32222.184 | 40348.55 | 1.25 > ArraysFill.testByteFill | 2048 | 31930.607 | 35773.5 | 1.12 > ArraysFill.testByteFill | 8195 | 10690.434 | 10709.71 | 1.00 > ArraysFill.testIntFill | 16 | 144979.804 | 289781.8 | 2.00 > ArraysFill.testIntFill | 31 | 133495.302 | 212475.7 | 1.59 > ArraysFill.testIntFill | 250 | 74178.893 | 80775.39 | 1.09 > ArraysFill.testIntFill | 266 | 68009.933 | 78090.68 | 1.15 > ArraysFill.testIntFill | 511 | 39688.805 | 45553.15 | 1.15 > ArraysFill.testIntFill | 2047 | 11504.203 | 11282.22 | 0.98 > ArraysFill.testIntFill | 2048 | 11245.331 | 11512.12 | 1.02 > ArraysFill.testIntFill | 8195 | 2692.649 | 2654.157 | 0.99 > ArraysFill.testLongFill | 16 | 212541.769 | 212508.9 | 1.00 > ArraysFill.testLongFill | 31 | 137729.599 | 137624.3 | 1.00 > ArraysFill.testLongFill | 250 | 43162.979 | 43155.4 | 1.00 > ArraysFill.testLongFill | 266 | 42173.88 | 42156.26 | 1.00 > ArraysFill.testLongFill | 511 | 23364.859 | 23367.6 | 1.00 > ArraysFill.testLongFill | 2047 | 6122.745 | 6123.296 | 1.00 > ArraysFill.testLongFill | 2048 | 5792.552 | 5772.727 | 1.00 > ArraysFill.testLongFill | 8195 | 616.62 | 616.257 | 1.00 > ArraysFill.testShortFill | 16 | 152176.336 | 354182.7 | 2.33 > ArraysFill.testShortFill | 31 | 137527.651 | 227688.8 | 1.66 > ArraysFill.testShortFill | 250 | 58930.645 | 99614.52 | 1.69 > ArraysFill.testShortFill | 266 | 91088.72 | 93755.19 | 1.03 > ArraysFill.testShortFill | 511 | 65332.79 | 70824.73 | 1.08 > ArraysFill.testShortFill | 2047 | 21713.296 | 22289.87 | 1.03 > ArraysFill.testShortFill | 2048 | 21667.468 | 21021.92 | 0.97 > ArraysFill.testShortFill | 8195 | 5922.318 | 5886.738 | 0.99 @IvaVladimir I'm going on vacation for 3 weeks, so won't be able to review. Feel free to ping others to review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26747#issuecomment-3307189076 From fandreuzzi at openjdk.org Thu Sep 18 12:44:00 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 18 Sep 2025 12:44:00 GMT Subject: RFR: 8334866: Improve Speed of ElfDecoder source search In-Reply-To: <1imedKgVSjyJClRAHocak7H2XZHFNCWtACCfHMWKNqM=.2ddb3733-5cdc-4159-9692-5725e79aeb20@github.com> References: <1imedKgVSjyJClRAHocak7H2XZHFNCWtACCfHMWKNqM=.2ddb3733-5cdc-4159-9692-5725e79aeb20@github.com> Message-ID: On Wed, 17 Sep 2025 11:08:47 GMT, Kerem Kat wrote: >> src/hotspot/share/utilities/elfFile.hpp line 530: >> >>> 528: size_t _capacity; >>> 529: bool _initialized; >>> 530: bool _failed; >> >> What's the advantage of having `_failed`? It seems that whenever you check `_failed` you also check `_initialized`. > > If initialization is failed for some reason, we do not try it again for the same `DwarfFile`, with the check in `ensure_aranges_cache`. I see, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27337#discussion_r2359050004 From amitkumar at openjdk.org Thu Sep 18 12:44:03 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 18 Sep 2025 12:44:03 GMT Subject: RFR: 8367325: [s390x] build failure due to JDK-8361376 [v5] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 12:09:31 GMT, Amit Kumar wrote: >> Fixes the SIGLL caused after [JDK-8361376](https://bugs.openjdk.org/browse/JDK-8361376). >> >> Issue was with `cs` instruction, which requires the address to be aligned. And after this change address at which operating was not aligned. >> >> Wisdom from Principle of Z Operations: >> >> Sytax: CS R1,R3,D2(B2) >> >> Sytax: CSY R1,R3,D2(B2) >> >> ` >> The second operand of COMPARE AND SWAP (CS, CSY) must be designated on a word boundary. >> ` >> >> >> >> => 0x3fffc3149ba <_ZN17BarrierSetNMethod15set_guard_valueEP7nmethodii+266>: cs %r1,%r4,0(%r3) >> (gdb) i r r3 >> r3 0x3ffe500017a 4397593526650 >> (gdb) p ($r3 % 8) >> $5 = 2 >> (gdb) si >> >> Thread 16 "C1 CompilerThre" received signal SIGILL, Illegal instruction. >> NativeMethodBarrier::set_guard_value (bit_mask=2147483647, value=1, this=0x3ffe5000166) >> at /home/amit/jdk/src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp:74 >> 74 if (v == old_value) break; > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > update @dean-long would it be possible for you to have another look at the latest changes ? Thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/27213#issuecomment-3307242405 From amitkumar at openjdk.org Thu Sep 18 12:44:07 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 18 Sep 2025 12:44:07 GMT Subject: RFR: 8367325: [s390x] build failure due to JDK-8361376 [v5] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 12:26:09 GMT, Martin Doerr wrote: >> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> update > > src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp line 54: > >> 52: >> 53: public: >> 54: static const int BARRIER_TOTAL_LENGTH = BarrierSetAssembler::BARRIER_TOTAL_LENGTH; > > Is it necessary to replicate it? It is being used with `NativeMethodBarrier`, yes I can change it and technically it wouldn't affect anything, but just to keep code change bit shorter, I left it as it is. > src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp line 98: > >> 96: offset += Assembler::instr_len(&start[offset]); >> 97: >> 98: // it will be assignment operation, So it doesn't matter what value is already present in instr > > I don't understand what you mean by "it will be assignment operation". it is just a assignment being done in that method, i.e. `instr` variable will be just overwritten straightly. So currently whatever value `instr` holds, it wouldn't not affect the returned-value. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27213#discussion_r2359026137 PR Review Comment: https://git.openjdk.org/jdk/pull/27213#discussion_r2359038854 From jbechberger at openjdk.org Thu Sep 18 13:00:01 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 18 Sep 2025 13:00:01 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing In-Reply-To: References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> Message-ID: <_uoBONcm-SYGzYs8fKBgfwmfhIeqZaBgimjZYtqJ92g=.7827f207-de8e-4842-91cb-f15230b2b40f@github.com> On Thu, 18 Sep 2025 01:16:44 GMT, Andrei Pangin wrote: >> This change hopefully fixes the test failures by making the test cases more resilient. > > test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 103: > >> 101: // setup recording >> 102: AtomicLong burstThreadId = new AtomicLong(); >> 103: final long startTimeMillis = System.currentTimeMillis(); > > Do not use `System.currentTimeMillis()` for time intervals: 1) it suffers from rounding errors due to low resolution; 2) it is not guaranteed to be monotonic. Use `System.nanoTime()` or `Instant.now()` instead. Thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2359140696 From jbechberger at openjdk.org Thu Sep 18 13:09:27 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 18 Sep 2025 13:09:27 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing In-Reply-To: References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> Message-ID: On Thu, 18 Sep 2025 01:30:44 GMT, Andrei Pangin wrote: >> This change hopefully fixes the test failures by making the test cases more resilient. > > test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 165: > >> 163: } >> 164: // check that there are at least 3 time boxes >> 165: Asserts.assertTrue(timeBoxedLosses.size() > 3); > > Not sure what this assert means. From what I see, the size of `timeBoxedLosses` should be exactly equal to the number of main loop iterations (5). It should. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2359195279 From jbechberger at openjdk.org Thu Sep 18 13:20:57 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 18 Sep 2025 13:20:57 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing In-Reply-To: <9faaJWDTc4hOBRJ5p1ZZcX879KV1385Njd4IAL7Bu-c=.3cc8526c-a553-446f-8c90-8cc7c446a437@github.com> References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> <9faaJWDTc4hOBRJ5p1ZZcX879KV1385Njd4IAL7Bu-c=.3cc8526c-a553-446f-8c90-8cc7c446a437@github.com> Message-ID: On Thu, 18 Sep 2025 01:58:18 GMT, Andrei Pangin wrote: >> test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 154: >> >>> 152: ThreadMXBean bean = ManagementFactory.getThreadMXBean(); >>> 153: long start = bean.getCurrentThreadCpuTime(); >>> 154: while (bean.getCurrentThreadCpuTime() - start < millis * 1_000_000) { >> >> Isn't this method supposed to check CPU time of the passed `thread` rather than current thread? > > BTW, is there a specific reason to burn cpu in a separate thread? It can be done in the same `main` thread, isn't it? > Isn't this method supposed to check CPU time of the passed thread rather than current thread? You're correct. > It can be done in the same main thread, isn't it? You're correct and it makes the code so much easier. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2359252129 From iwalulya at openjdk.org Thu Sep 18 13:28:52 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 18 Sep 2025 13:28:52 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v7] In-Reply-To: References: Message-ID: > Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. > > Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. > > Testing: Tier 1-7 Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - make universal - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - Revert - Thomas Review - return on timeout - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - timed wait - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - ... and 5 more: https://git.openjdk.org/jdk/compare/4c7c009d...1a53c207 ------------- Changes: https://git.openjdk.org/jdk/pull/27190/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=06 Stats: 103 lines in 17 files changed: 76 ins; 20 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27190.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27190/head:pull/27190 PR: https://git.openjdk.org/jdk/pull/27190 From jbechberger at openjdk.org Thu Sep 18 13:30:31 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 18 Sep 2025 13:30:31 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing In-Reply-To: References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> Message-ID: <81w2mpMAaOI3WCzt3qEPCGDKblt0nPdT6ULvaDx9BtM=.7eb2a3e5-a114-4be7-aba4-0335d104bd94@github.com> On Thu, 18 Sep 2025 02:06:27 GMT, Andrei Pangin wrote: >> This change hopefully fixes the test failures by making the test cases more resilient. > > test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 99: > >> 97: } >> 98: >> 99: public static void main(String[] args) throws Exception { > > A brief high-level explanation of what the test does would be useful. > From what I understood, the test starts CPU time sampling with a short interval (1ms), temporarily disables processing of native samples to cause queue overflow, then enables it back to report lost samples. Repeats the cycle 5 times and verifies that the queue has grown by the time of the last iteration, thereby decreasing the amount of losses. Almost. But I only check the loss. I'll use an updated version of your text. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2359312057 From iwalulya at openjdk.org Thu Sep 18 13:31:43 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 18 Sep 2025 13:31:43 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v7] In-Reply-To: References: <37fyY6jq5j6CdWbBJQK94mkR70ik6oINWLiAR6nPY90=.dd5f6d7c-8a02-46f1-99db-bfb3500772fb@github.com> Message-ID: On Tue, 16 Sep 2025 14:44:20 GMT, Ivan Walulya wrote: >> I had put `log_cpu_time` right before calling `stop()`. The `stop()` is the method that terminates GC threads, so no synchronization should be needed if I'm not mistaken. >> >> Please correct me if you think I got it wrong here. >> >> Nevertheless, any user of `gc_threads_do` might still iterate over terminated GC workers thread. Could we consider adding a check or assert in that method? > > We can have GCs between `log_cpu_time` and `stop()`. This reduces chances of that happening if we have `log_cpu_time` under same lock as setting `_is_shutting_down`. > >> Nevertheless, any user of gc_threads_do might still iterate over terminated GC workers thread. Could we consider adding a check or assert in that method? > > Yes, we can have the assert in `gc_threads_do`, I thought this was going to be done as a follow up. I moved `_is_shutting_down` to `Universe`, which allowed me to restore this `log_cpu_time`. I also added the assert before reading `os::thread_cpu_time` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2359318824 From cnorrbin at openjdk.org Thu Sep 18 13:35:31 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 18 Sep 2025 13:35:31 GMT Subject: RFR: 8367536: Change RBTree to use C++17 features [v4] In-Reply-To: References: Message-ID: > Hi everyone, > > C++17 lets us tidy up som of the ugly templating done in the red-black tree. We can replace the `std::false_type`/`std::true_type` tricks used to discover comparator and verifier signatures with the new `std::is_invocable(_r_v)`, and most of the overload/SFINAE noise can disappear thanks to `if constexpr`. > > We can now write one-liners such as: > ```c++ > static constexpr bool HasKeyComparator = std::is_invocable_r_v; > > > and then select the right branch with > ```c++ > if constexpr (HasKeyComparator) { } > > inside a single function instead of having several `ENABLE_IF` overloads. > > This results in fewer lines, clearer intent, and more readable errors, while keeping behaviour identical. > > Testing: > - Oracle tiers 1-3 Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: Added clarifying note + change name to 'HasNodeVerifierImpl' ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27260/files - new: https://git.openjdk.org/jdk/pull/27260/files/6f52cbf1..184b5fc5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27260&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27260&range=02-03 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27260.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27260/head:pull/27260 PR: https://git.openjdk.org/jdk/pull/27260 From cnorrbin at openjdk.org Thu Sep 18 13:45:26 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 18 Sep 2025 13:45:26 GMT Subject: RFR: 8367536: Change RBTree to use C++17 features [v3] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 21:30:19 GMT, Kim Barrett wrote: > Maybe leave a comment with `has_not_verifier` about the issue, referring to that gcc bug? Oh, and `has_node_verifier` is a type, so should normally be studly capped. Add an "Impl" suffix to avoid collision with the constant, and also make it more obvious other code shouldn't be referencing it directly. Thank you for the comment. It's unfortunate that such a bug exists, and that we had to encounter it almost immediately. I can definitely understand why it wasn't caught though. Seeing as it is pretty niche, I agree it shouldn't be added to the style guide at this time, perhaps in the future if it were to become a (somewhat) regular problem. Nevertheless, I pushed an update to document the issue (with the GCC PR ID) in the code along with changing the struct name to `HasNodeVerifierImpl`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27260#issuecomment-3307538098 From jbechberger at openjdk.org Thu Sep 18 14:02:53 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 18 Sep 2025 14:02:53 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing [v2] In-Reply-To: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> Message-ID: > This change hopefully fixes the test failures by making the test cases more resilient. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Simplify code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27293/files - new: https://git.openjdk.org/jdk/pull/27293/files/15569d5d..1dc6ad1d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27293&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27293&range=00-01 Stats: 85 lines in 5 files changed: 18 ins; 51 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/27293.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27293/head:pull/27293 PR: https://git.openjdk.org/jdk/pull/27293 From jbechberger at openjdk.org Thu Sep 18 14:02:54 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 18 Sep 2025 14:02:54 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing In-Reply-To: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> Message-ID: On Mon, 15 Sep 2025 12:17:13 GMT, Johannes Bechberger wrote: > This change hopefully fixes the test failures by making the test cases more resilient. Thanks to the tips of @apangin I was able to drastically reduce both size and complexity of the test case. I hope it runs better now. What I improved - Only use a single thread - No arbitrary waits, just one native wait in the loop - Properly documented the test scenario ------------- PR Comment: https://git.openjdk.org/jdk/pull/27293#issuecomment-3307625621 From apangin at openjdk.org Thu Sep 18 14:15:59 2025 From: apangin at openjdk.org (Andrei Pangin) Date: Thu, 18 Sep 2025 14:15:59 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing [v2] In-Reply-To: References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> Message-ID: On Thu, 18 Sep 2025 14:02:53 GMT, Johannes Bechberger wrote: >> This change hopefully fixes the test failures by making the test cases more resilient. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Simplify code Thanks! Much better, indeed. Added a few more minor comments. test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 74: > 72: private final List timeBoxEnds = new ArrayList<>(); > 73: > 74: public synchronized void addEvent(LossEvent event) { Since the test is now single-threaded, all `synchronized` are redundant. test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 106: > 104: try (RecordingStream rs = new RecordingStream()) { > 105: // setup recording > 106: AtomicLong burstThreadId = new AtomicLong(); Does not need to be `AtomicLong`. Can be `long` and initialized right here. test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 130: > 128: WHITE_BOX.busyWaitCPUTime(1000); > 129: // going out-of-native at the end of the previous call should have triggered > 130: // the safepoint handler, thereby also triggering the stack walkingand creation typo: walking_and test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 145: > 143: static void disableOutOfStackWalking() { > 144: boolean supported = WHITE_BOX.cpuSamplerSetOutOfStackWalking(false); > 145: if (!supported) { Why not simply `assertTrue(supported, ...)`? ------------- PR Review: https://git.openjdk.org/jdk/pull/27293#pullrequestreview-3239996378 PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2359507524 PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2359518683 PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2359523702 PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2359530422 From stuefe at openjdk.org Thu Sep 18 14:29:41 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 18 Sep 2025 14:29:41 GMT Subject: RFR: 8365823: Revert storing abstract and interface Klasses to non-class metaspace [v3] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 14:38:03 GMT, Coleen Phillimore wrote: >> This change removes the optimization to not store abstract and interface Klass metadata to non-class metaspace. Now all Klass metadata is in the Klass metaspace. This is simpler and less bug prone, and didn't help with the limitation of classes that can be stored in class metaspace materially. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove CFP.is_abstract(). This looks good. In hindsight kind of scary that there are no tests to change back. But all Metaspace tests sit either on a layer below Metaspace::allocate or test class loading, which sits above this layer. Some tests that check expected memory levels in class space and non-class metaspace could now run into problems, since the ratio between these numbers should shift (total consumption should be about identical). Maybe not. We'll see it when we see it. src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotMetaspaceConstantImpl.java line 102: > 100: // in compressible metaspace. > 101: return !t.isInterface() && !t.isAbstract(); > 102: } Can we remove this completely? ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27295#pullrequestreview-3240079100 PR Review Comment: https://git.openjdk.org/jdk/pull/27295#discussion_r2359574924 From sspitsyn at openjdk.org Thu Sep 18 14:31:46 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 18 Sep 2025 14:31:46 GMT Subject: RFR: 8362561: Remove diagnostic option AllowArchivingWithJavaAgent [v2] In-Reply-To: <4rXsdT80fqT4ZXSAbEjCVeIcLq42E8c8aZmaioXvMyU=.685afea0-beb1-44ea-a5e9-d0667f567c05@github.com> References: <4rXsdT80fqT4ZXSAbEjCVeIcLq42E8c8aZmaioXvMyU=.685afea0-beb1-44ea-a5e9-d0667f567c05@github.com> Message-ID: On Thu, 18 Sep 2025 03:35:19 GMT, Ioi Lam wrote: >> Goal: simplify AOT implementation and removed unnecessary tests: >> >> This PR removes old CDS tests that use java agents during CDS dump (to increase test coverage by triggering conditions, such as GCs, that were not happening during usual `java -Xshare:dump` operations). >> >> Since AOT assembly is much more complex now, we have enough coverage. These old tests are no longer necessary. >> >> With these tests removed, we no longer need the `-XX:-AllowArchivingWithJavaAgent` diagnostic flag, which has been abused by users despite the warning that this flag should not be used in production. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into 8362561-remove-diagnostic-option-AllowArchivingWithJavaAgent > - Added test case for dynamic archive with -javaagent > - 8362561: Remove diagnostic option AllowArchivingWithJavaAgent Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27304#pullrequestreview-3240125838 From sspitsyn at openjdk.org Thu Sep 18 14:31:48 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 18 Sep 2025 14:31:48 GMT Subject: RFR: 8362561: Remove diagnostic option AllowArchivingWithJavaAgent [v2] In-Reply-To: References: <4rXsdT80fqT4ZXSAbEjCVeIcLq42E8c8aZmaioXvMyU=.685afea0-beb1-44ea-a5e9-d0667f567c05@github.com> Message-ID: <1WUA7IO4VV9v2g94V8V_kXLO5-MwySbuTwGx0aM7Tlw=.1032ac3a-6004-48f1-bce3-7b0264c4e7d7@github.com> On Thu, 18 Sep 2025 04:43:44 GMT, Ioi Lam wrote: > I have merged manually to fix conflicts in TEST.groups. No other changes. > Please re-review. Thanks! It looks okay but I've noticed that now 9 lines are removed in TEST.groups instead of 10. I hope it is intentional. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27304#issuecomment-3307782824 From jbechberger at openjdk.org Thu Sep 18 14:48:11 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 18 Sep 2025 14:48:11 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing [v3] In-Reply-To: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> Message-ID: <_LgONwP1Tgunjanim54_sYkPkqq-uRHjjbqVDoPYf_0=.45c05cb7-a616-4704-b367-cff3dad7926c@github.com> > This change hopefully fixes the test failures by making the test cases more resilient. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Tiny fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27293/files - new: https://git.openjdk.org/jdk/pull/27293/files/1dc6ad1d..5a1ec5f9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27293&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27293&range=01-02 Stats: 11 lines in 1 file changed: 0 ins; 7 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27293.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27293/head:pull/27293 PR: https://git.openjdk.org/jdk/pull/27293 From jbechberger at openjdk.org Thu Sep 18 14:51:33 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 18 Sep 2025 14:51:33 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing [v4] In-Reply-To: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> Message-ID: <3tx8u2KSzSzLQG8wa-YCiQGCwS--B1q56JZFiYbklhQ=.396d1328-3591-46de-9e82-5e3a065c8b8a@github.com> > This change hopefully fixes the test failures by making the test cases more resilient. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Remove synchronized ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27293/files - new: https://git.openjdk.org/jdk/pull/27293/files/5a1ec5f9..c7c72770 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27293&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27293&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27293.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27293/head:pull/27293 PR: https://git.openjdk.org/jdk/pull/27293 From adinn at openjdk.org Thu Sep 18 15:01:41 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 18 Sep 2025 15:01:41 GMT Subject: RFR: 8359378: aarch64: crash when using -XX:+UseFPUForSpilling In-Reply-To: <0MbLaZYRoz-raa9x1eZycxeHE7mvPiGJujQpg8vBdek=.e3483c47-ad65-4d09-baf5-2db9b780669d@github.com> References: <0MbLaZYRoz-raa9x1eZycxeHE7mvPiGJujQpg8vBdek=.e3483c47-ad65-4d09-baf5-2db9b780669d@github.com> Message-ID: On Wed, 17 Sep 2025 16:19:12 GMT, Boris Ulasevich wrote: > AArch64 BarrierSetAssembler path assumes only FP/vector ideal regs reach the FP spill/restore encoding. With -XX:+UseFPUForSpilling Register Allocator may allocate scalar values in FP registers. When such values (Op_RegI/Op_RegN/Op_RegL/Op_RegP) hit `BarrierSetAssembler::encode_float_vector_register_size`, we trip ShouldNotReachHere in release build and **"unexpected ideal register"** assertion in debug build. > > Fix: teach the encoder to handle scalar ideal regs when they physically live in FP regs: > - treat Op_RegI / Op_RegN as 32-bit (single slot) - same class as Op_RegF > - treat Op_RegL / Op_RegP as 64-bit (two slots) - same class as Op_RegD > > Related: > - reproduced since #19746 > - spilling logic: > - #18967 > - #17977 > > Testing: tier1-3 with javaoptions -Xcomp -Xbatch -XX:+UseFPUForSpilling on AARCH I was wondering about that. So, perhaps a better fix is to change the command line ergonomics so that AArch64 either 1) refuses to run with it set to true or 2) prints a warning and resets it to false. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27350#issuecomment-3307970063 From azafari at openjdk.org Thu Sep 18 15:37:38 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 18 Sep 2025 15:37:38 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v7] In-Reply-To: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: > The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. > The acceptable value is changed to 64K. > > Tests: > linux-x64 tier1 Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: fixed MAX2 template parameter ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26955/files - new: https://git.openjdk.org/jdk/pull/26955/files/649f59d2..3dfa9765 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26955.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26955/head:pull/26955 PR: https://git.openjdk.org/jdk/pull/26955 From aboldtch at openjdk.org Thu Sep 18 15:37:38 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 18 Sep 2025 15:37:38 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer [v5] In-Reply-To: References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> Message-ID: On Thu, 18 Sep 2025 07:44:04 GMT, Afshin Zafari wrote: > I followed (IIUC) your comments on replacing uintptr_t and uint64_t because of differences in platforms. Sorry, something must be lacking in my communication. What I was trying to describe was that you will have issues if you expect the two typedefs to have the same underlying type even if we can assume they are both 64bit and unsigned. You currently have the same issue with `size_t` and `uintptr_t`. The issue is that you are using a template function which expects something along the lines of `T MAX2(T, T)`. But you are using it with two distinct (but compatible) types. The compiler cannot infer if you want `unsigned long long MAX2(unsigned long long, unsigned long long)` or `unsigned long MAX2(unsigned long, unsigned long)` so you need to tell it. There are in general two ways to do this. Either you cast: ```C++ lowest_start = MAX2(lowest_start, (uintptr_t)(UnscaledOopHeapMax - size)); or you select the specific instantiation of the templated function: ```C++ lowest_start = MAX2(lowest_start, UnscaledOopHeapMax - size); I prefer the later as it allows `-Wconversions` to warn if these types are incompatible(/lossy). While the cast will silence such warnings. If I see the former I usually assume that we are truncating or allow truncation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3308161319 From apangin at openjdk.org Thu Sep 18 15:54:01 2025 From: apangin at openjdk.org (Andrei Pangin) Date: Thu, 18 Sep 2025 15:54:01 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing [v4] In-Reply-To: <3tx8u2KSzSzLQG8wa-YCiQGCwS--B1q56JZFiYbklhQ=.396d1328-3591-46de-9e82-5e3a065c8b8a@github.com> References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> <3tx8u2KSzSzLQG8wa-YCiQGCwS--B1q56JZFiYbklhQ=.396d1328-3591-46de-9e82-5e3a065c8b8a@github.com> Message-ID: On Thu, 18 Sep 2025 14:51:33 GMT, Johannes Bechberger wrote: >> This change hopefully fixes the test failures by making the test cases more resilient. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove synchronized Marked as reviewed by apangin (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/27293#pullrequestreview-3240632801 From pchilanomate at openjdk.org Thu Sep 18 15:58:57 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 18 Sep 2025 15:58:57 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v11] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 05:12:14 GMT, Leonid Mesnik wrote: >> The >> `SuspendResumeManager::suspend(bool register_vthread_SR)` >> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. >> >> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. >> >> The fix added some "asymmetry" in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > asseriton moved out Current version looks good to me, thanks. ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27317#pullrequestreview-3240659049 From iklam at openjdk.org Thu Sep 18 16:12:19 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 18 Sep 2025 16:12:19 GMT Subject: RFR: 8362561: Remove diagnostic option AllowArchivingWithJavaAgent [v2] In-Reply-To: <1WUA7IO4VV9v2g94V8V_kXLO5-MwySbuTwGx0aM7Tlw=.1032ac3a-6004-48f1-bce3-7b0264c4e7d7@github.com> References: <4rXsdT80fqT4ZXSAbEjCVeIcLq42E8c8aZmaioXvMyU=.685afea0-beb1-44ea-a5e9-d0667f567c05@github.com> <1WUA7IO4VV9v2g94V8V_kXLO5-MwySbuTwGx0aM7Tlw=.1032ac3a-6004-48f1-bce3-7b0264c4e7d7@github.com> Message-ID: On Thu, 18 Sep 2025 14:29:05 GMT, Serguei Spitsyn wrote: > > I have merged manually to fix conflicts in TEST.groups. No other changes. > > Please re-review. Thanks! > > It looks okay but I've noticed that now 9 lines are removed in TEST.groups instead of 10. I hope it is intentional. Yes, it's intentional. Some of those lines were already removed by another recent [changeset 91a979430e2516b5853c397a336837799928f478](https://github.com/openjdk/jdk/commit/91a979430e2516b5853c397a336837799928f478#diff-6a6d33f5e9a74d214fa61fa2cc0c8e210ff6032b77ab3395ec6210769b8e57e6). Thanks @sspitsyn @albertnetymk @shipilev @dholmes-ora for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/27304#issuecomment-3308332068 PR Comment: https://git.openjdk.org/jdk/pull/27304#issuecomment-3308334286 From iklam at openjdk.org Thu Sep 18 16:12:21 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 18 Sep 2025 16:12:21 GMT Subject: Integrated: 8362561: Remove diagnostic option AllowArchivingWithJavaAgent In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 03:52:16 GMT, Ioi Lam wrote: > Goal: simplify AOT implementation and removed unnecessary tests: > > This PR removes old CDS tests that use java agents during CDS dump (to increase test coverage by triggering conditions, such as GCs, that were not happening during usual `java -Xshare:dump` operations). > > Since AOT assembly is much more complex now, we have enough coverage. These old tests are no longer necessary. > > With these tests removed, we no longer need the `-XX:-AllowArchivingWithJavaAgent` diagnostic flag, which has been abused by users despite the warning that this flag should not be used in production. This pull request has now been integrated. Changeset: 000569da Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/000569da601afde85f83c361c9f1a7ba3814bff4 Stats: 1197 lines in 25 files changed: 41 ins; 1146 del; 10 mod 8362561: Remove diagnostic option AllowArchivingWithJavaAgent Reviewed-by: sspitsyn, shade, dholmes, ayang ------------- PR: https://git.openjdk.org/jdk/pull/27304 From phh at openjdk.org Thu Sep 18 16:15:12 2025 From: phh at openjdk.org (Paul Hohensee) Date: Thu, 18 Sep 2025 16:15:12 GMT Subject: RFR: 8367862: debug.cpp: Do not print help message for methods not compiled in In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 11:27:27 GMT, Kerem Kat wrote: > The `help` command in `debug.cpp` was out of date, listing only a fraction of the available functions. This and other commands callable from gdb via `call help()`. > > I added all commands to the help message, except `pns2` as it is documented as not being useful when called from gdb. > > Also fixed is the message for the conditional `pns` command appearing in PRODUCT builds. Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27341#pullrequestreview-3240752187 From kbarrett at openjdk.org Thu Sep 18 16:30:28 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 18 Sep 2025 16:30:28 GMT Subject: RFR: 8367536: Change RBTree to use C++17 features [v4] In-Reply-To: References: Message-ID: <64bh4d_TAVY9cU002EuITVxJWl0UQpsmYszh_IGPgxg=.b199d57f-97a2-498d-a0e7-4f39f73807d5@github.com> On Thu, 18 Sep 2025 13:35:31 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> C++17 lets us tidy up som of the ugly templating done in the red-black tree. We can replace the `std::false_type`/`std::true_type` tricks used to discover comparator and verifier signatures with the new `std::is_invocable(_r_v)`, and most of the overload/SFINAE noise can disappear thanks to `if constexpr`. >> >> We can now write one-liners such as: >> ```c++ >> static constexpr bool HasKeyComparator = std::is_invocable_r_v; >> >> >> and then select the right branch with >> ```c++ >> if constexpr (HasKeyComparator) { } >> >> inside a single function instead of having several `ENABLE_IF` overloads. >> >> This results in fewer lines, clearer intent, and more readable errors, while keeping behaviour identical. >> >> Testing: >> - Oracle tiers 1-3 > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > Added clarifying note + change name to 'HasNodeVerifierImpl' Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27260#pullrequestreview-3240831666 From duke at openjdk.org Thu Sep 18 16:34:11 2025 From: duke at openjdk.org (Ruben) Date: Thu, 18 Sep 2025 16:34:11 GMT Subject: RFR: 8365153: AArch64: Set JVM flags for Neoverse N3 and V3 cores Message-ID: For Neoverse N1, N2, V1, and V2, the following JVM flags are set: - UseSIMDForMemoryOps=true - OnSpinWaitInst=isb - OnSpinWaitInstCount=1 - AlwaysMergeDMB=false Additionally, for Neoverse V1 and V2 only, these flags are set: - UseCryptoPmullForCRC32=true - CodeEntryAlignment=32 Set the same flags for Neoverse N3 and V3, respectively. ------------- Commit messages: - 8365153: AArch64: Set JVM flags for Neoverse N3 and V3 cores Changes: https://git.openjdk.org/jdk/pull/26701/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26701&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365153 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26701.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26701/head:pull/26701 PR: https://git.openjdk.org/jdk/pull/26701 From coleenp at openjdk.org Thu Sep 18 17:50:54 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 18 Sep 2025 17:50:54 GMT Subject: RFR: 8365823: Revert storing abstract and interface Klasses to non-class metaspace [v4] In-Reply-To: References: Message-ID: > This change removes the optimization to not store abstract and interface Klass metadata to non-class metaspace. Now all Klass metadata is in the Klass metaspace. This is simpler and less bug prone, and didn't help with the limitation of classes that can be stored in class metaspace materially. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Revert JFR changes from JDK-8338526 also. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27295/files - new: https://git.openjdk.org/jdk/pull/27295/files/fe44431f..c333b8a1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27295&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27295&range=02-03 Stats: 8 lines in 1 file changed: 1 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27295.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27295/head:pull/27295 PR: https://git.openjdk.org/jdk/pull/27295 From duke at openjdk.org Thu Sep 18 17:52:12 2025 From: duke at openjdk.org (Ruben) Date: Thu, 18 Sep 2025 17:52:12 GMT Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1 volatile field loads [v2] In-Reply-To: <7rOmFYwzssNyo-r4sU_9563VootV4M61h-6MYsNU7Zc=.23d773f2-43a3-4ea0-8a1d-f1b740bdcdbb@github.com> References: <7rOmFYwzssNyo-r4sU_9563VootV4M61h-6MYsNU7Zc=.23d773f2-43a3-4ea0-8a1d-f1b740bdcdbb@github.com> Message-ID: On Thu, 18 Sep 2025 07:50:33 GMT, Andrew Haley wrote: >> Also have just finished running jcstress and it seems to pass fine. > > @spchee , are you still working on this? Hi @theRealAph, Thank you for checking. @spchee is currently unavailable. I will be taking over this work. Following the https://github.com/openjdk/jdk/pull/26748#discussion_r2287427842 discussion, would it be possible to confirm whether there is a current use-case for `AlwaysAtomicAccesses`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26748#issuecomment-3308790802 From mgronlun at openjdk.org Thu Sep 18 17:55:24 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 18 Sep 2025 17:55:24 GMT Subject: RFR: 8365823: Revert storing abstract and interface Klasses to non-class metaspace [v4] In-Reply-To: References: Message-ID: <-F-_kJ5tErKjYKADQ4XDAxLsGKG5I7WqGpHdSErUSnE=.6cf5d41a-61b4-482f-a71d-0f69746e08d9@github.com> On Thu, 18 Sep 2025 17:50:54 GMT, Coleen Phillimore wrote: >> This change removes the optimization to not store abstract and interface Klass metadata to non-class metaspace. Now all Klass metadata is in the Klass metaspace. This is simpler and less bug prone, and didn't help with the limitation of classes that can be stored in class metaspace materially. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Revert JFR changes from JDK-8338526 also. Commit: "Revert JFR changes from JDK-8338526 also." looks good. Thanks ------------- PR Review: https://git.openjdk.org/jdk/pull/27295#pullrequestreview-3241262669 From jsjolen at openjdk.org Thu Sep 18 18:02:03 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 18 Sep 2025 18:02:03 GMT Subject: RFR: 8367536: Change RBTree to use C++17 features [v4] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 13:35:31 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> C++17 lets us tidy up som of the ugly templating done in the red-black tree. We can replace the `std::false_type`/`std::true_type` tricks used to discover comparator and verifier signatures with the new `std::is_invocable(_r_v)`, and most of the overload/SFINAE noise can disappear thanks to `if constexpr`. >> >> We can now write one-liners such as: >> ```c++ >> static constexpr bool HasKeyComparator = std::is_invocable_r_v; >> >> >> and then select the right branch with >> ```c++ >> if constexpr (HasKeyComparator) { } >> >> inside a single function instead of having several `ENABLE_IF` overloads. >> >> This results in fewer lines, clearer intent, and more readable errors, while keeping behaviour identical. >> >> Testing: >> - Oracle tiers 1-3 > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > Added clarifying note + change name to 'HasNodeVerifierImpl' src/hotspot/share/utilities/rbTree.hpp line 205: > 203: std::is_invocable_r_v; > 204: > 205: // Due to a bug in older GCC versions with static templeted constexpr data members (see GCC PR 71954), templeted -> templated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27260#discussion_r2360546002 From coleenp at openjdk.org Thu Sep 18 18:04:05 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 18 Sep 2025 18:04:05 GMT Subject: RFR: 8365823: Revert storing abstract and interface Klasses to non-class metaspace [v5] In-Reply-To: References: Message-ID: > This change removes the optimization to not store abstract and interface Klass metadata to non-class metaspace. Now all Klass metadata is in the Klass metaspace. This is simpler and less bug prone, and didn't help with the limitation of classes that can be stored in class metaspace materially. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Some limited additional cleanup to HotSpotMetaspaceConstantImpl.java on jvmci. Reran jvmci tests. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27295/files - new: https://git.openjdk.org/jdk/pull/27295/files/c333b8a1..f1d08d63 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27295&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27295&range=03-04 Stats: 11 lines in 1 file changed: 0 ins; 10 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27295.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27295/head:pull/27295 PR: https://git.openjdk.org/jdk/pull/27295 From coleenp at openjdk.org Thu Sep 18 18:04:08 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 18 Sep 2025 18:04:08 GMT Subject: RFR: 8365823: Revert storing abstract and interface Klasses to non-class metaspace [v5] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 14:21:48 GMT, Thomas Stuefe wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Some limited additional cleanup to HotSpotMetaspaceConstantImpl.java on jvmci. Reran jvmci tests. > > src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotMetaspaceConstantImpl.java line 102: > >> 100: // in compressible metaspace. >> 101: return !t.isInterface() && !t.isAbstract(); >> 102: } > > Can we remove this completely? I suppose but we don't really test this code well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27295#discussion_r2360528357 From coleenp at openjdk.org Thu Sep 18 18:04:09 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 18 Sep 2025 18:04:09 GMT Subject: RFR: 8365823: Revert storing abstract and interface Klasses to non-class metaspace [v5] In-Reply-To: References: Message-ID: <1Onnx3yG5dKlycjRqKePin3Lqy_U6-HFSHBGYxrsZm8=.0fde1dbd-fd4f-47b4-9c11-4de165f5fa6a@github.com> On Thu, 18 Sep 2025 17:54:11 GMT, Coleen Phillimore wrote: >> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotMetaspaceConstantImpl.java line 102: >> >>> 100: // in compressible metaspace. >>> 101: return !t.isInterface() && !t.isAbstract(); >>> 102: } >> >> Can we remove this completely? > > I suppose but we don't really test this code well. I removed this and cleaned up or fixed the callers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27295#discussion_r2360553785 From sviswanathan at openjdk.org Thu Sep 18 18:08:29 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Thu, 18 Sep 2025 18:08:29 GMT Subject: RFR: 8367780: Enable UseAPX on Intel CPUs only when both APX_F and APX_NCI_NDD_NF cpuid features are present [v4] In-Reply-To: <-cYOL5wwp8oSisK5utj0B7mHi0D_Ne0i_N_RI-bsbLk=.87c1bc5f-a6a3-4d4e-9530-fc91e676656f@github.com> References: <-cYOL5wwp8oSisK5utj0B7mHi0D_Ne0i_N_RI-bsbLk=.87c1bc5f-a6a3-4d4e-9530-fc91e676656f@github.com> Message-ID: On Wed, 17 Sep 2025 17:54:49 GMT, Srinivas Vamsi Parasa wrote: >> The goal of this PR is to enable APX on Intel CPUs (i.e. enable UseAPX) only when both the APX_F and APX_NCI_NDD_NF cpuid feature flags are present. >> >> As per the latest update to the Intel APX specification (https://www.intel.com/content/www/us/en/content-details/861610/intel-advanced-performance-extensions-intel-apx-architecture-specification.html ), when APX_F is set, processors also provide CPUID leaf 0x29 (APX Advanced Performance Extensions Leaf). Any Intel processor that enumerates APX_F also enumerates APX_NCI_NDD_NF. >> >> This PR enhances the HotSpot x86 CPU feature detection to recognize the APX_NCI_NDD_NF sub-feature of Intel APX and update the enabling logic for UseAPX VM flag. > > Srinivas Vamsi Parasa has updated the pull request incrementally with two additional commits since the last revision: > > - Update CPUInfoTest.java > - Remove APX_NCI_NDD_NF as an explicit feature Looks good to me. ------------- Marked as reviewed by sviswanathan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27320#pullrequestreview-3241321050 From coleenp at openjdk.org Thu Sep 18 18:35:39 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 18 Sep 2025 18:35:39 GMT Subject: RFR: 8367989: Remove InstanceKlass::allocate_objArray Message-ID: This change removes InstanceKlass::allocate_objArray and has its caller call ObjArrayKlass::allocate_instance directly from oopFactory, like the other array allocations do. See CR for more information why we should have this change. I also removed element_klass_addr() and moved element_klass_offset() to be in a more logical place near element_klass() functions. This upstreams a tiny valhalla diff. Tested with tier1-4. ------------- Commit messages: - 8367989: Remove InstanceKlass::allocate_objArray Changes: https://git.openjdk.org/jdk/pull/27372/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27372&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367989 Stats: 19 lines in 4 files changed: 3 ins; 14 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27372.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27372/head:pull/27372 PR: https://git.openjdk.org/jdk/pull/27372 From missa at openjdk.org Thu Sep 18 21:01:06 2025 From: missa at openjdk.org (Mohamed Issa) Date: Thu, 18 Sep 2025 21:01:06 GMT Subject: RFR: 8367611: Enable vblendvp[sd] on Future ECore Message-ID: <_Jk5fv1iO9ZPZyOtUAXeUez481RibKJR4FsUT_BnKm8=.2f68f9ee-9ce2-4dbb-be8b-1b9f910ba0e0@github.com> The upcoming ECore platforms will benefit from using `vblendvps` and `vblendvpd` instructions when the destination register is the same as the source register. This change takes that situation into account. The JTREG test shown below was used to verify correctness against the [OpenJDK v26-b15](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B15) baseline build. 1. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` ------------- Commit messages: - Add file missing from last commit - Use blend instruction when destination is same as source for certain ECore platforms Changes: https://git.openjdk.org/jdk/pull/27354/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27354&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367611 Stats: 14 lines in 3 files changed: 12 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27354.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27354/head:pull/27354 PR: https://git.openjdk.org/jdk/pull/27354 From sspitsyn at openjdk.org Thu Sep 18 21:32:51 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 18 Sep 2025 21:32:51 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v11] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 05:12:14 GMT, Leonid Mesnik wrote: >> The >> `SuspendResumeManager::suspend(bool register_vthread_SR)` >> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. >> >> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. >> >> The fix added some "asymmetry" in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > asseriton moved out This looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27317#pullrequestreview-3242159686 From sspitsyn at openjdk.org Thu Sep 18 21:32:53 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 18 Sep 2025 21:32:53 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v10] In-Reply-To: References: <5iVFEcNvcbry683t2HizWDraAcyf9j39LAwnoM5rm0E=.7270f60d-5427-4d8c-a69a-75bf60bf5e98@github.com> Message-ID: On Thu, 18 Sep 2025 04:50:01 GMT, Leonid Mesnik wrote: >> Thanks - though I find this code rather convoluted. We now always extract the `id` even though we only need it in the `register_vthread_SR == true` case. I tried different re-arrangements of the code to see if it could be cleaner, but the JVMTI part is just messy. > > Yes, the id is always extracted and the exposure of "raw" id on this level is not the good desing. However, I don't know how to implement this better. I'm not sure the exposure of "raw" id on this level is not a good design. The parameter `register_vthread_SR` looks somewhat messy as it is used under JVMTI ifdef's only. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27317#discussion_r2361236101 From kvn at openjdk.org Thu Sep 18 21:41:01 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 18 Sep 2025 21:41:01 GMT Subject: RFR: 8365823: Revert storing abstract and interface Klasses to non-class metaspace [v5] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 18:04:05 GMT, Coleen Phillimore wrote: >> This change removes the optimization to not store abstract and interface Klass metadata to non-class metaspace. Now all Klass metadata is in the Klass metaspace. This is simpler and less bug prone, and didn't help with the limitation of classes that can be stored in class metaspace materially. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Some limited additional cleanup to HotSpotMetaspaceConstantImpl.java on jvmci. Reran jvmci tests. Still good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27295#pullrequestreview-3242181368 From vpaprotski at openjdk.org Thu Sep 18 21:57:59 2025 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Thu, 18 Sep 2025 21:57:59 GMT Subject: RFR: 8367780: Enable UseAPX on Intel CPUs only when both APX_F and APX_NCI_NDD_NF cpuid features are present [v4] In-Reply-To: <-cYOL5wwp8oSisK5utj0B7mHi0D_Ne0i_N_RI-bsbLk=.87c1bc5f-a6a3-4d4e-9530-fc91e676656f@github.com> References: <-cYOL5wwp8oSisK5utj0B7mHi0D_Ne0i_N_RI-bsbLk=.87c1bc5f-a6a3-4d4e-9530-fc91e676656f@github.com> Message-ID: On Wed, 17 Sep 2025 17:54:49 GMT, Srinivas Vamsi Parasa wrote: >> The goal of this PR is to enable APX on Intel CPUs (i.e. enable UseAPX) only when both the APX_F and APX_NCI_NDD_NF cpuid feature flags are present. >> >> As per the latest update to the Intel APX specification (https://www.intel.com/content/www/us/en/content-details/861610/intel-advanced-performance-extensions-intel-apx-architecture-specification.html ), when APX_F is set, processors also provide CPUID leaf 0x29 (APX Advanced Performance Extensions Leaf). Any Intel processor that enumerates APX_F also enumerates APX_NCI_NDD_NF. >> >> This PR enhances the HotSpot x86 CPU feature detection to recognize the APX_NCI_NDD_NF sub-feature of Intel APX and update the enabling logic for UseAPX VM flag. > > Srinivas Vamsi Parasa has updated the pull request incrementally with two additional commits since the last revision: > > - Update CPUInfoTest.java > - Remove APX_NCI_NDD_NF as an explicit feature Thanks for answering my questions.. things we checked: - double-checked reg parameter values of cpuid against the spec - double-checked endianness of bitset variables in C grammar - double-checked how offset to the field std_cpuid29_ebx is computed Change looks good to me src/hotspot/cpu/x86/vm_version_x86.cpp line 2928: > 2926: if (sefsl1_cpuid7_edx.bits.apx_f != 0 && > 2927: xem_xcr0_eax.bits.apx_f != 0 && > 2928: std_cpuid29_ebx.bits.apx_nci_ndd_nf != 0) { was confused why the previous implementation was 'wrong'.. Please clarify that this was triggered "because" of the update to the spec (in the PR description). ------------- Marked as reviewed by vpaprotski (Committer). PR Review: https://git.openjdk.org/jdk/pull/27320#pullrequestreview-3242099089 PR Review Comment: https://git.openjdk.org/jdk/pull/27320#discussion_r2361188118 From duke at openjdk.org Thu Sep 18 22:09:00 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 18 Sep 2025 22:09:00 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v7] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 13:28:52 GMT, Ivan Walulya wrote: >> Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. >> >> Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. >> >> Testing: Tier 1-7 > > Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - make universal > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - Revert > - Thomas Review > - return on timeout > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - timed wait > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - ... and 5 more: https://git.openjdk.org/jdk/compare/4c7c009d...1a53c207 src/hotspot/share/memory/universe.hpp line 132: > 130: > 131: // Shutdown > 132: static volatile bool _is_shutting_down; If `_is_shutting_down` is in Universe, should ZGC/ZAbort hook into this too? It could be confusing that ZAbort reports that we are shutting down but the universe field does not report this. I would expect them both to report true. src/hotspot/share/services/cpuTimeUsage.cpp line 39: > 37: > 38: static inline jlong thread_cpu_time_or_zero(Thread* thread) { > 39: assert(!thread->has_terminated(), "Cannot get cpu time for terminated thread: %zu", thread->osthread()->thread_id_for_printing()); Are we sure that the thread is never in a de-allocated state here? I discussed adding an assert like that in `os::thread_cpu_time` but @dholmes-ora pointed out that such asserts are in general dangerous as the they may have been dealloacted and the assert itself could result in a segmentation fault. That being said, maybe we know that all threads we could possibly poke at here in this point could be terminated but not deallocated? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2361277250 PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2361281193 From duke at openjdk.org Thu Sep 18 22:09:02 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Thu, 18 Sep 2025 22:09:02 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v7] In-Reply-To: References: Message-ID: <2YPWvn-XmFS-P4PggP5HsRRStVRfa-l_UDeIbICRAMw=.0b3254fb-4e5c-4fd7-b7f1-00779fe75dd5@github.com> On Thu, 18 Sep 2025 22:01:23 GMT, Jonas Norlinder wrote: >> Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: >> >> - make universal >> - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs >> - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs >> - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs >> - Revert >> - Thomas Review >> - return on timeout >> - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs >> - timed wait >> - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs >> - ... and 5 more: https://git.openjdk.org/jdk/compare/4c7c009d...1a53c207 > > src/hotspot/share/services/cpuTimeUsage.cpp line 39: > >> 37: >> 38: static inline jlong thread_cpu_time_or_zero(Thread* thread) { >> 39: assert(!thread->has_terminated(), "Cannot get cpu time for terminated thread: %zu", thread->osthread()->thread_id_for_printing()); > > Are we sure that the thread is never in a de-allocated state here? I discussed adding an assert like that in `os::thread_cpu_time` but @dholmes-ora pointed out that such asserts are in general dangerous as the they may have been dealloacted and the assert itself could result in a segmentation fault. That being said, maybe we know that all threads we could possibly poke at here in this point could be terminated but not deallocated? The assert I had in mind was to check `_is_shutting_down` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2361287062 From missa at openjdk.org Thu Sep 18 23:28:07 2025 From: missa at openjdk.org (Mohamed Issa) Date: Thu, 18 Sep 2025 23:28:07 GMT Subject: RFR: 8367611: Enable vblendvp[sd] on Future ECore [v2] In-Reply-To: <_Jk5fv1iO9ZPZyOtUAXeUez481RibKJR4FsUT_BnKm8=.2f68f9ee-9ce2-4dbb-be8b-1b9f910ba0e0@github.com> References: <_Jk5fv1iO9ZPZyOtUAXeUez481RibKJR4FsUT_BnKm8=.2f68f9ee-9ce2-4dbb-be8b-1b9f910ba0e0@github.com> Message-ID: > The upcoming ECore platforms will benefit from using `vblendvps` and `vblendvpd` instructions when the destination register is the same as the source register. This change takes that situation into account. > > The JTREG test shown below was used to verify correctness against the [OpenJDK v26-b15](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B15) baseline build. > > 1. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: Use function to identify Darkmont cores instead of global flag ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27354/files - new: https://git.openjdk.org/jdk/pull/27354/files/078a295d..88ac7733 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27354&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27354&range=00-01 Stats: 18 lines in 4 files changed: 6 ins; 10 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27354.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27354/head:pull/27354 PR: https://git.openjdk.org/jdk/pull/27354 From dlong at openjdk.org Thu Sep 18 23:29:50 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 18 Sep 2025 23:29:50 GMT Subject: RFR: 8367325: [s390x] build failure due to JDK-8361376 [v5] In-Reply-To: References: Message-ID: <9oBJoM2n46eyKQdjnnLoBGEg5PZoENj7M42koNIOWxg=.208baa99-3cab-4f2b-ab7d-40d28da2dcde@github.com> On Thu, 18 Sep 2025 12:09:31 GMT, Amit Kumar wrote: >> Fixes the SIGLL caused after [JDK-8361376](https://bugs.openjdk.org/browse/JDK-8361376). >> >> Issue was with `cs` instruction, which requires the address to be aligned. And after this change address at which operating was not aligned. >> >> Wisdom from Principle of Z Operations: >> >> Sytax: CS R1,R3,D2(B2) >> >> Sytax: CSY R1,R3,D2(B2) >> >> ` >> The second operand of COMPARE AND SWAP (CS, CSY) must be designated on a word boundary. >> ` >> >> >> >> => 0x3fffc3149ba <_ZN17BarrierSetNMethod15set_guard_valueEP7nmethodii+266>: cs %r1,%r4,0(%r3) >> (gdb) i r r3 >> r3 0x3ffe500017a 4397593526650 >> (gdb) p ($r3 % 8) >> $5 = 2 >> (gdb) si >> >> Thread 16 "C1 CompilerThre" received signal SIGILL, Illegal instruction. >> NativeMethodBarrier::set_guard_value (bit_mask=2147483647, value=1, this=0x3ffe5000166) >> at /home/amit/jdk/src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp:74 >> 74 if (v == old_value) break; > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > update Looks reasonable to me. ------------- Marked as reviewed by dlong (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27213#pullrequestreview-3242337049 From kvn at openjdk.org Thu Sep 18 23:50:20 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 18 Sep 2025 23:50:20 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 14:49:48 GMT, Ashutosh Mehra wrote: > This PR removes the need to store entry point addresses in AdapterHandlerEntry by storing a direct pointer to AdapterBlob instead. Entry point addresses can be computed on the fly from the entry point offsets stored in AdapterBlob. Good. Few comments only src/hotspot/share/runtime/sharedRuntime.cpp line 2825: > 2823: int comp_args_on_stack = SharedRuntime::java_calling_convention(sig_bt, regs, total_args_passed); > 2824: address entry_address[AdapterBlob::ENTRY_COUNT]; > 2825: assert(AdapterBlob::ENTRY_COUNT == 4, "sanity"); Why you need this assert? Do you use `4` instead of `ENTRY_COUNT` somewhere? src/hotspot/share/runtime/sharedRuntime.cpp line 3034: > 3032: #endif // INCLUDE_CDS > 3033: > 3034: address AdapterHandlerEntry::base_address() { This method is used in `print_adapter_handler_info()` only after removal of `relocate()`. Consider using `adapter_blob->content_begin()` in `print_adapter_handler_info()` and remove this `base_address()` ------------- PR Review: https://git.openjdk.org/jdk/pull/27101#pullrequestreview-3242329072 PR Review Comment: https://git.openjdk.org/jdk/pull/27101#discussion_r2361367345 PR Review Comment: https://git.openjdk.org/jdk/pull/27101#discussion_r2361392408 From iklam at openjdk.org Fri Sep 19 01:38:25 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Sep 2025 01:38:25 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v8] In-Reply-To: References: Message-ID: > This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. > > - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. > - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. > - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: - Removed JVMCI-specific checks that are no longer necessary with class preloading -- all CP entries discoverable by JVMCI will always point to already-loaded classes - Simplify implementation after JDK-8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - @ashu-mehra comment: removed AOTLinkedClassBulkLoader::is_pending_aot_linked_class - @ashu-mehra review comments - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - @DanHeidinga comments -- added comments and asserts about the handling of enums - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase - ... and 17 more: https://git.openjdk.org/jdk/compare/91a97943...04cb7a64 ------------- Changes: https://git.openjdk.org/jdk/pull/26375/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=07 Stats: 903 lines in 43 files changed: 498 ins; 212 del; 193 mod Patch: https://git.openjdk.org/jdk/pull/26375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26375/head:pull/26375 PR: https://git.openjdk.org/jdk/pull/26375 From iklam at openjdk.org Fri Sep 19 01:44:26 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Sep 2025 01:44:26 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v8] In-Reply-To: References: Message-ID: <5_ai8lG-Zs7B3xi8XQ0dnrr2TDmywRALaeN0uyqyUQ8=.18e3bfa2-9512-4173-8fc3-a83d827e7353@github.com> On Fri, 19 Sep 2025 01:38:25 GMT, Ioi Lam wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: > > - Removed JVMCI-specific checks that are no longer necessary with class preloading -- all CP entries discoverable by JVMCI will always point to already-loaded classes > - Simplify implementation after JDK-8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - @ashu-mehra comment: removed AOTLinkedClassBulkLoader::is_pending_aot_linked_class > - @ashu-mehra review comments > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - @DanHeidinga comments -- added comments and asserts about the handling of enums > - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase > - ... and 17 more: https://git.openjdk.org/jdk/compare/91a97943...04cb7a64 @ashu-mehra , I've remove all the code that was needed to handle aot-linked classes from the dynamic archive but is no longer needed since [JDK-8367366](https://bugs.openjdk.org/browse/JDK-8367366). I am able to remove about 200 lines of code. I also renamed a few functions in `AOTLinkedClassBulkLoader` to reflect the up-to-date meaning. `CDSConfig::is_using_preloaded_classes()` has been removed and replaced with `CDSConfig::is_using_aot_linked_classes()` The handling of `fixup_mirror_list()` and `fixup_module_field_list()` in javaClasses.cpp have been made uniform. Please see https://github.com/openjdk/jdk/pull/26375/commits/896ce8b9636a5534f1db487afbe27e875022fbfa ------------- PR Comment: https://git.openjdk.org/jdk/pull/26375#issuecomment-3310193834 From iklam at openjdk.org Fri Sep 19 02:10:15 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Sep 2025 02:10:15 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v5] In-Reply-To: References: Message-ID: > This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. > > This PR annotates a single class, `jdk.internal.math.MathUtils` (also the object hierarchy root class, `Object.class`, which has no associated AOT initialization but is required for completeness). More classes will be added in future PRs. > > If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to > - All of `K`'s super classes > - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` > > Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). > > This annotation is awfully similar to `@AOTSafeClassInitializer`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: - Updated requirements for annotations on supertypes for AOTInitialize and AOTSafeClassInitializer - Merge branch 'master' into aot-initialize-math-utils - Added logging about @AOTSafeClassInitializer classes that have not been initialized - Added comment about the order of FinalImageRecipes::apply_recipes() vs link_all_loaded_classes() - Exclude more GC heap size tests as AOT cache size has increased for "make test JTREG=AOT_JDK=onestep ..." - Added javadoc; added test case; code clean up - Merge branch 'master' into aot-initialize-math-utils - cleanup - Merge branch 'master' into aot-initialize-math-utils - Merge branch '8366477-refactor-aot-related-flag-bits-in-klass-hpp' into aot-initialize-math-utils - ... and 13 more: https://git.openjdk.org/jdk/compare/7ec3fa5f...d21bfb12 ------------- Changes: https://git.openjdk.org/jdk/pull/27024/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27024&range=04 Stats: 350 lines in 12 files changed: 288 ins; 54 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/27024.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27024/head:pull/27024 PR: https://git.openjdk.org/jdk/pull/27024 From iklam at openjdk.org Fri Sep 19 02:10:16 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Sep 2025 02:10:16 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v4] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 19:08:46 GMT, Ashutosh Mehra wrote: > > Note, the check of the above requirement has been moved to AOTClassInitializer::check_aot_annotations(). The previous check in ClassFileParser was not executed because the class is loaded in the AOT training run, where CDSConfig::is_initing_classes_at_dump_time() returns false (this function returns true only in the AOT assembly phase). > > So this is a bug already present in the code and effectively disables super type checks for AOTSafeClassInitializer annotation, is that right? Yes, that's a bug in the current code in the mainline. > There is a reference to ClassFileParser in the documentation for AOTSafeClassInitializer. I think it needs to be updated as well: > > https://github.com/openjdk/jdk/blob/18dc186a8f4820ed78c21173713dd127ef512e1f/src/java.base/share/classes/jdk/internal/vm/annotation/AOTSafeClassInitializer.java#L124-L129 I updated the requirements about safety and supertypes for both `AOTInitialize` and `AOTSafeClassInitializer` to use the exact same wording. I think it's OK to describe the effect (the AOT assembly phase will fail) without the details about where we do the checks: /// Before adding this annotation to a class _X_, the author must determine /// that it's safe to execute the static initializer of _X_ during the AOT /// assembly phase. In addition, all supertypes of _X_ must also have this /// annotation. If a supertype of _X_ is found to be missing this annotation, /// the AOT assembly phase will fail. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27024#issuecomment-3310249049 From iklam at openjdk.org Fri Sep 19 02:14:31 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Sep 2025 02:14:31 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v4] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 19:05:37 GMT, Ashutosh Mehra wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Added logging about @AOTSafeClassInitializer classes that have not been initialized > > src/hotspot/share/cds/aotClassInitializer.cpp line 53: > >> 51: >> 52: if (ik->force_aot_initialization()) { >> 53: assert(ik->is_initialized(), "must have been initialized before this check"); > > Is it not possible for a jdk class to be loaded but not initialized during an application run? If such a jdk class is marked with AOTInitialize annotation, this assert would trigger during the assembly phase. We come to here only in the assembly phase, after this check: if (!CDSConfig::is_initing_classes_at_dump_time()) { return false; } In the training run, `is_initing_classes_at_dump_time()` returns false. Also, in `AOTMetaspace::try_link_class()`, which is called before we enter the CDS safepoint, we try to initialize all `force_aot_initialization()` classes in this loop: https://github.com/openjdk/jdk/blob/d21bfb1231bec75bc6eb6eaac33c95ed833565fb/src/hotspot/share/cds/aotMetaspace.cpp#L1262-L1272 When we come to here, we are already in the CDS safepoint, so all classes with `force_aot_initialization()` must have been initialized. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27024#discussion_r2361539771 From dholmes at openjdk.org Fri Sep 19 02:48:27 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Sep 2025 02:48:27 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v5] In-Reply-To: References: Message-ID: <9GaOIC1GMr4TNQ-P-K54NJF-vVqaAFAOFVNZNNOpWM4=.a2c29f92-b499-4780-8187-82693d512448@github.com> On Thu, 18 Sep 2025 07:41:31 GMT, Johan Sj?len wrote: >> Hi, >> >> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array` to store the offsets in and an `Array` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`. >> >> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately. >> >> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc. >> >> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement. >> >> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Fix rename This looks good. I think it will be easier to understand for newcomers to the code. One query: have you done any performance measurements for this change? I'm a little concerned that the insertion iterator and the internal array management is now more heavyweight than the old array management. I don't understand the existing "operand" terminology and it seems even less appropriate now. It would be good to change this, but can be left for future RFE. A number of nits, mainly indentation. Thanks src/hotspot/share/oops/constantPool.cpp line 1784: > 1782: int k1 = from_cp->bootstrap_methods_attribute_index(from_i); > 1783: int k2 = from_cp->bootstrap_name_and_type_ref_index_at(from_i); > 1784: k1 += to_cp->bsm_entries().array_length(); // to_cp might already have operands Here and below can we replace "operands" with something better? I didn't understand its use initially and now we don't have an operand array it seems even less informative. src/hotspot/share/oops/constantPool.cpp line 2303: > 2301: st->print("constant pool [%d]", length()); > 2302: if (has_preresolution()) st->print("/preresolution"); > 2303: if (!bsm_entries().is_empty()) st->print("/operands[%d]", bsm_entries().bootstrap_methods()->length()); Again is "operands" a meaningful description? src/hotspot/share/oops/constantPool.cpp line 2358: > 2356: InsertionIterator iter = start_extension(other.number_of_entries(), other.array_length(), loader_data, CHECK_(BSMAttributeEntries::InsertionIterator())); > 2357: return iter; > 2358: } Suggestion: BSMAttributeEntries::InsertionIterator BSMAttributeEntries::start_extension(const BSMAttributeEntries& other, ClassLoaderData* loader_data, TRAPS) { InsertionIterator iter = start_extension(other.number_of_entries(), other.array_length(), loader_data, CHECK_(BSMAttributeEntries::InsertionIterator())); return iter; } src/hotspot/share/oops/constantPool.cpp line 2362: > 2360: BSMAttributeEntries::InsertionIterator > 2361: BSMAttributeEntries::start_extension(int number_of_entries, int array_length, > 2362: ClassLoaderData* loader_data, TRAPS) { Suggestion: ClassLoaderData* loader_data, TRAPS) { Fix indent src/hotspot/share/oops/constantPool.cpp line 2391: > 2389: other.copy_into(iter, other.number_of_entries()); > 2390: end_extension(iter, loader_data, THREAD); > 2391: Suggestion: src/hotspot/share/oops/constantPool.cpp line 2399: > 2397: assert(iter._cur_array <= this->_bootstrap_methods->length(), "must be"); > 2398: > 2399: // Did we fill up all of the available space? If so, do nothing Suggestion: // Did we fill up all of the available space? If so, do nothing. src/hotspot/share/oops/constantPool.hpp line 665: > 663: bool compare_bootstrap_entry_to(int bsms_attribute_index1, const constantPoolHandle& cp2, > 664: int bsms_attribute_index2); > 665: // Find a BSM entry in search_cp that matches the BSM at bsm_attribute_index Suggestion: // Find a BSM entry in search_cp that matches the BSM at bsm_attribute_index. src/hotspot/share/oops/constantPool.hpp line 668: > 666: // Return -1 if not found. > 667: int find_matching_bsm_entry(int bsms_attribute_index, const constantPoolHandle& search_cp, > 668: int offset_limit); Suggestion: int find_matching_bsm_entry(int bsms_attribute_index, const constantPoolHandle& search_cp, int offset_limit); Fix indent src/hotspot/share/oops/constantPool.inline.hpp line 93: > 91: inline BSMAttributeEntry* BSMAttributeEntries::InsertionIterator::reserve_new_entry(u2 bsmi, u2 argc) { > 92: if (_cur_offset + 1 > insert_into->offsets()->length() || > 93: _cur_array + 1 + 1 + argc > insert_into->bootstrap_methods()->length()) { The `+ 1 + 1 + argc` looks a little magical - can we factor it out and explain it e.g. int next_array = _cur_array + 1 /* ??? */ + 1 /* ??? */ + argc; ... _curr_array = next_array; ... src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 713: > 711: // forward reference in *merge_cp_p or not a direct match > 712: int found_i = scratch_cp->find_matching_bsm_entry(old_bs_i, *merge_cp_p, > 713: max_offset_in_merge); Suggestion: int found_i = scratch_cp->find_matching_bsm_entry(old_bs_i, *merge_cp_p, max_offset_in_merge); Fix indent src/hotspot/share/prims/jvmtiRedefineClasses.hpp line 451: > 449: bool merge_constant_pools(const constantPoolHandle& old_cp, > 450: const constantPoolHandle& scratch_cp, constantPoolHandle& merge_cp_p, > 451: int& merge_cp_length_p, TRAPS); Pre-existing but none of the line-wrapping indentation is correct in this section of the file. ------------- PR Review: https://git.openjdk.org/jdk/pull/27198#pullrequestreview-3237461571 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2361464715 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2361479948 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2361487875 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2361489262 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2361209369 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2361210519 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2361528513 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2361225007 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2361234056 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2361542260 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2361569102 From dholmes at openjdk.org Fri Sep 19 02:48:30 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Sep 2025 02:48:30 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v4] In-Reply-To: <_l9gNHqLkkeioUXxWsXpWKp01ft-E06ucp_s5JUPwMo=.1879d0bf-aefd-4912-9ec5-f6d4989396f5@github.com> References: <_l9gNHqLkkeioUXxWsXpWKp01ft-E06ucp_s5JUPwMo=.1879d0bf-aefd-4912-9ec5-f6d4989396f5@github.com> Message-ID: On Wed, 17 Sep 2025 07:26:34 GMT, Johan Sj?len wrote: >> Hi, >> >> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array` to store the offsets in and an `Array` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`. >> >> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately. >> >> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc. >> >> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement. >> >> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again. > > Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/hotspot/share/prims/jvmtiRedefineClasses.hpp > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> > - Update src/hotspot/share/oops/constantPool.cpp > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> src/hotspot/share/classfile/classFileParser.cpp line 51: > 49: #include "oops/annotations.hpp" > 50: #include "oops/constantPool.hpp" > 51: #include "oops/constantPool.inline.hpp" Suggestion: #include "oops/constantPool.inline.hpp" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2357647450 From dholmes at openjdk.org Fri Sep 19 02:48:31 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Sep 2025 02:48:31 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v5] In-Reply-To: <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com> References: <6nQvUTQVFCfVwzibTxjwXW7Z5dy40kbuzqUdc0J6RXQ=.6b17cf92-3ff5-46b0-a078-fddb0642dedd@github.com> Message-ID: On Tue, 16 Sep 2025 05:52:05 GMT, David Holmes wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix rename > > src/hotspot/share/oops/constantPool.cpp line 1625: > >> 1623: void ConstantPool::copy_bsm_entries(const constantPoolHandle& from_cp, >> 1624: const constantPoolHandle& to_cp, >> 1625: TRAPS) { > > Suggestion: > > void ConstantPool::copy_bsm_entries(const constantPoolHandle& from_cp, > const constantPoolHandle& to_cp, > TRAPS) { > > Fix indent Still not fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2361462226 From iklam at openjdk.org Fri Sep 19 03:06:42 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Sep 2025 03:06:42 GMT Subject: RFR: 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition() [v2] In-Reply-To: References: Message-ID: > Simplify the boilerplate code in jvm.cpp that calls `JvmtiThreadState::class_to_verify_considering_redefinition()`, and reduce the number of `InstanceKlass::cast()` calls. > > I also changed a few fields/arguments from `Klass*` to `InstanceKlass*` as these are used exclusively with `InstanceKlass*`. Ioi Lam 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 three additional commits since the last revision: - @coleenp and @dholmes-ora comments -- simplify implementation; fixed code formatting - Merge branch 'master' into 8367719-refactor-jni-code-that-uses-class_to_verify_considering_redefinition - 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27303/files - new: https://git.openjdk.org/jdk/pull/27303/files/e9d9546a..2504e1a6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27303&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27303&range=00-01 Stats: 10736 lines in 233 files changed: 4911 ins; 2614 del; 3211 mod Patch: https://git.openjdk.org/jdk/pull/27303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27303/head:pull/27303 PR: https://git.openjdk.org/jdk/pull/27303 From iklam at openjdk.org Fri Sep 19 03:10:35 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Sep 2025 03:10:35 GMT Subject: RFR: 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition() [v2] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 15:57:48 GMT, Coleen Phillimore wrote: >> Ioi Lam 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 three additional commits since the last revision: >> >> - @coleenp and @dholmes-ora comments -- simplify implementation; fixed code formatting >> - Merge branch 'master' into 8367719-refactor-jni-code-that-uses-class_to_verify_considering_redefinition >> - 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition() > > src/hotspot/share/prims/jvm.cpp line 2291: > >> 2289: >> 2290: JVM_ENTRY(const char*, JVM_GetClassNameUTF(JNIEnv *env, jclass cls)) >> 2291: Klass* k = get_klass_considering_redefinition(cls, thread); > > Even if it's a redefined class, it'll have the same name so this isn't necessary. I usually don't want to make semantic changes in a clean-up PR, but this one seems pretty safe so I changed it anyway. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2361635458 From iklam at openjdk.org Fri Sep 19 03:10:32 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Sep 2025 03:10:32 GMT Subject: RFR: 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition() [v2] In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 06:41:52 GMT, David Holmes wrote: >> Ioi Lam 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 three additional commits since the last revision: >> >> - @coleenp and @dholmes-ora comments -- simplify implementation; fixed code formatting >> - Merge branch 'master' into 8367719-refactor-jni-code-that-uses-class_to_verify_considering_redefinition >> - 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition() > > Looks good. Just some minor nits. > > Thanks Thanks for the comments @dholmes-ora and @coleenp. I've made the changes you suggested. > I sort of think there's no need for the Klass* version of get_class_considering_redefinition since its callers seem to really want an InstanceKlass. Since it's jvm.cpp, you can probably verify that it's never Klass in these callers. I think it's valid for some of the functions to be called with a non-instance klass, so I use the `get_instance_klass_considering_redefinition()` version only when the original code was doing an `InstanceKlass::cast()`. For functions like this one, I am keeping the type checks in the original code: JVM_ENTRY(jint, JVM_GetClassMethodsCount(JNIEnv *env, jclass cls)) Klass* k = get_klass_considering_redefinition(cls, thread); return (!k->is_instance_klass()) ? 0 : InstanceKlass::cast(k)->methods()->length(); JVM_END I did remove the `Klass*` version from jvmThreadState.hpp. I also updated the comments to reflect the new naming. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27303#issuecomment-3310354049 From amitkumar at openjdk.org Fri Sep 19 04:36:27 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Fri, 19 Sep 2025 04:36:27 GMT Subject: RFR: 8367325: [s390x] build failure due to JDK-8361376 [v5] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 12:09:31 GMT, Amit Kumar wrote: >> Fixes the SIGLL caused after [JDK-8361376](https://bugs.openjdk.org/browse/JDK-8361376). >> >> Issue was with `cs` instruction, which requires the address to be aligned. And after this change address at which operating was not aligned. >> >> Wisdom from Principle of Z Operations: >> >> Sytax: CS R1,R3,D2(B2) >> >> Sytax: CSY R1,R3,D2(B2) >> >> ` >> The second operand of COMPARE AND SWAP (CS, CSY) must be designated on a word boundary. >> ` >> >> >> >> => 0x3fffc3149ba <_ZN17BarrierSetNMethod15set_guard_valueEP7nmethodii+266>: cs %r1,%r4,0(%r3) >> (gdb) i r r3 >> r3 0x3ffe500017a 4397593526650 >> (gdb) p ($r3 % 8) >> $5 = 2 >> (gdb) si >> >> Thread 16 "C1 CompilerThre" received signal SIGILL, Illegal instruction. >> NativeMethodBarrier::set_guard_value (bit_mask=2147483647, value=1, this=0x3ffe5000166) >> at /home/amit/jdk/src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp:74 >> 74 if (v == old_value) break; > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > update thank you so much for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27213#issuecomment-3310518817 From amitkumar at openjdk.org Fri Sep 19 04:36:28 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Fri, 19 Sep 2025 04:36:28 GMT Subject: Integrated: 8367325: [s390x] build failure due to JDK-8361376 In-Reply-To: References: Message-ID: On Thu, 11 Sep 2025 09:51:29 GMT, Amit Kumar wrote: > Fixes the SIGLL caused after [JDK-8361376](https://bugs.openjdk.org/browse/JDK-8361376). > > Issue was with `cs` instruction, which requires the address to be aligned. And after this change address at which operating was not aligned. > > Wisdom from Principle of Z Operations: > > Sytax: CS R1,R3,D2(B2) > > Sytax: CSY R1,R3,D2(B2) > > ` > The second operand of COMPARE AND SWAP (CS, CSY) must be designated on a word boundary. > ` > > > > => 0x3fffc3149ba <_ZN17BarrierSetNMethod15set_guard_valueEP7nmethodii+266>: cs %r1,%r4,0(%r3) > (gdb) i r r3 > r3 0x3ffe500017a 4397593526650 > (gdb) p ($r3 % 8) > $5 = 2 > (gdb) si > > Thread 16 "C1 CompilerThre" received signal SIGILL, Illegal instruction. > NativeMethodBarrier::set_guard_value (bit_mask=2147483647, value=1, this=0x3ffe5000166) > at /home/amit/jdk/src/hotspot/cpu/s390/gc/shared/barrierSetNMethod_s390.cpp:74 > 74 if (v == old_value) break; This pull request has now been integrated. Changeset: 898fcff0 Author: Amit Kumar URL: https://git.openjdk.org/jdk/commit/898fcff03745da29318e29ead189d78f8daa6988 Stats: 33 lines in 3 files changed: 23 ins; 1 del; 9 mod 8367325: [s390x] build failure due to JDK-8361376 Reviewed-by: mdoerr, dlong ------------- PR: https://git.openjdk.org/jdk/pull/27213 From iklam at openjdk.org Fri Sep 19 04:46:13 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Sep 2025 04:46:13 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v9] In-Reply-To: References: Message-ID: > This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. > > - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. > - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. > - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Fixed 32-bit builds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26375/files - new: https://git.openjdk.org/jdk/pull/26375/files/04cb7a64..9ec10f5f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=07-08 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26375/head:pull/26375 PR: https://git.openjdk.org/jdk/pull/26375 From dholmes at openjdk.org Fri Sep 19 05:02:18 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Sep 2025 05:02:18 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v6] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 09:04:53 GMT, Albert Mingkun Yang wrote: > > Though I still wonder if this aspect of shutdown should be part of "Heap" (or Universe) rather than G1 specific. > > Why is it G1 specific? The new `bool _is_shutting_down` lives inside `CollectedHeap` -- Serial/Parallel/G1 are all updated to use it. My mistake, I didn't track the changes enough and was just looking at all the G1 files involved. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27190#issuecomment-3310561420 From dholmes at openjdk.org Fri Sep 19 05:02:20 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Sep 2025 05:02:20 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v7] In-Reply-To: <2YPWvn-XmFS-P4PggP5HsRRStVRfa-l_UDeIbICRAMw=.0b3254fb-4e5c-4fd7-b7f1-00779fe75dd5@github.com> References: <2YPWvn-XmFS-P4PggP5HsRRStVRfa-l_UDeIbICRAMw=.0b3254fb-4e5c-4fd7-b7f1-00779fe75dd5@github.com> Message-ID: On Thu, 18 Sep 2025 22:05:59 GMT, Jonas Norlinder wrote: >> src/hotspot/share/services/cpuTimeUsage.cpp line 39: >> >>> 37: >>> 38: static inline jlong thread_cpu_time_or_zero(Thread* thread) { >>> 39: assert(!thread->has_terminated(), "Cannot get cpu time for terminated thread: %zu", thread->osthread()->thread_id_for_printing()); >> >> Are we sure that the thread is never in a de-allocated state here? I discussed adding an assert like that in `os::thread_cpu_time` but @dholmes-ora pointed out that such asserts are in general dangerous as the they may have been dealloacted and the assert itself could result in a segmentation fault. That being said, maybe we know that all threads we could possibly poke at here in this point could be terminated but not deallocated? > > The assert I had in mind was to check `_is_shutting_down` To be clear, unless you have done something to ensure a terminated thread cannot progress to deallocated, then you cannot safely query if it may be terminated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2361769389 From iwalulya at openjdk.org Fri Sep 19 05:10:22 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 19 Sep 2025 05:10:22 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v7] In-Reply-To: <2YPWvn-XmFS-P4PggP5HsRRStVRfa-l_UDeIbICRAMw=.0b3254fb-4e5c-4fd7-b7f1-00779fe75dd5@github.com> References: <2YPWvn-XmFS-P4PggP5HsRRStVRfa-l_UDeIbICRAMw=.0b3254fb-4e5c-4fd7-b7f1-00779fe75dd5@github.com> Message-ID: <1a-5AHawGFCl1Zab3YmkwEzUj8MuCq9DR-ma30usfsI=.7007a34d-9abb-469b-b40a-091217102a08@github.com> On Thu, 18 Sep 2025 22:05:59 GMT, Jonas Norlinder wrote: >> src/hotspot/share/services/cpuTimeUsage.cpp line 39: >> >>> 37: >>> 38: static inline jlong thread_cpu_time_or_zero(Thread* thread) { >>> 39: assert(!thread->has_terminated(), "Cannot get cpu time for terminated thread: %zu", thread->osthread()->thread_id_for_printing()); >> >> Are we sure that the thread is never in a de-allocated state here? I discussed adding an assert like that in `os::thread_cpu_time` but @dholmes-ora pointed out that such asserts are in general dangerous as the they may have been dealloacted and the assert itself could result in a segmentation fault. That being said, maybe we know that all threads we could possibly poke at here in this point could be terminated but not deallocated? > > The assert I had in mind was to check `_is_shutting_down` Thanks @JonasNorlinder and @dholmes-ora for pointing this out, I will use `_is_shutting_down` as suggested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2361783277 From iwalulya at openjdk.org Fri Sep 19 05:17:23 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 19 Sep 2025 05:17:23 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v8] In-Reply-To: References: Message-ID: > Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. > > Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. > > Testing: Tier 1-7 Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: remove assert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27190/files - new: https://git.openjdk.org/jdk/pull/27190/files/1a53c207..46add7af Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27190.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27190/head:pull/27190 PR: https://git.openjdk.org/jdk/pull/27190 From dholmes at openjdk.org Fri Sep 19 05:30:16 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Sep 2025 05:30:16 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing [v4] In-Reply-To: <3tx8u2KSzSzLQG8wa-YCiQGCwS--B1q56JZFiYbklhQ=.396d1328-3591-46de-9e82-5e3a065c8b8a@github.com> References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> <3tx8u2KSzSzLQG8wa-YCiQGCwS--B1q56JZFiYbklhQ=.396d1328-3591-46de-9e82-5e3a065c8b8a@github.com> Message-ID: On Thu, 18 Sep 2025 14:51:33 GMT, Johannes Bechberger wrote: >> This change hopefully fixes the test failures by making the test cases more resilient. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove synchronized I will run the updated test through our CI ... ------------- PR Comment: https://git.openjdk.org/jdk/pull/27293#issuecomment-3310645145 From dholmes at openjdk.org Fri Sep 19 06:00:43 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Sep 2025 06:00:43 GMT Subject: RFR: 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition() [v2] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 03:06:42 GMT, Ioi Lam wrote: >> Simplify the boilerplate code in jvm.cpp that calls `JvmtiThreadState::class_to_verify_considering_redefinition()`, and reduce the number of `InstanceKlass::cast()` calls. >> >> I also changed a few fields/arguments from `Klass*` to `InstanceKlass*` as these are used exclusively with `InstanceKlass*`. > > Ioi Lam 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 three additional commits since the last revision: > > - @coleenp and @dholmes-ora comments -- simplify implementation; fixed code formatting > - Merge branch 'master' into 8367719-refactor-jni-code-that-uses-class_to_verify_considering_redefinition > - 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition() Looks good! Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27303#pullrequestreview-3243228173 From dholmes at openjdk.org Fri Sep 19 06:02:19 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Sep 2025 06:02:19 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v11] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 05:12:14 GMT, Leonid Mesnik wrote: >> The >> `SuspendResumeManager::suspend(bool register_vthread_SR)` >> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. >> >> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. >> >> The fix added some "asymmetry" in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > asseriton moved out Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27317#pullrequestreview-3243235465 From mhaessig at openjdk.org Fri Sep 19 06:28:21 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Fri, 19 Sep 2025 06:28:21 GMT Subject: RFR: 8367862: debug.cpp: Do not print help message for methods not compiled in In-Reply-To: References: Message-ID: <8Q5wZJn9YFiAEqORmPkRsFXe_7burF_dFJWZw4H3Jb4=.8e4393f7-68b6-40e0-b5c4-cbf95792ff42@github.com> On Wed, 17 Sep 2025 11:27:27 GMT, Kerem Kat wrote: > The `help` command in `debug.cpp` was out of date, listing only a fraction of the available functions. This and other commands callable from gdb via `call help()`. > > I added all commands to the help message, except `pns2` as it is documented as not being useful when called from gdb. > > Also fixed is the message for the conditional `pns` command appearing in PRODUCT builds. Thank you for providing this improvement, @krk! This sure is a good quality of life improvement. I do have a few suggestions below. Also, please update either the JBS issue description or the PR title so they match up. src/hotspot/share/utilities/debug.cpp line 661: > 659: tty->print_cr(" findm(intptr_t pc) - finds Method*"); > 660: tty->print_cr(" find(intptr_t x) - finds & prints nmethod/stub/bytecode/oop based on pointer into it"); > 661: tty->print_cr(" findpc(intptr_t x) - finds & prints nmethod/stub/bytecode/oop based on pointer into it (verbose)"); Since you are touching this, it would be good to make the grammar consistent. My suggestion is to do it like above and drop the "s" on all verbs to describe to the user what they can do with the function. Suggestion: tty->print_cr(" findnm(intptr_t pc) - find nmethod*"); tty->print_cr(" findm(intptr_t pc) - find Method*"); tty->print_cr(" find(intptr_t x) - find & print nmethod/stub/bytecode/oop based on pointer into it"); tty->print_cr(" findpc(intptr_t x) - find & print nmethod/stub/bytecode/oop based on pointer into it (verbose)"); Could you do that for the rest as well? src/hotspot/share/utilities/debug.cpp line 667: > 665: tty->print_cr(" pns($sp, $rbp, $pc) on Linux/amd64 or"); > 666: tty->print_cr(" pns($sp, $ebp, $pc) on Linux/x86 or"); > 667: tty->print_cr(" pns($sp, $fp, $pc) on Linux/AArch64 or"); Since you are already ifdefing, you could go all the way and only print one of the pns examples: Suggestion: tty->print_cr(" pns(void* sp, void* fp, void* pc) - print native (i.e. mixed) stack trace. E.g."); #ifdef LINUX AMD64_ONLY(tty->print_cr(" pns($sp, $rbp, $pc) on Linux/amd64");) IA32_ONLY(tty->print_cr(" pns($sp, $ebp, $pc) on Linux/x86");) AARCH64_ONLY(tty->print_cr(" pns($sp, $fp, $pc) on Linux/AArch64");) (this is not a complete suggestion, because Github won't let me...) src/hotspot/share/utilities/debug.cpp line 673: > 671: tty->print_cr(" - in gdb do 'set overload-resolution off' before calling pns()"); > 672: tty->print_cr(" - in dbx do 'frame 1' before calling pns()"); > 673: #endif Suggestion: #endif // !PRODUCT Nit: this is my readability pet peeve. src/hotspot/share/utilities/debug.cpp line 703: > 701: > 702: tty->print_cr("compiler debugging"); > 703: tty->print_cr(" debug() - to set things up for compiler debugging"); Suggestion: tty->print_cr(" debug() - set things up for compiler debugging"); One last grammar nit. ------------- Changes requested by mhaessig (Committer). PR Review: https://git.openjdk.org/jdk/pull/27341#pullrequestreview-3243305992 PR Review Comment: https://git.openjdk.org/jdk/pull/27341#discussion_r2361903475 PR Review Comment: https://git.openjdk.org/jdk/pull/27341#discussion_r2361900556 PR Review Comment: https://git.openjdk.org/jdk/pull/27341#discussion_r2361906096 PR Review Comment: https://git.openjdk.org/jdk/pull/27341#discussion_r2361910106 From dholmes at openjdk.org Fri Sep 19 06:31:17 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 19 Sep 2025 06:31:17 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing [v4] In-Reply-To: <3tx8u2KSzSzLQG8wa-YCiQGCwS--B1q56JZFiYbklhQ=.396d1328-3591-46de-9e82-5e3a065c8b8a@github.com> References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> <3tx8u2KSzSzLQG8wa-YCiQGCwS--B1q56JZFiYbklhQ=.396d1328-3591-46de-9e82-5e3a065c8b8a@github.com> Message-ID: On Thu, 18 Sep 2025 14:51:33 GMT, Johannes Bechberger wrote: >> This change hopefully fixes the test failures by making the test cases more resilient. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove synchronized The test is still failing in our CI on linux-aarch64-debug: [58.916s][info][jfr,startup] Started recording 1. No limit specified, using maxsize=250MB as default. [58.916s][info][jfr,startup] [58.916s][info][jfr,startup] Use jcmd 2600244 JFR.dump name=1 filename=FILEPATH to copy recording data to file. Lost samples: 41 at 978 start time 1758260993451 Lost samples in time box 0: 0 Lost samples: 5 at 1078 start time 1758260993451 Lost samples in time box 1959: 0 Lost samples in time box 2967: 0 Lost samples in time box 3969: 0 Lost samples in time box 4970: 0 ----------System.err:(15/1004)---------- java.lang.RuntimeException: assertTrue: expected true, was false at jdk.test.lib.Asserts.fail(Asserts.java:715) at jdk.test.lib.Asserts.assertTrue(Asserts.java:545) at jdk.test.lib.Asserts.assertTrue(Asserts.java:531) at jdk.jfr.event.profiling.TestCPUTimeSampleQueueAutoSizes.checkThatLossDecreased(TestCPUTimeSampleQueueAutoSizes.java:154) at jdk.jfr.event.profiling.TestCPUTimeSampleQueueAutoSizes.main(TestCPUTimeSampleQueueAutoSizes.java:136) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1474) I ran with `-Xcomp -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:+TieredCompilation -XX:+VerifyOops'` as used in some of our higher tier testing where we saw initial failures. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27293#issuecomment-3310786254 From mhaessig at openjdk.org Fri Sep 19 06:55:05 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Fri, 19 Sep 2025 06:55:05 GMT Subject: RFR: 8367611: Enable vblendvp[sd] on Future ECore [v2] In-Reply-To: References: <_Jk5fv1iO9ZPZyOtUAXeUez481RibKJR4FsUT_BnKm8=.2f68f9ee-9ce2-4dbb-be8b-1b9f910ba0e0@github.com> Message-ID: On Thu, 18 Sep 2025 23:28:07 GMT, Mohamed Issa wrote: >> The upcoming ECore platforms will benefit from using `vblendvps` and `vblendvpd` instructions when the destination register is the same as the source register. This change takes that situation into account. >> >> The JTREG test shown below was used to verify correctness against the [OpenJDK v26-b15](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B15) baseline build. >> >> 1. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` > > Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: > > Use function to identify Darkmont cores instead of global flag Thank you for this improvement, @missa-prime! The change looks good to me, but I have a question. > The JTREG test shown below was used to verify correctness against the [OpenJDK v26-b15](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B15) baseline build. > - jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java Can you elaborate, what this verification entails? Why this test? ------------- Changes requested by mhaessig (Committer). PR Review: https://git.openjdk.org/jdk/pull/27354#pullrequestreview-3243446726 From ayang at openjdk.org Fri Sep 19 07:57:49 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 19 Sep 2025 07:57:49 GMT Subject: RFR: 8368072: Remove redundant arguments of MarkingNMethodClosure Message-ID: "Inline" statically known value to callee to simplify `MarkingNMethodClosure`. Test: tier1 ------------- Commit messages: - nmethod-closure-remove-arg Changes: https://git.openjdk.org/jdk/pull/27382/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27382&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368072 Stats: 21 lines in 6 files changed: 0 ins; 11 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/27382.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27382/head:pull/27382 PR: https://git.openjdk.org/jdk/pull/27382 From stefank at openjdk.org Fri Sep 19 08:17:47 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 19 Sep 2025 08:17:47 GMT Subject: RFR: 8367989: Remove InstanceKlass::allocate_objArray In-Reply-To: References: Message-ID: <6VeFjixTLN_lcvaVt3RO_YjGMXUXuQ6DNe71Rf9XxCk=.17ee1a0d-07b9-41db-b7f6-2c79c04d5e69@github.com> On Thu, 18 Sep 2025 18:27:14 GMT, Coleen Phillimore wrote: > This change removes InstanceKlass::allocate_objArray and has its caller call ObjArrayKlass::allocate_instance directly from oopFactory, like the other array allocations do. See CR for more information why we should have this change. I also removed element_klass_addr() and moved element_klass_offset() to be in a more logical place near element_klass() functions. This upstreams a tiny valhalla diff. > Tested with tier1-4. src/hotspot/share/memory/oopFactory.cpp line 112: > 110: } else { > 111: ArrayKlass* ak = InstanceKlass::cast(klass)->array_klass(CHECK_NULL); > 112: return ObjArrayKlass::cast(ak)->allocate_instance(length, THREAD); Before this change the two if/else branches had a symmetry that is lost with the proposed change. It makes you look at the code and wonder what the reason is for this asymmetry. Could the symmetry be retained by changing this to: objArrayOop oopFactory::new_objArray(Klass* klass, int length, TRAPS) { ArrayKlass* ak; if (klass->is_array_klass()) { ak = ArrayKlass::cast(klass)->array_klass(CHECK_NULL); } else { ak = InstanceKlass::cast(klass)->array_klass(CHECK_NULL); } return ak->allocate_instance(length, THREAD); } Or if you dare to use a virtual call instead of the if branch: objArrayOop oopFactory::new_objArray(Klass* klass, int length, TRAPS) { ArrayKlass* ak = klass->array_klass(CHECK_NULL); return ak->allocate_instance(length, THREAD); } If the virtual call is unwanted then we could add a new "faster" (unclear how much faster this actually is): ArrayKlass* Klass::array_klass_fast(TRAPS) { ArrayKlass* ak; if (klass->is_array_klass()) { ak = ArrayKlass::cast(klass)->array_klass(CHECK_NULL); } else { ak = InstanceKlass::cast(klass)->array_klass(CHECK_NULL); } assert(ak == array_klass(), "The two functions should return the same result"); return ak; } ... objArrayOop oopFactory::new_objArray(Klass* klass, int length, TRAPS) { ArrayKlass* ak = klass->array_klass_fast(CHECK_NULL); return ak->allocate_instance(length, THREAD); } (I've not compiled nor tested the above) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27372#discussion_r2362136758 From ayang at openjdk.org Fri Sep 19 08:18:37 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 19 Sep 2025 08:18:37 GMT Subject: RFR: 8368072: Remove redundant arguments of MarkingNMethodClosure [v2] In-Reply-To: References: Message-ID: > "Inline" statically known value to callee to simplify `MarkingNMethodClosure`. > > Test: tier1 Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision: - review - review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27382/files - new: https://git.openjdk.org/jdk/pull/27382/files/598a28d4..7e0efed5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27382&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27382&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27382.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27382/head:pull/27382 PR: https://git.openjdk.org/jdk/pull/27382 From jsikstro at openjdk.org Fri Sep 19 08:18:40 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Fri, 19 Sep 2025 08:18:40 GMT Subject: RFR: 8368072: Remove redundant arguments of MarkingNMethodClosure [v2] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 08:15:24 GMT, Albert Mingkun Yang wrote: >> "Inline" statically known value to callee to simplify `MarkingNMethodClosure`. >> >> Test: tier1 > > Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision: > > - review > - review src/hotspot/share/memory/iterator.hpp line 259: > 257: > 258: class MarkingNMethodClosure : public NMethodToOopClosure { > 259: bool _keepalive_nmethods; This isn't needed anymore, right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27382#discussion_r2362121475 From fandreuzzi at openjdk.org Fri Sep 19 08:18:42 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 19 Sep 2025 08:18:42 GMT Subject: RFR: 8368072: Remove redundant arguments of MarkingNMethodClosure [v2] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 08:15:24 GMT, Albert Mingkun Yang wrote: >> "Inline" statically known value to callee to simplify `MarkingNMethodClosure`. >> >> Test: tier1 > > Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision: > > - review > - review src/hotspot/share/memory/iterator.hpp line 261: > 259: public: > 260: MarkingNMethodClosure(OopClosure* cl) : > 261: NMethodToOopClosure(cl, false /* fix_relocations */) {} Would it be appropriate to use `!NMethodToOopClosure::FixRelocations` here instead? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27382#discussion_r2362127076 From ayang at openjdk.org Fri Sep 19 08:34:37 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 19 Sep 2025 08:34:37 GMT Subject: RFR: 8368072: Remove redundant arguments of MarkingNMethodClosure [v3] In-Reply-To: References: Message-ID: > "Inline" statically known value to callee to simplify `MarkingNMethodClosure`. > > Test: tier1 Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27382/files - new: https://git.openjdk.org/jdk/pull/27382/files/7e0efed5..637eb9a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27382&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27382&range=01-02 Stats: 5 lines in 1 file changed: 2 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27382.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27382/head:pull/27382 PR: https://git.openjdk.org/jdk/pull/27382 From stefank at openjdk.org Fri Sep 19 08:34:37 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 19 Sep 2025 08:34:37 GMT Subject: RFR: 8368072: Remove redundant arguments of MarkingNMethodClosure [v3] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 08:32:02 GMT, Albert Mingkun Yang wrote: >> "Inline" statically known value to callee to simplify `MarkingNMethodClosure`. >> >> Test: tier1 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27382#pullrequestreview-3243772929 From stefank at openjdk.org Fri Sep 19 08:34:40 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 19 Sep 2025 08:34:40 GMT Subject: RFR: 8368072: Remove redundant arguments of MarkingNMethodClosure [v2] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 08:18:37 GMT, Albert Mingkun Yang wrote: >> "Inline" statically known value to callee to simplify `MarkingNMethodClosure`. >> >> Test: tier1 > > Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision: > > - review > - review src/hotspot/share/memory/iterator.hpp line 261: > 259: public: > 260: MarkingNMethodClosure(OopClosure* cl) : > 261: NMethodToOopClosure(cl, !NMethodToOopClosure::FixRelocations) {} I think you should decouple MarkingNMethodClosure and NMethodToOopClosure. The later is only used to hold the same instance variables and one of them is unused after this change. class MarkingNMethodClosure : public NMethodClosure { OopClosure* _cl; public: MarkingNMethodClosure(OopClosure* cl) : _cl(cl) {} ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27382#discussion_r2362151898 From fandreuzzi at openjdk.org Fri Sep 19 08:40:35 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 19 Sep 2025 08:40:35 GMT Subject: RFR: 8368072: Remove redundant arguments of MarkingNMethodClosure [v3] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 08:34:37 GMT, Albert Mingkun Yang wrote: >> "Inline" statically known value to callee to simplify `MarkingNMethodClosure`. >> >> Test: tier1 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/27382#pullrequestreview-3243807190 From cnorrbin at openjdk.org Fri Sep 19 08:55:09 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Fri, 19 Sep 2025 08:55:09 GMT Subject: RFR: 8367536: Change RBTree to use C++17 features [v5] In-Reply-To: References: Message-ID: > Hi everyone, > > C++17 lets us tidy up som of the ugly templating done in the red-black tree. We can replace the `std::false_type`/`std::true_type` tricks used to discover comparator and verifier signatures with the new `std::is_invocable(_r_v)`, and most of the overload/SFINAE noise can disappear thanks to `if constexpr`. > > We can now write one-liners such as: > ```c++ > static constexpr bool HasKeyComparator = std::is_invocable_r_v; > > > and then select the right branch with > ```c++ > if constexpr (HasKeyComparator) { } > > inside a single function instead of having several `ENABLE_IF` overloads. > > This results in fewer lines, clearer intent, and more readable errors, while keeping behaviour identical. > > Testing: > - Oracle tiers 1-3 Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27260/files - new: https://git.openjdk.org/jdk/pull/27260/files/184b5fc5..2a5eee2d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27260&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27260&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27260.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27260/head:pull/27260 PR: https://git.openjdk.org/jdk/pull/27260 From aph at openjdk.org Fri Sep 19 09:45:32 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 19 Sep 2025 09:45:32 GMT Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1 volatile field loads [v2] In-Reply-To: <7rOmFYwzssNyo-r4sU_9563VootV4M61h-6MYsNU7Zc=.23d773f2-43a3-4ea0-8a1d-f1b740bdcdbb@github.com> References: <7rOmFYwzssNyo-r4sU_9563VootV4M61h-6MYsNU7Zc=.23d773f2-43a3-4ea0-8a1d-f1b740bdcdbb@github.com> Message-ID: On Thu, 18 Sep 2025 07:50:33 GMT, Andrew Haley wrote: >> Also have just finished running jcstress and it seems to pass fine. > > @spchee , are you still working on this? > Hi @theRealAph, Thank you for checking. @spchee is currently unavailable. I will be taking over this work. > > Following the [#26748 (comment)](https://github.com/openjdk/jdk/pull/26748#discussion_r2287427842) discussion, would it be possible to confirm whether there is a current use-case for `AlwaysAtomicAccesses`? There is, but the C1 implementation for `AlwaysAtomicAccesses` has a bug. (Or it has an unfortunate feature; your mileage may vary.) The current way that `AlwaysAtomicAccesses` works is to mark all accesses as effectively volatile, but this is unnecessary on AArch64 because all naturally-aligned accesses are single-copy atomic. Therefore, the logic here void BarrierSetC1::store_at_resolved(LIRAccess& access, LIR_Opr value) { DecoratorSet decorators = access.decorators(); bool is_volatile = (decorators & MO_SEQ_CST) != 0; bool is_atomic = is_volatile || AlwaysAtomicAccesses; could be fixed by something like ` bool is_atomic = is_volatile || (AlwaysAtomicAccesses & ! CPU_IS_SINGLE_COPY_ATOMIC); ` But that could be handled in another patch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26748#issuecomment-3311483034 From sgehwolf at openjdk.org Fri Sep 19 09:52:17 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 19 Sep 2025 09:52:17 GMT Subject: RFR: 8360651: Create OSContainer API for memory limit [v2] In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 17:54:10 GMT, Severin Gehwolf wrote: >> Please review this small addition to add a new `OSContainer::has_memory_limit()` API (Linux only - as with the entire OSContainer API) in preparation for [JDK-8350596](https://bugs.openjdk.org/browse/JDK-8350596) which proposes to increase the default `MaxRAMPercentage` when this new API returns true. The patch is pretty trivial. It's only the testing which amounts to the most lines in this patch. >> >> Testing: >> - [x] GHA >> - [x] Hotspot container tests on x86_64 Linux on cgroup v1 and cgroup v2 (including the new tests). >> >> Thoughts? > > Severin Gehwolf 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 four additional commits since the last revision: > > - Merge branch 'master' into jdk-8360651-mem-limit-api > - MemoryLimitTest whitespace fixes. > - TestContainerMemory whitespace fixes. > - 8360651: Create OSContainer API for memory limit Thanks for the reviews, but it looks like there is no need for this. See [JDK-8350596](https://bugs.openjdk.org/browse/JDK-8350596). Closing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26020#issuecomment-3311499681 From sgehwolf at openjdk.org Fri Sep 19 09:52:19 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 19 Sep 2025 09:52:19 GMT Subject: Withdrawn: 8360651: Create OSContainer API for memory limit In-Reply-To: References: Message-ID: <1O_WhH_lEELZv18LUQHxMOwVmKQ0s2TzR5286Wb2Up4=.de4b15a3-d768-4585-aeb1-ceb80ddfce55@github.com> On Fri, 27 Jun 2025 14:47:34 GMT, Severin Gehwolf wrote: > Please review this small addition to add a new `OSContainer::has_memory_limit()` API (Linux only - as with the entire OSContainer API) in preparation for [JDK-8350596](https://bugs.openjdk.org/browse/JDK-8350596) which proposes to increase the default `MaxRAMPercentage` when this new API returns true. The patch is pretty trivial. It's only the testing which amounts to the most lines in this patch. > > Testing: > - [x] GHA > - [x] Hotspot container tests on x86_64 Linux on cgroup v1 and cgroup v2 (including the new tests). > > Thoughts? This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/26020 From aboldtch at openjdk.org Fri Sep 19 09:56:43 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 19 Sep 2025 09:56:43 GMT Subject: RFR: 8367972: ZGC: Reduce ZBarrierSet includes Message-ID: [JDK-8365053](https://bugs.openjdk.org/browse/JDK-8365053) made a fact which is already well known to ZGC developers clear. We pull in large parts of the ZGC implementation through the access API, via `zbarrierset.inline.hpp`. ZGC developers are well aware as touching most `.hpp` or `inline.hpp` files in `gc/z` requires rebuilding most of hotspot in incremental builds. I propose we create a boundary between the barrier set and the implementation. The main reason being making incremental builds less painful. I experimented with this last year, at the time I saw no real difference in full build times, nor any performance regressions from not inlining the barrier implementation into the access API. Will reevaluate the performance implications. I ran the `bin/update_pch.sh` script, but with the default `MIN_MS` I saw the same list both before and after this change: ```c++ #include "gc/g1/g1BarrierSet.inline.hpp" #include "gc/shenandoah/shenandoahHeap.inline.hpp" #include "memory/iterator.inline.hpp" #include "oops/access.hpp" #include "oops/access.inline.hpp" #include "oops/oop.inline.hpp" #include "utilities/globalDefinitions.hpp" However when running with `MIN_MS` reduced by an order of magnitude `#include "gc/z/zBarrier.inline.hpp"` was included without this patch, and was excluded after with this patch. Also cross-compiled ppc64le, s390x and riscv64 (fast debug). Could not find any missing includes, have not built all configurations. For some reason windows slow debug failed to build because `test/hotspot/gtest/runtime/test_os_windows.cpp` was missing `os_windows.hpp`, did not investigate further, but included `runtime/os.inline.hpp` in the test as it includes all OS and OS CPU specific declarations and inline definitions. * Testing * Tier 1 + ZGC tier 1-5 on Oracle supported platforms ------------- Commit messages: - 8367972: ZGC: Reduce ZBarrierSet includes Changes: https://git.openjdk.org/jdk/pull/27386/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27386&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367972 Stats: 187 lines in 10 files changed: 114 ins; 50 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/27386.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27386/head:pull/27386 PR: https://git.openjdk.org/jdk/pull/27386 From ayang at openjdk.org Fri Sep 19 10:05:30 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 19 Sep 2025 10:05:30 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v8] In-Reply-To: References: Message-ID: <2zZ0C8QMjO3VjsicHXhLbNuy1d_Vg9HsmltsW5BU1kY=.95ac00a0-d202-4ae3-9ae3-7568bd9e6d1d@github.com> On Fri, 19 Sep 2025 05:17:23 GMT, Ivan Walulya wrote: >> Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. >> >> Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. >> >> Testing: Tier 1-7 > > Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: > > remove assert src/hotspot/share/gc/shared/collectedHeap.cpp line 626: > 624: // triggers a GC. > 625: MonitorLocker ml(VMExit_lock); > 626: ml.wait(2 * MILLIUNITS); I think one can use `ThreadBlockInVM` + sleep to achieve the blocking-current-thread purpose. Then, there is no need for a new lock, as there is no critical-region anyway. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2362381514 From stefank at openjdk.org Fri Sep 19 10:14:47 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 19 Sep 2025 10:14:47 GMT Subject: RFR: 8367972: ZGC: Reduce ZBarrierSet includes In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 09:49:03 GMT, Axel Boldt-Christmas wrote: > [JDK-8365053](https://bugs.openjdk.org/browse/JDK-8365053) made a fact which is already well known to ZGC developers clear. We pull in large parts of the ZGC implementation through the access API, via `zbarrierset.inline.hpp`. > > ZGC developers are well aware as touching most `.hpp` or `inline.hpp` files in `gc/z` requires rebuilding most of hotspot in incremental builds. > > I propose we create a boundary between the barrier set and the implementation. The main reason being making incremental builds less painful. > > I experimented with this last year, at the time I saw no real difference in full build times, nor any performance regressions from not inlining the barrier implementation into the access API. > > Will reevaluate the performance implications. > > I ran the `bin/update_pch.sh` script, but with the default `MIN_MS` I saw the same list both before and after this change: > ```c++ > #include "gc/g1/g1BarrierSet.inline.hpp" > #include "gc/shenandoah/shenandoahHeap.inline.hpp" > #include "memory/iterator.inline.hpp" > #include "oops/access.hpp" > #include "oops/access.inline.hpp" > #include "oops/oop.inline.hpp" > #include "utilities/globalDefinitions.hpp" > > However when running with `MIN_MS` reduced by an order of magnitude `#include "gc/z/zBarrier.inline.hpp"` was included without this patch, and was excluded after with this patch. > > Also cross-compiled ppc64le, s390x and riscv64 (fast debug). Could not find any missing includes, have not built all configurations. > > For some reason windows slow debug failed to build because `test/hotspot/gtest/runtime/test_os_windows.cpp` was missing `os_windows.hpp`, did not investigate further, but included `runtime/os.inline.hpp` in the test as it includes all OS and OS CPU specific declarations and inline definitions. > > * Testing > * Tier 1 + ZGC tier 1-5 on Oracle supported platforms Looks good if the performance evaluation looks good. ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27386#pullrequestreview-3244176898 From krk at openjdk.org Fri Sep 19 10:37:18 2025 From: krk at openjdk.org (Kerem Kat) Date: Fri, 19 Sep 2025 10:37:18 GMT Subject: RFR: debug.cpp: Do not print help message for methods ifdef'd out [v2] In-Reply-To: References: Message-ID: > The `help` command in `debug.cpp` was out of date, listing only a fraction of the available functions. This and other commands callable from gdb via `call help()`. > > I added all commands to the help message, except `pns2` as it is documented as not being useful when called from gdb. > > Also fixed is the message for the conditional `pns` command appearing in PRODUCT builds. Kerem Kat has updated the pull request incrementally with one additional commit since the last revision: address comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27341/files - new: https://git.openjdk.org/jdk/pull/27341/files/e1bdce21..6077d252 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27341&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27341&range=00-01 Stats: 27 lines in 1 file changed: 1 ins; 0 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/27341.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27341/head:pull/27341 PR: https://git.openjdk.org/jdk/pull/27341 From krk at openjdk.org Fri Sep 19 10:39:57 2025 From: krk at openjdk.org (Kerem Kat) Date: Fri, 19 Sep 2025 10:39:57 GMT Subject: RFR: debug.cpp: Do not print help message for methods ifdef'd out [v2] In-Reply-To: References: Message-ID: <8hz8WtLGihu0SZ59UftBZrWKURESeQ2xW4hi4uUapr8=.03f11edb-9a14-4fce-832a-544418161eec@github.com> On Fri, 19 Sep 2025 10:37:18 GMT, Kerem Kat wrote: >> The `help` command in `debug.cpp` was out of date, listing only a fraction of the available functions. This and other commands callable from gdb via `call help()`. >> >> I added all commands to the help message, except `pns2` as it is documented as not being useful when called from gdb. >> >> Also fixed is the message for the conditional `pns` command appearing in PRODUCT builds. > > Kerem Kat has updated the pull request incrementally with one additional commit since the last revision: > > address comments Thanks for the reviews, addressed all points. Also, removed help for MIPS as I could not find any evidence that it is a supported architecture. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27341#issuecomment-3311677521 From coleenp at openjdk.org Fri Sep 19 11:35:23 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 19 Sep 2025 11:35:23 GMT Subject: RFR: 8367989: Remove InstanceKlass::allocate_objArray In-Reply-To: <6VeFjixTLN_lcvaVt3RO_YjGMXUXuQ6DNe71Rf9XxCk=.17ee1a0d-07b9-41db-b7f6-2c79c04d5e69@github.com> References: <6VeFjixTLN_lcvaVt3RO_YjGMXUXuQ6DNe71Rf9XxCk=.17ee1a0d-07b9-41db-b7f6-2c79c04d5e69@github.com> Message-ID: On Fri, 19 Sep 2025 08:15:20 GMT, Stefan Karlsson wrote: >> This change removes InstanceKlass::allocate_objArray and has its caller call ObjArrayKlass::allocate_instance directly from oopFactory, like the other array allocations do. See CR for more information why we should have this change. I also removed element_klass_addr() and moved element_klass_offset() to be in a more logical place near element_klass() functions. This upstreams a tiny valhalla diff. >> Tested with tier1-4. > > src/hotspot/share/memory/oopFactory.cpp line 112: > >> 110: } else { >> 111: ArrayKlass* ak = InstanceKlass::cast(klass)->array_klass(CHECK_NULL); >> 112: return ObjArrayKlass::cast(ak)->allocate_instance(length, THREAD); > > Before this change the two if/else branches had a symmetry that is lost with the proposed change. It makes you look at the code and wonder what the reason is for this asymmetry. Could the symmetry be retained by changing this to: > > > objArrayOop oopFactory::new_objArray(Klass* klass, int length, TRAPS) { > ArrayKlass* ak; > > if (klass->is_array_klass()) { > ak = ArrayKlass::cast(klass)->array_klass(CHECK_NULL); > } else { > ak = InstanceKlass::cast(klass)->array_klass(CHECK_NULL); > } > > return ak->allocate_instance(length, THREAD); > } > > > Or if you dare to use a virtual call instead of the if branch: > > objArrayOop oopFactory::new_objArray(Klass* klass, int length, TRAPS) { > ArrayKlass* ak = klass->array_klass(CHECK_NULL); > return ak->allocate_instance(length, THREAD); > } > > > If the virtual call is unwanted then we could add a new "faster" (unclear how much faster this actually is): > > ArrayKlass* Klass::array_klass_fast(TRAPS) { > ArrayKlass* ak; > > if (klass->is_array_klass()) { > ak = ArrayKlass::cast(klass)->array_klass(CHECK_NULL); > } else { > ak = InstanceKlass::cast(klass)->array_klass(CHECK_NULL); > } > > assert(ak == array_klass(), "The two functions should return the same result"); > return ak; > } > ... > objArrayOop oopFactory::new_objArray(Klass* klass, int length, TRAPS) { > ArrayKlass* ak = klass->array_klass_fast(CHECK_NULL); > return ak->allocate_instance(length, THREAD); > } > > > (I've not compiled nor tested the above) It wasn't really symmetric except number of lines. One branch calls ArrayKlass::allocate_arrayArray, the other calls allocate_instance for ObjArray. Unless I refactor allocate_arrayArray into this, it still won't be symmetrical, and it's quite a bit different in the valhalla repo. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27372#discussion_r2362599079 From coleenp at openjdk.org Fri Sep 19 11:35:24 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 19 Sep 2025 11:35:24 GMT Subject: RFR: 8367989: Remove InstanceKlass::allocate_objArray In-Reply-To: References: <6VeFjixTLN_lcvaVt3RO_YjGMXUXuQ6DNe71Rf9XxCk=.17ee1a0d-07b9-41db-b7f6-2c79c04d5e69@github.com> Message-ID: On Fri, 19 Sep 2025 11:30:40 GMT, Coleen Phillimore wrote: >> src/hotspot/share/memory/oopFactory.cpp line 112: >> >>> 110: } else { >>> 111: ArrayKlass* ak = InstanceKlass::cast(klass)->array_klass(CHECK_NULL); >>> 112: return ObjArrayKlass::cast(ak)->allocate_instance(length, THREAD); >> >> Before this change the two if/else branches had a symmetry that is lost with the proposed change. It makes you look at the code and wonder what the reason is for this asymmetry. Could the symmetry be retained by changing this to: >> >> >> objArrayOop oopFactory::new_objArray(Klass* klass, int length, TRAPS) { >> ArrayKlass* ak; >> >> if (klass->is_array_klass()) { >> ak = ArrayKlass::cast(klass)->array_klass(CHECK_NULL); >> } else { >> ak = InstanceKlass::cast(klass)->array_klass(CHECK_NULL); >> } >> >> return ak->allocate_instance(length, THREAD); >> } >> >> >> Or if you dare to use a virtual call instead of the if branch: >> >> objArrayOop oopFactory::new_objArray(Klass* klass, int length, TRAPS) { >> ArrayKlass* ak = klass->array_klass(CHECK_NULL); >> return ak->allocate_instance(length, THREAD); >> } >> >> >> If the virtual call is unwanted then we could add a new "faster" (unclear how much faster this actually is): >> >> ArrayKlass* Klass::array_klass_fast(TRAPS) { >> ArrayKlass* ak; >> >> if (klass->is_array_klass()) { >> ak = ArrayKlass::cast(klass)->array_klass(CHECK_NULL); >> } else { >> ak = InstanceKlass::cast(klass)->array_klass(CHECK_NULL); >> } >> >> assert(ak == array_klass(), "The two functions should return the same result"); >> return ak; >> } >> ... >> objArrayOop oopFactory::new_objArray(Klass* klass, int length, TRAPS) { >> ArrayKlass* ak = klass->array_klass_fast(CHECK_NULL); >> return ak->allocate_instance(length, THREAD); >> } >> >> >> (I've not compiled nor tested the above) > > It wasn't really symmetric except number of lines. One branch calls ArrayKlass::allocate_arrayArray, the other calls allocate_instance for ObjArray. Unless I refactor allocate_arrayArray into this, it still won't be symmetrical, and it's quite a bit different in the valhalla repo. It might make sense to refactor allocate_arrayArray into this though and remove that too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27372#discussion_r2362603501 From eosterlund at openjdk.org Fri Sep 19 11:43:54 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 19 Sep 2025 11:43:54 GMT Subject: RFR: 8367972: ZGC: Reduce ZBarrierSet includes In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 09:49:03 GMT, Axel Boldt-Christmas wrote: > [JDK-8365053](https://bugs.openjdk.org/browse/JDK-8365053) made a fact which is already well known to ZGC developers clear. We pull in large parts of the ZGC implementation through the access API, via `zbarrierset.inline.hpp`. > > ZGC developers are well aware as touching most `.hpp` or `inline.hpp` files in `gc/z` requires rebuilding most of hotspot in incremental builds. > > I propose we create a boundary between the barrier set and the implementation. The main reason being making incremental builds less painful. > > I experimented with this last year, at the time I saw no real difference in full build times, nor any performance regressions from not inlining the barrier implementation into the access API. > > Will reevaluate the performance implications. > > I ran the `bin/update_pch.sh` script, but with the default `MIN_MS` I saw the same list both before and after this change: > ```c++ > #include "gc/g1/g1BarrierSet.inline.hpp" > #include "gc/shenandoah/shenandoahHeap.inline.hpp" > #include "memory/iterator.inline.hpp" > #include "oops/access.hpp" > #include "oops/access.inline.hpp" > #include "oops/oop.inline.hpp" > #include "utilities/globalDefinitions.hpp" > > However when running with `MIN_MS` reduced by an order of magnitude `#include "gc/z/zBarrier.inline.hpp"` was included without this patch, and was excluded after with this patch. > > Also cross-compiled ppc64le, s390x and riscv64 (fast debug). Could not find any missing includes, have not built all configurations. > > For some reason windows slow debug failed to build because `test/hotspot/gtest/runtime/test_os_windows.cpp` was missing `os_windows.hpp`, did not investigate further, but included `runtime/os.inline.hpp` in the test as it includes all OS and OS CPU specific declarations and inline definitions. > > * Testing > * Tier 1 + ZGC tier 1-5 on Oracle supported platforms Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27386#pullrequestreview-3244484350 From coleenp at openjdk.org Fri Sep 19 11:47:56 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 19 Sep 2025 11:47:56 GMT Subject: RFR: 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition() [v2] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 03:06:42 GMT, Ioi Lam wrote: >> Simplify the boilerplate code in jvm.cpp that calls `JvmtiThreadState::class_to_verify_considering_redefinition()`, and reduce the number of `InstanceKlass::cast()` calls. >> >> I also changed a few fields/arguments from `Klass*` to `InstanceKlass*` as these are used exclusively with `InstanceKlass*`. > > Ioi Lam 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 three additional commits since the last revision: > > - @coleenp and @dholmes-ora comments -- simplify implementation; fixed code formatting > - Merge branch 'master' into 8367719-refactor-jni-code-that-uses-class_to_verify_considering_redefinition > - 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition() Looks good. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27303#pullrequestreview-3244497323 From jbechberger at openjdk.org Fri Sep 19 11:48:57 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Fri, 19 Sep 2025 11:48:57 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing [v4] In-Reply-To: <3tx8u2KSzSzLQG8wa-YCiQGCwS--B1q56JZFiYbklhQ=.396d1328-3591-46de-9e82-5e3a065c8b8a@github.com> References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> <3tx8u2KSzSzLQG8wa-YCiQGCwS--B1q56JZFiYbklhQ=.396d1328-3591-46de-9e82-5e3a065c8b8a@github.com> Message-ID: On Thu, 18 Sep 2025 14:51:33 GMT, Johannes Bechberger wrote: >> This change hopefully fixes the test failures by making the test cases more resilient. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove synchronized Interesting. I'm further simplifying the test case, removing all the time-box code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27293#issuecomment-3311888120 From jsjolen at openjdk.org Fri Sep 19 11:50:59 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 19 Sep 2025 11:50:59 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v5] In-Reply-To: <9GaOIC1GMr4TNQ-P-K54NJF-vVqaAFAOFVNZNNOpWM4=.a2c29f92-b499-4780-8187-82693d512448@github.com> References: <9GaOIC1GMr4TNQ-P-K54NJF-vVqaAFAOFVNZNNOpWM4=.a2c29f92-b499-4780-8187-82693d512448@github.com> Message-ID: <4sDHlKErEtUHt0Y6uxCcqxnQX5Ztl8gNYsd8t_9pnmc=.7a7bf590-9e18-424c-9992-2d65d264c075@github.com> On Fri, 19 Sep 2025 02:45:16 GMT, David Holmes wrote: >One query: have you done any performance measurements for this change? I'm a little concerned that the insertion iterator and the internal array management is now more heavyweight than the old array management. I haven'e done any performance testing. I was considering doing so, but the majority of the work that has potentially been slowed down is when redefining classes via JVMTI, as this is when we got to do what essentially boiled down to a `memcpy`. My understanding of JVMTI is that it's less performance sensitive than the usual JVM, as it's only used or tooling on a 'human' level (debuggers, etc). Is that understanding correct? Regardless, I'll have a look at doing some coarse-grained profiling via Aurora, and also have a look at the generated assembly. The goal of putting some of the functions in the inline file was to give enough context to the compiler so that it can do a good job of optimizing the code, we'll see if that was actually the case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27198#issuecomment-3311891616 From fandreuzzi at openjdk.org Fri Sep 19 11:50:57 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Fri, 19 Sep 2025 11:50:57 GMT Subject: RFR: 8367972: ZGC: Reduce ZBarrierSet includes In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 09:49:03 GMT, Axel Boldt-Christmas wrote: > [JDK-8365053](https://bugs.openjdk.org/browse/JDK-8365053) made a fact which is already well known to ZGC developers clear. We pull in large parts of the ZGC implementation through the access API, via `zbarrierset.inline.hpp`. > > ZGC developers are well aware as touching most `.hpp` or `inline.hpp` files in `gc/z` requires rebuilding most of hotspot in incremental builds. > > I propose we create a boundary between the barrier set and the implementation. The main reason being making incremental builds less painful. > > I experimented with this last year, at the time I saw no real difference in full build times, nor any performance regressions from not inlining the barrier implementation into the access API. > > Will reevaluate the performance implications. > > I ran the `bin/update_pch.sh` script, but with the default `MIN_MS` I saw the same list both before and after this change: > ```c++ > #include "gc/g1/g1BarrierSet.inline.hpp" > #include "gc/shenandoah/shenandoahHeap.inline.hpp" > #include "memory/iterator.inline.hpp" > #include "oops/access.hpp" > #include "oops/access.inline.hpp" > #include "oops/oop.inline.hpp" > #include "utilities/globalDefinitions.hpp" > > However when running with `MIN_MS` reduced by an order of magnitude `#include "gc/z/zBarrier.inline.hpp"` was included without this patch, and was excluded after with this patch. > > Also cross-compiled ppc64le, s390x and riscv64 (fast debug). Could not find any missing includes, have not built all configurations. > > For some reason windows slow debug failed to build because `test/hotspot/gtest/runtime/test_os_windows.cpp` was missing `os_windows.hpp`, did not investigate further, but included `runtime/os.inline.hpp` in the test as it includes all OS and OS CPU specific declarations and inline definitions. > > * Testing > * Tier 1 + ZGC tier 1-5 on Oracle supported platforms Hi @xmas92, some more data about this change. ### Before ./ClangBuildAnalyzer/build/ClangBuildAnalyzer --analyze cba_out_20250919-1055 | grep /z/ -A 3 126184 ms: /jdk/src/hotspot/share/gc/z/zGeneration.inline.hpp (included 646 times, avg 195 ms), included via: 81x: oop.inline.hpp iterator.inline.hpp access.inline.hpp barrierSetConfig.inline.hpp zBarrierSet.inline.hpp zBarrier.inline.hpp ... 121644 ms: /jdk/src/hotspot/share/gc/z/zBarrier.inline.hpp (included 646 times, avg 188 ms), included via: 81x: oop.inline.hpp iterator.inline.hpp access.inline.hpp barrierSetConfig.inline.hpp zBarrierSet.inline.hpp ... 109125 ms: /jdk/src/hotspot/share/gc/z/zHeap.inline.hpp (included 646 times, avg 168 ms), included via: 81x: oop.inline.hpp iterator.inline.hpp access.inline.hpp barrierSetConfig.inline.hpp zBarrierSet.inline.hpp zBarrier.inline.hpp zGeneration.inline.hpp ... -- 61224 ms: /jdk/src/hotspot/share/gc/z/zForwardingTable.inline.hpp (included 646 times, avg 94 ms), included via: 81x: oop.inline.hpp iterator.inline.hpp access.inline.hpp barrierSetConfig.inline.hpp zBarrierSet.inline.hpp zBarrier.inline.hpp zGeneration.inline.hpp zHeap.inline.hpp ... -- 58889 ms: /jdk/src/hotspot/share/gc/z/zForwarding.inline.hpp (included 646 times, avg 91 ms), included via: 81x: oop.inline.hpp iterator.inline.hpp access.inline.hpp barrierSetConfig.inline.hpp zBarrierSet.inline.hpp zBarrier.inline.hpp zGeneration.inline.hpp zHeap.inline.hpp zForwardingTable.inline.hpp ... ### After ./ClangBuildAnalyzer/build/ClangBuildAnalyzer --analyze after | grep /z/ -A 3 31714 ms: /jdk/src/hotspot/share/gc/z/zHeap.inline.hpp (included 40 times, avg 792 ms), included via: 13x: zBarrier.inline.hpp zGeneration.inline.hpp ... -- 31012 ms: /jdk/src/hotspot/share/gc/z/zForwarding.inline.hpp (included 40 times, avg 775 ms), included via: 13x: zBarrier.inline.hpp zGeneration.inline.hpp zHeap.inline.hpp zForwardingTable.inline.hpp ... -- 27089 ms: /jdk/src/hotspot/share/gc/z/zForwardingTable.inline.hpp (included 40 times, avg 677 ms), included via: 13x: zBarrier.inline.hpp zGeneration.inline.hpp zHeap.inline.hpp ... 27058 ms: /jdk/src/hotspot/share/gc/z/zGeneration.inline.hpp (included 40 times, avg 676 ms), included via: 13x: zBarrier.inline.hpp ... `` ------------- PR Comment: https://git.openjdk.org/jdk/pull/27386#issuecomment-3311893573 From coleenp at openjdk.org Fri Sep 19 11:57:13 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 19 Sep 2025 11:57:13 GMT Subject: RFR: 8365823: Revert storing abstract and interface Klasses to non-class metaspace [v5] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 18:04:05 GMT, Coleen Phillimore wrote: >> This change removes the optimization to not store abstract and interface Klass metadata to non-class metaspace. Now all Klass metadata is in the Klass metaspace. This is simpler and less bug prone, and didn't help with the limitation of classes that can be stored in class metaspace materially. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Some limited additional cleanup to HotSpotMetaspaceConstantImpl.java on jvmci. Reran jvmci tests. Thanks Vladimir for re-reviewing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27295#issuecomment-3311902694 From coleenp at openjdk.org Fri Sep 19 11:57:15 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 19 Sep 2025 11:57:15 GMT Subject: Integrated: 8365823: Revert storing abstract and interface Klasses to non-class metaspace In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 13:28:45 GMT, Coleen Phillimore wrote: > This change removes the optimization to not store abstract and interface Klass metadata to non-class metaspace. Now all Klass metadata is in the Klass metaspace. This is simpler and less bug prone, and didn't help with the limitation of classes that can be stored in class metaspace materially. > Tested with tier1-4. This pull request has now been integrated. Changeset: fa00b249 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/fa00b24954d63abed0093b696e5971c1918eec4d Stats: 104 lines in 19 files changed: 7 ins; 66 del; 31 mod 8365823: Revert storing abstract and interface Klasses to non-class metaspace Reviewed-by: kvn, shade, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/27295 From egahlin at openjdk.org Fri Sep 19 11:59:46 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 19 Sep 2025 11:59:46 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing [v4] In-Reply-To: <3tx8u2KSzSzLQG8wa-YCiQGCwS--B1q56JZFiYbklhQ=.396d1328-3591-46de-9e82-5e3a065c8b8a@github.com> References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> <3tx8u2KSzSzLQG8wa-YCiQGCwS--B1q56JZFiYbklhQ=.396d1328-3591-46de-9e82-5e3a065c8b8a@github.com> Message-ID: On Thu, 18 Sep 2025 14:51:33 GMT, Johannes Bechberger wrote: >> This change hopefully fixes the test failures by making the test cases more resilient. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove synchronized Could you add "@requires vm.flagless" to reduce risk of false positives. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27293#issuecomment-3311917878 From coleenp at openjdk.org Fri Sep 19 12:22:54 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 19 Sep 2025 12:22:54 GMT Subject: RFR: 8367989: Remove InstanceKlass::allocate_objArray [v2] In-Reply-To: References: Message-ID: > This change removes InstanceKlass::allocate_objArray and has its caller call ObjArrayKlass::allocate_instance directly from oopFactory, like the other array allocations do. See CR for more information why we should have this change. I also removed element_klass_addr() and moved element_klass_offset() to be in a more logical place near element_klass() functions. This upstreams a tiny valhalla diff. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Stefan's suggestion #1. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27372/files - new: https://git.openjdk.org/jdk/pull/27372/files/e1680b1c..f4f1d289 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27372&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27372&range=00-01 Stats: 17 lines in 3 files changed: 2 ins; 12 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27372.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27372/head:pull/27372 PR: https://git.openjdk.org/jdk/pull/27372 From jbechberger at openjdk.org Fri Sep 19 12:34:33 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Fri, 19 Sep 2025 12:34:33 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing [v5] In-Reply-To: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> Message-ID: > This change hopefully fixes the test failures by making the test cases more resilient. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Add @requires vm.flagless ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27293/files - new: https://git.openjdk.org/jdk/pull/27293/files/c7c72770..b68e886a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27293&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27293&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27293.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27293/head:pull/27293 PR: https://git.openjdk.org/jdk/pull/27293 From apangin at openjdk.org Fri Sep 19 12:50:36 2025 From: apangin at openjdk.org (Andrei Pangin) Date: Fri, 19 Sep 2025 12:50:36 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing [v4] In-Reply-To: References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> <3tx8u2KSzSzLQG8wa-YCiQGCwS--B1q56JZFiYbklhQ=.396d1328-3591-46de-9e82-5e3a065c8b8a@github.com> Message-ID: <1JgJowqBni21c69KNQXqYX7fLPjZqV5xtY7Uub_5IAw=.267ac8d7-cc53-4cbe-ae69-19288263d6e2@github.com> On Fri, 19 Sep 2025 11:46:39 GMT, Johannes Bechberger wrote: >> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove synchronized > > Interesting. I'm further simplifying the test case, removing all the time-box code. @parttimenerd Oh, my previous comment about `synchronized` was incorrect: you still have concurrency between the main thread and `RecordingStream` async processor - sorry for confusion. I also think you need to call `rs.stop()` (which internally calls `awaitTermination`) before closing the stream. This should fix the race in the David's case. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27293#issuecomment-3312072149 From jbechberger at openjdk.org Fri Sep 19 13:02:38 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Fri, 19 Sep 2025 13:02:38 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing [v5] In-Reply-To: References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> Message-ID: <-lQxnoPEO28N8PfnpMWS0ciDTwMxQfB7pSnTI87CTGQ=.f7436113-f741-4d71-aa77-aac1460c61e3@github.com> On Fri, 19 Sep 2025 12:34:33 GMT, Johannes Bechberger wrote: >> This change hopefully fixes the test failures by making the test cases more resilient. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Add @requires vm.flagless Ah, that was probably the reason why I added it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27293#issuecomment-3312108180 From coleenp at openjdk.org Fri Sep 19 13:18:09 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 19 Sep 2025 13:18:09 GMT Subject: RFR: 8367989: Remove InstanceKlass::allocate_objArray [v3] In-Reply-To: References: Message-ID: > This change removes InstanceKlass::allocate_objArray and has its caller call ObjArrayKlass::allocate_instance directly from oopFactory, like the other array allocations do. See CR for more information why we should have this change. I also removed element_klass_addr() and moved element_klass_offset() to be in a more logical place near element_klass() functions. This upstreams a tiny valhalla diff. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Use virtual function rather than if statement, still need one cast though. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27372/files - new: https://git.openjdk.org/jdk/pull/27372/files/f4f1d289..cfa036b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27372&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27372&range=01-02 Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27372.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27372/head:pull/27372 PR: https://git.openjdk.org/jdk/pull/27372 From jbechberger at openjdk.org Fri Sep 19 13:25:37 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Fri, 19 Sep 2025 13:25:37 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing [v6] In-Reply-To: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> Message-ID: > This change hopefully fixes the test failures by making the test cases more resilient. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Add synchronized ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27293/files - new: https://git.openjdk.org/jdk/pull/27293/files/b68e886a..d927a0dc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27293&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27293&range=04-05 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27293.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27293/head:pull/27293 PR: https://git.openjdk.org/jdk/pull/27293 From krk at openjdk.org Fri Sep 19 13:25:53 2025 From: krk at openjdk.org (Kerem Kat) Date: Fri, 19 Sep 2025 13:25:53 GMT Subject: RFR: 8334866: Improve Speed of ElfDecoder source search [v2] In-Reply-To: References: Message-ID: <65x4enG48_tBFuzqS4rZiIlKf5fNsDzClwobZTZNHEA=.e30ac83d-5c3a-4f09-8c81-9778424333e7@github.com> > Right now, looking up source file and line number info is slow because we do a full linear scan of the `.debug_aranges` section for every single call. This can be a major bottleneck on large binaries, especially during frequent native stack walking, e.g. while writing an hs_err. > > This change fixes that by caching the address ranges on the first lookup, and keeping it in memory for the lifetime of the `DwarfFile` object. > > All subsequent lookups on that object now use a binary search instead of the slow linear scan. If caching fails for any reason, it just falls back to the old method. Kerem Kat has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into elfdecoder-JDK-8334866 - 8334866: Cache debug_aranges for faster address lookups ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27337/files - new: https://git.openjdk.org/jdk/pull/27337/files/aabab080..3f8b7a4e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27337&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27337&range=00-01 Stats: 9119 lines in 261 files changed: 5792 ins; 2732 del; 595 mod Patch: https://git.openjdk.org/jdk/pull/27337.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27337/head:pull/27337 PR: https://git.openjdk.org/jdk/pull/27337 From stefank at openjdk.org Fri Sep 19 13:28:35 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 19 Sep 2025 13:28:35 GMT Subject: RFR: 8367989: Remove InstanceKlass::allocate_objArray [v3] In-Reply-To: References: <6VeFjixTLN_lcvaVt3RO_YjGMXUXuQ6DNe71Rf9XxCk=.17ee1a0d-07b9-41db-b7f6-2c79c04d5e69@github.com> Message-ID: On Fri, 19 Sep 2025 11:33:00 GMT, Coleen Phillimore wrote: >> It wasn't really symmetric except number of lines. One branch calls ArrayKlass::allocate_arrayArray, the other calls allocate_instance for ObjArray. Unless I refactor allocate_arrayArray into this, it still won't be symmetrical, and it's quite a bit different in the valhalla repo. > > It might make sense to refactor allocate_arrayArray into this though and remove that too. > Yes, I like suggestion #1. There are too many array allocation functions. > It wasn't really symmetric except number of lines. Given that you refuted my statement about symmetry I want to try to explain what symmetry I saw but you didn't: The old code called allocate_xArray function in both branches. That was the symmetry. It was quite clear that the two functions accomplished similar goals, in similar ways. Yes, the functions called are named differently, but I didn't talk about absolute symmetry in characters of number of lines. In the first proposed patch both branches call its corresponding array_klass function, but only one of the legs make it explicit, and the other has that deferred to the call to allocate_xArray function. I find that this kind of asymmetry often hurts readability and makes code harder to maintain. Hence my proposal. My 2c. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27372#discussion_r2362889421 From coleenp at openjdk.org Fri Sep 19 14:30:02 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 19 Sep 2025 14:30:02 GMT Subject: RFR: 8367989: Remove InstanceKlass::allocate_objArray [v3] In-Reply-To: References: Message-ID: <5jhtaHUDz2TIi-ztkq8WtI1GOICe0632ualiU-RavG4=.e72ccf2c-36e7-41ac-be14-c496f36d9a7a@github.com> On Fri, 19 Sep 2025 13:18:09 GMT, Coleen Phillimore wrote: >> This change removes InstanceKlass::allocate_objArray and has its caller call ObjArrayKlass::allocate_instance directly from oopFactory, like the other array allocations do. See CR for more information why we should have this change. I also removed element_klass_addr() and moved element_klass_offset() to be in a more logical place near element_klass() functions. This upstreams a tiny valhalla diff. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Use virtual function rather than if statement, still need one cast though. src/hotspot/share/memory/oopFactory.cpp line 113: > 111: } else { > 112: return InstanceKlass::cast(klass)->allocate_objArray(1, length, THREAD); > 113: } I suppose this has symmetry in the mainline, except both of these functions do the same thing as ObjArrayKlass.allocate_instance do. The goal is to hide allocate_instance and only make this class a friend, and not InstanceKlass. This isn't the case in the current repository but it is in the valhalla repo and I want them to be the same at this level. So this isolates the CollectedHeap::array_allocate call to less places now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27372#discussion_r2363081628 From asmehra at openjdk.org Fri Sep 19 14:57:58 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 19 Sep 2025 14:57:58 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry [v2] In-Reply-To: References: Message-ID: > This PR removes the need to store entry point addresses in AdapterHandlerEntry by storing a direct pointer to AdapterBlob instead. Entry point addresses can be computed on the fly from the entry point offsets stored in AdapterBlob. Ashutosh Mehra 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 five additional commits since the last revision: - Merge branch 'master' into store-blob-pointer-adapterhandlerentry-v2 - Remove unused method and change numeric constants to enums Signed-off-by: Ashutosh Mehra - Address review comments Signed-off-by: Ashutosh Mehra - Do not call generate_i2c2i_adapters() on zero Signed-off-by: Ashutosh Mehra - Store pointer to AdapterBlob in AdapterHandlerEntry Signed-off-by: Ashutosh Mehra ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27101/files - new: https://git.openjdk.org/jdk/pull/27101/files/cad0d0c3..fff99163 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27101&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27101&range=00-01 Stats: 55244 lines in 1448 files changed: 29703 ins; 15980 del; 9561 mod Patch: https://git.openjdk.org/jdk/pull/27101.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27101/head:pull/27101 PR: https://git.openjdk.org/jdk/pull/27101 From asmehra at openjdk.org Fri Sep 19 14:58:02 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 19 Sep 2025 14:58:02 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry [v2] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 14:50:18 GMT, Ashutosh Mehra wrote: >> src/hotspot/share/runtime/sharedRuntime.cpp line 2825: >> >>> 2823: int comp_args_on_stack = SharedRuntime::java_calling_convention(sig_bt, regs, total_args_passed); >>> 2824: address entry_address[AdapterBlob::ENTRY_COUNT]; >>> 2825: assert(AdapterBlob::ENTRY_COUNT == 4, "sanity"); >> >> Why you need this assert? Do you use `4` instead of `ENTRY_COUNT` somewhere? > > This was just copied from the existing code. I think we don't need it. We should always be using enums. AdapterBlob constructor was using numeric values to access values in the entry_offset. I update it to use enums. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27101#discussion_r2363184167 From asmehra at openjdk.org Fri Sep 19 14:58:01 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 19 Sep 2025 14:58:01 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry [v2] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 23:47:21 GMT, Vladimir Kozlov wrote: >> Ashutosh Mehra 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 five additional commits since the last revision: >> >> - Merge branch 'master' into store-blob-pointer-adapterhandlerentry-v2 >> - Remove unused method and change numeric constants to enums >> >> Signed-off-by: Ashutosh Mehra >> - Address review comments >> >> Signed-off-by: Ashutosh Mehra >> - Do not call generate_i2c2i_adapters() on zero >> >> Signed-off-by: Ashutosh Mehra >> - Store pointer to AdapterBlob in AdapterHandlerEntry >> >> Signed-off-by: Ashutosh Mehra > > Good. Few comments only @vnkozlov addressed your comments and merged master as well. > src/hotspot/share/runtime/sharedRuntime.cpp line 2825: > >> 2823: int comp_args_on_stack = SharedRuntime::java_calling_convention(sig_bt, regs, total_args_passed); >> 2824: address entry_address[AdapterBlob::ENTRY_COUNT]; >> 2825: assert(AdapterBlob::ENTRY_COUNT == 4, "sanity"); > > Why you need this assert? Do you use `4` instead of `ENTRY_COUNT` somewhere? This was just copied from the existing code. I think we don't need it. We should always be using enums. > src/hotspot/share/runtime/sharedRuntime.cpp line 3034: > >> 3032: #endif // INCLUDE_CDS >> 3033: >> 3034: address AdapterHandlerEntry::base_address() { > > This method is used in `print_adapter_handler_info()` only after removal of `relocate()`. > Consider using `adapter_blob->content_begin()` in `print_adapter_handler_info()` and remove this `base_address()` Done ------------- PR Comment: https://git.openjdk.org/jdk/pull/27101#issuecomment-3312523843 PR Review Comment: https://git.openjdk.org/jdk/pull/27101#discussion_r2363174214 PR Review Comment: https://git.openjdk.org/jdk/pull/27101#discussion_r2363176991 From missa at openjdk.org Fri Sep 19 15:04:52 2025 From: missa at openjdk.org (Mohamed Issa) Date: Fri, 19 Sep 2025 15:04:52 GMT Subject: RFR: 8367611: Enable vblendvp[sd] on Future ECore [v2] In-Reply-To: References: <_Jk5fv1iO9ZPZyOtUAXeUez481RibKJR4FsUT_BnKm8=.2f68f9ee-9ce2-4dbb-be8b-1b9f910ba0e0@github.com> Message-ID: <0Q1S1XrqQK7lK0K-9N89tDyZx0B6dJwTSBE94kXpcfI=.69286971-f34f-4992-956d-6f32872cbfbb@github.com> On Fri, 19 Sep 2025 06:51:50 GMT, Manuel H?ssig wrote: > Thank you for this improvement, @missa-prime! The change looks good to me, but I have a question. > > > The JTREG test shown below was used to verify correctness against the [OpenJDK v26-b15](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B15) baseline build. > > > > * jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java > > Can you elaborate, what this verification entails? Why this test? @mhaessig I used this test because it frequently calls vblendvps() and vblendvpd() in the macro assembler. On Darkmont and non-Darkmont cores, I checked the right code paths were followed with asserts. Also, I wrote some sample code and checked the instructions generated at runtime. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27354#issuecomment-3312551922 From lmesnik at openjdk.org Fri Sep 19 15:23:34 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 19 Sep 2025 15:23:34 GMT Subject: RFR: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked [v11] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 05:12:14 GMT, Leonid Mesnik wrote: >> The >> `SuspendResumeManager::suspend(bool register_vthread_SR)` >> has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. >> >> Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. >> >> The fix added some "asymmetry" in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > asseriton moved out @dholmes-ora, @pchilano, @sspitsyn Thank you for review and feedback. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27317#issuecomment-3312615550 From lmesnik at openjdk.org Fri Sep 19 15:23:36 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 19 Sep 2025 15:23:36 GMT Subject: Integrated: 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked In-Reply-To: References: Message-ID: <3fxcQhiRsRMlpH0m5dtfkz7n8HhpRupZjwMoXGijj1g=.c25a8bbc-fa87-4581-abe9-e3203d9460b6@github.com> On Tue, 16 Sep 2025 15:55:12 GMT, Leonid Mesnik wrote: > The > `SuspendResumeManager::suspend(bool register_vthread_SR)` > has an issue while suspend current virtual thread. The suspend tries to access vthread oop field to read vthread id after thread is blocked. > > Seems, that this case is not used by our debugger and was not covered by tests. I found it using jtreg test thread virtual factory plugin. I updated existing test to reproduce this problem. The easiest way is to suspend current virtual thread using plain SuspendThread. > > The fix added some "asymmetry" in suspend/resume mechanism which is required because self-suspend doesn't have resume counterpart. This pull request has now been integrated. Changeset: 16458b60 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/16458b60c9ccdfac60140c8186f31d5d8a57f2f9 Stats: 43 lines in 5 files changed: 35 ins; 1 del; 7 mod 8367725: Incorrect reading of oop in SuspendResumeManager::suspend while thread is blocked Reviewed-by: pchilanomate, dholmes, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/27317 From coleenp at openjdk.org Fri Sep 19 15:31:47 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 19 Sep 2025 15:31:47 GMT Subject: RFR: 8367989: Remove InstanceKlass::allocate_objArray and ArrayKlass::allocate_arrayArray [v3] In-Reply-To: References: <6VeFjixTLN_lcvaVt3RO_YjGMXUXuQ6DNe71Rf9XxCk=.17ee1a0d-07b9-41db-b7f6-2c79c04d5e69@github.com> Message-ID: <7uiIpgCwWLsN-h4LCz0QOc4kMYTisdCOjgjPoSjikeg=.a5a360e6-6e58-4abf-ba8e-5476fdc48bcc@github.com> On Fri, 19 Sep 2025 13:26:08 GMT, Stefan Karlsson wrote: >> It might make sense to refactor allocate_arrayArray into this though and remove that too. >> Yes, I like suggestion #1. There are too many array allocation functions. > >> It wasn't really symmetric except number of lines. > > Given that you refuted my statement about symmetry I want to try to explain what symmetry I saw but you didn't: > > The old code called allocate_xArray function in both branches. That was the symmetry. It was quite clear that the two functions accomplished similar goals, in similar ways. Yes, the functions called are named differently, but I didn't talk about absolute symmetry in characters of number of lines. > > In the first proposed patch both branches call its corresponding array_klass function, but only one of the legs make it explicit, and the other has that deferred to the call to allocate_xArray function. I find that this kind of asymmetry often hurts readability and makes code harder to maintain. Hence my proposal. My 2c. Your suggested changes are really good. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27372#discussion_r2363299629 From eastigeevich at openjdk.org Fri Sep 19 15:59:14 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Fri, 19 Sep 2025 15:59:14 GMT Subject: RFR: 8365153: AArch64: Set JVM flags for Neoverse N3 and V3 cores In-Reply-To: References: Message-ID: On Fri, 8 Aug 2025 14:50:13 GMT, Ruben wrote: > For Neoverse N1, N2, V1, and V2, the following JVM flags are set: > - UseSIMDForMemoryOps=true > - OnSpinWaitInst=isb > - OnSpinWaitInstCount=1 > - AlwaysMergeDMB=false > > Additionally, for Neoverse V1 and V2 only, these flags are set: > - UseCryptoPmullForCRC32=true > - CodeEntryAlignment=32 > > Set the same flags for Neoverse N3 and V3, respectively. I checked V2 and V3 optimization guides: > UseSIMDForMemoryOps=true OnSpinWaitInst=isb OnSpinWaitInstCount=1 AlwaysMergeDMB=false I don't see any significant changes in latencies and throughput of instructions used when these options are set. > UseCryptoPmullForCRC32=true The latency and throughput are the same. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26701#issuecomment-3312740477 From eastigeevich at openjdk.org Fri Sep 19 16:14:48 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Fri, 19 Sep 2025 16:14:48 GMT Subject: RFR: 8365153: AArch64: Set JVM flags for Neoverse N3 and V3 cores In-Reply-To: References: Message-ID: On Fri, 8 Aug 2025 14:50:13 GMT, Ruben wrote: > CodeEntryAlignment=32 This should be Ok for V3 according to the following from the Optimization Guide: > Aligning subroutine entry points and branch targets to 32-byte boundaries will ensure that the subsequent fetch can maximize bandwidth following the taken branch by bringing in all useful instructions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26701#issuecomment-3312804060 From kvn at openjdk.org Fri Sep 19 16:26:02 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 19 Sep 2025 16:26:02 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry [v2] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 14:57:58 GMT, Ashutosh Mehra wrote: >> This PR removes the need to store entry point addresses in AdapterHandlerEntry by storing a direct pointer to AdapterBlob instead. Entry point addresses can be computed on the fly from the entry point offsets stored in AdapterBlob. > > Ashutosh Mehra 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 five additional commits since the last revision: > > - Merge branch 'master' into store-blob-pointer-adapterhandlerentry-v2 > - Remove unused method and change numeric constants to enums > > Signed-off-by: Ashutosh Mehra > - Address review comments > > Signed-off-by: Ashutosh Mehra > - Do not call generate_i2c2i_adapters() on zero > > Signed-off-by: Ashutosh Mehra > - Store pointer to AdapterBlob in AdapterHandlerEntry > > Signed-off-by: Ashutosh Mehra Good. I will submit testing. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27101#pullrequestreview-3245746094 From sparasa at openjdk.org Fri Sep 19 16:27:06 2025 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Fri, 19 Sep 2025 16:27:06 GMT Subject: RFR: 8367780: Enable UseAPX on Intel CPUs only when both APX_F and APX_NCI_NDD_NF cpuid features are present [v4] In-Reply-To: References: <-cYOL5wwp8oSisK5utj0B7mHi0D_Ne0i_N_RI-bsbLk=.87c1bc5f-a6a3-4d4e-9530-fc91e676656f@github.com> Message-ID: On Thu, 18 Sep 2025 21:55:13 GMT, Volodymyr Paprotski wrote: > Change looks good to me > Thanks Vlad for going through the changes and reviewing the PR! > src/hotspot/cpu/x86/vm_version_x86.cpp line 2928: > >> 2926: if (sefsl1_cpuid7_edx.bits.apx_f != 0 && >> 2927: xem_xcr0_eax.bits.apx_f != 0 && >> 2928: std_cpuid29_ebx.bits.apx_nci_ndd_nf != 0) { > > was confused why the previous implementation was 'wrong'.. Please clarify that this was triggered "because" of the update to the spec (in the PR description). Please see the updated PR description which clarifies that this PR was triggered because of the update to the Intel APX spec. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27320#issuecomment-3312848532 PR Review Comment: https://git.openjdk.org/jdk/pull/27320#discussion_r2363522977 From coleenp at openjdk.org Fri Sep 19 16:32:37 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 19 Sep 2025 16:32:37 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v5] In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 07:41:31 GMT, Johan Sj?len wrote: >> Hi, >> >> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array` to store the offsets in and an `Array` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`. >> >> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately. >> >> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc. >> >> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement. >> >> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Fix rename I really like this except let's make a new file for this type. You might want @sspitsyn to review the jvmtiRedefineClasses changes since he did this work for the existing operands arrays. ------------- PR Review: https://git.openjdk.org/jdk/pull/27198#pullrequestreview-3245777812 PR Comment: https://git.openjdk.org/jdk/pull/27198#issuecomment-3312867807 From eastigeevich at openjdk.org Fri Sep 19 16:37:43 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Fri, 19 Sep 2025 16:37:43 GMT Subject: RFR: 8365153: AArch64: Set JVM flags for Neoverse N3 and V3 cores In-Reply-To: References: Message-ID: On Fri, 8 Aug 2025 14:50:13 GMT, Ruben wrote: > For Neoverse N1, N2, V1, and V2, the following JVM flags are set: > - UseSIMDForMemoryOps=true > - OnSpinWaitInst=isb > - OnSpinWaitInstCount=1 > - AlwaysMergeDMB=false > > Additionally, for Neoverse V1 and V2 only, these flags are set: > - UseCryptoPmullForCRC32=true > - CodeEntryAlignment=32 > > Set the same flags for Neoverse N3 and V3, respectively. Neoverse-N3: > UseSIMDForMemoryOps=true When it's true we use `ldpq/stpq`. N3 `ldpq` latency/throughput is the same as N2. N3 `stpq` latency/throughput is 2/2. N2 `stpq` latency/throughput is 2/1. So we might expect better performance on N3. > OnSpinWaitInst=isb OnSpinWaitInstCount=1 AlwaysMergeDMB=false IMO we should not expect big changes here as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26701#issuecomment-3312885831 From eastigeevich at openjdk.org Fri Sep 19 16:41:43 2025 From: eastigeevich at openjdk.org (Evgeny Astigeevich) Date: Fri, 19 Sep 2025 16:41:43 GMT Subject: RFR: 8365153: AArch64: Set JVM flags for Neoverse N3 and V3 cores In-Reply-To: References: Message-ID: On Fri, 8 Aug 2025 14:50:13 GMT, Ruben wrote: > For Neoverse N1, N2, V1, and V2, the following JVM flags are set: > - UseSIMDForMemoryOps=true > - OnSpinWaitInst=isb > - OnSpinWaitInstCount=1 > - AlwaysMergeDMB=false > > Additionally, for Neoverse V1 and V2 only, these flags are set: > - UseCryptoPmullForCRC32=true > - CodeEntryAlignment=32 > > Set the same flags for Neoverse N3 and V3, respectively. Based on the available V3 and N3 optimization guides, we should expect similar or better performance on V3 and N3 when these changes are applied. ------------- Marked as reviewed by eastigeevich (Committer). PR Review: https://git.openjdk.org/jdk/pull/26701#pullrequestreview-3245820561 From liach at openjdk.org Fri Sep 19 17:02:48 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Sep 2025 17:02:48 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v5] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 02:10:15 GMT, Ioi Lam wrote: >> This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. >> >> This PR annotates a single class, `jdk.internal.math.MathUtils` (also the object hierarchy root class, `Object.class`, which has no associated AOT initialization but is required for completeness). More classes will be added in future PRs. >> >> If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to >> - All of `K`'s super classes >> - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` >> >> Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). >> >> This annotation is awfully similar to `@AOTSafeClassInitializer`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: > > - Updated requirements for annotations on supertypes for AOTInitialize and AOTSafeClassInitializer > - Merge branch 'master' into aot-initialize-math-utils > - Added logging about @AOTSafeClassInitializer classes that have not been initialized > - Added comment about the order of FinalImageRecipes::apply_recipes() vs link_all_loaded_classes() > - Exclude more GC heap size tests as AOT cache size has increased for "make test JTREG=AOT_JDK=onestep ..." > - Added javadoc; added test case; code clean up > - Merge branch 'master' into aot-initialize-math-utils > - cleanup > - Merge branch 'master' into aot-initialize-math-utils > - Merge branch '8366477-refactor-aot-related-flag-bits-in-klass-hpp' into aot-initialize-math-utils > - ... and 13 more: https://git.openjdk.org/jdk/compare/7ec3fa5f...d21bfb12 src/hotspot/share/cds/aotMetaspace.cpp line 1266: > 1264: if (HAS_PENDING_EXCEPTION) { > 1265: ResourceMark rm; > 1266: log_error(aot, init)("class %s has @AOTForceInitialize but failed to initialize", Suggestion: log_error(aot, init)("class %s has @AOTInitialize but failed to initialize", ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27024#discussion_r2363651802 From kbarrett at openjdk.org Fri Sep 19 17:12:22 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 19 Sep 2025 17:12:22 GMT Subject: RFR: 8367536: Change RBTree to use C++17 features [v5] In-Reply-To: References: Message-ID: <_yytRYw4r4alQIBjHJMkwZSLN451svLeFhxk8ayl45Y=.a4ee6df6-b2e0-4ba1-9232-5da66add28f9@github.com> On Fri, 19 Sep 2025 08:55:09 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> C++17 lets us tidy up som of the ugly templating done in the red-black tree. We can replace the `std::false_type`/`std::true_type` tricks used to discover comparator and verifier signatures with the new `std::is_invocable(_r_v)`, and most of the overload/SFINAE noise can disappear thanks to `if constexpr`. >> >> We can now write one-liners such as: >> ```c++ >> static constexpr bool HasKeyComparator = std::is_invocable_r_v; >> >> >> and then select the right branch with >> ```c++ >> if constexpr (HasKeyComparator) { } >> >> inside a single function instead of having several `ENABLE_IF` overloads. >> >> This results in fewer lines, clearer intent, and more readable errors, while keeping behaviour identical. >> >> Testing: >> - Oracle tiers 1-3 > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > typo Still good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27260#pullrequestreview-3245998696 From iklam at openjdk.org Fri Sep 19 17:24:29 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Sep 2025 17:24:29 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v6] In-Reply-To: References: Message-ID: > This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. > > This PR annotates a single class, `jdk.internal.math.MathUtils` (also the object hierarchy root class, `Object.class`, which has no associated AOT initialization but is required for completeness). More classes will be added in future PRs. > > If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to > - All of `K`'s super classes > - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` > > Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). > > This annotation is awfully similar to `@AOTSafeClassInitializer`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @liach comment - fixed typo in logging ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27024/files - new: https://git.openjdk.org/jdk/pull/27024/files/d21bfb12..eecfb42c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27024&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27024&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27024.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27024/head:pull/27024 PR: https://git.openjdk.org/jdk/pull/27024 From iklam at openjdk.org Fri Sep 19 17:24:32 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 19 Sep 2025 17:24:32 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v5] In-Reply-To: References: Message-ID: <9sj-YIuj9CGNBwJh06XbAVHS8kq4vAFx23-5i_fOrKY=.e6ebf522-55bf-421c-978e-f4ea987a6016@github.com> On Fri, 19 Sep 2025 16:57:42 GMT, Chen Liang wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: >> >> - Updated requirements for annotations on supertypes for AOTInitialize and AOTSafeClassInitializer >> - Merge branch 'master' into aot-initialize-math-utils >> - Added logging about @AOTSafeClassInitializer classes that have not been initialized >> - Added comment about the order of FinalImageRecipes::apply_recipes() vs link_all_loaded_classes() >> - Exclude more GC heap size tests as AOT cache size has increased for "make test JTREG=AOT_JDK=onestep ..." >> - Added javadoc; added test case; code clean up >> - Merge branch 'master' into aot-initialize-math-utils >> - cleanup >> - Merge branch 'master' into aot-initialize-math-utils >> - Merge branch '8366477-refactor-aot-related-flag-bits-in-klass-hpp' into aot-initialize-math-utils >> - ... and 13 more: https://git.openjdk.org/jdk/compare/7ec3fa5f...d21bfb12 > > src/hotspot/share/cds/aotMetaspace.cpp line 1266: > >> 1264: if (HAS_PENDING_EXCEPTION) { >> 1265: ResourceMark rm; >> 1266: log_error(aot, init)("class %s has @AOTForceInitialize but failed to initialize", > > Suggestion: > > log_error(aot, init)("class %s has @AOTInitialize but failed to initialize", Thanks for catching this. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27024#discussion_r2363778305 From sparasa at openjdk.org Fri Sep 19 18:21:57 2025 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Fri, 19 Sep 2025 18:21:57 GMT Subject: Integrated: 8367780: Enable UseAPX on Intel CPUs only when both APX_F and APX_NCI_NDD_NF cpuid features are present In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 18:04:33 GMT, Srinivas Vamsi Parasa wrote: > The goal of this PR is to enable APX on Intel CPUs (i.e. enable UseAPX) only when both the APX_F and APX_NCI_NDD_NF cpuid feature flags are present. > > The latest update to the Intel APX specification (https://www.intel.com/content/www/us/en/content-details/861610/intel-advanced-performance-extensions-intel-apx-architecture-specification.html ) has changed how APX features are detected on Intel CPUs. Because of this change, we need to update how the JVM enumerates CPU features. > > As per the new update, when APX_F is set, processors also provide CPUID leaf 0x29 (APX Advanced Performance Extensions Leaf). Any Intel processor that enumerates APX_F also enumerates APX_NCI_NDD_NF. > > This PR enhances the HotSpot x86 CPU feature detection to recognize the APX_NCI_NDD_NF sub-feature of Intel APX and update the enabling logic for UseAPX VM flag. This pull request has now been integrated. Changeset: 3d4e0491 Author: Srinivas Vamsi Parasa URL: https://git.openjdk.org/jdk/commit/3d4e0491940c4b4a05ac84006933d939370e7e2b Stats: 29 lines in 2 files changed: 26 ins; 0 del; 3 mod 8367780: Enable UseAPX on Intel CPUs only when both APX_F and APX_NCI_NDD_NF cpuid features are present Reviewed-by: sviswanathan, vpaprotski ------------- PR: https://git.openjdk.org/jdk/pull/27320 From liach at openjdk.org Fri Sep 19 18:25:31 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Sep 2025 18:25:31 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v6] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 17:24:29 GMT, Ioi Lam wrote: >> This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. >> >> This PR annotates a single class, `jdk.internal.math.MathUtils` (also the object hierarchy root class, `Object.class`, which has no associated AOT initialization but is required for completeness). More classes will be added in future PRs. >> >> If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to >> - All of `K`'s super classes >> - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` >> >> Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). >> >> This annotation is awfully similar to `@AOTSafeClassInitializer`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @liach comment - fixed typo in logging No other comment so far. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27024#pullrequestreview-3246373495 From asmehra at openjdk.org Fri Sep 19 18:41:03 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 19 Sep 2025 18:41:03 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v9] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 04:46:13 GMT, Ioi Lam wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed 32-bit builds src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 184: > 182: > 183: void AOTLinkedClassBulkLoader::link_or_init_javabase_classes(TRAPS) { > 184: link_or_init_classes_for_loader(Handle(), AOTLinkedClassTable::get()->boot1(), CHECK); Is exception check not needed here, like it is done in `link_or_init_non_javabase_classes()`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2364073186 From asmehra at openjdk.org Fri Sep 19 18:41:00 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 19 Sep 2025 18:41:00 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v8] In-Reply-To: <5_ai8lG-Zs7B3xi8XQ0dnrr2TDmywRALaeN0uyqyUQ8=.18e3bfa2-9512-4173-8fc3-a83d827e7353@github.com> References: <5_ai8lG-Zs7B3xi8XQ0dnrr2TDmywRALaeN0uyqyUQ8=.18e3bfa2-9512-4173-8fc3-a83d827e7353@github.com> Message-ID: On Fri, 19 Sep 2025 01:41:34 GMT, Ioi Lam wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits: >> >> - Removed JVMCI-specific checks that are no longer necessary with class preloading -- all CP entries discoverable by JVMCI will always point to already-loaded classes >> - Simplify implementation after JDK-8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - @ashu-mehra comment: removed AOTLinkedClassBulkLoader::is_pending_aot_linked_class >> - @ashu-mehra review comments >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap >> - @DanHeidinga comments -- added comments and asserts about the handling of enums >> - @DanHeidinga comment - add test: user enum types are not initialized in assembly phase >> - ... and 17 more: https://git.openjdk.org/jdk/compare/91a97943...04cb7a64 > > @ashu-mehra , I've remove all the code that was needed to handle aot-linked classes from the dynamic archive but is no longer needed since [JDK-8367366](https://bugs.openjdk.org/browse/JDK-8367366). I am able to remove about 200 lines of code. > > I also renamed a few functions in `AOTLinkedClassBulkLoader` to reflect the up-to-date meaning. > > `CDSConfig::is_using_preloaded_classes()` has been removed and replaced with `CDSConfig::is_using_aot_linked_classes()` > > The handling of `fixup_mirror_list()` and `fixup_module_field_list()` in javaClasses.cpp have been made uniform. > > Please see https://github.com/openjdk/jdk/pull/26375/commits/896ce8b9636a5534f1db487afbe27e875022fbfa @iklam thank you for updating the changes. It is much easier to follow the code now. I have just one additional comment, otherwise looks good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26375#issuecomment-3313363526 From vpaprotski at openjdk.org Fri Sep 19 18:59:49 2025 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Fri, 19 Sep 2025 18:59:49 GMT Subject: RFR: 8367611: Enable vblendvp[sd] on Future ECore [v2] In-Reply-To: References: <_Jk5fv1iO9ZPZyOtUAXeUez481RibKJR4FsUT_BnKm8=.2f68f9ee-9ce2-4dbb-be8b-1b9f910ba0e0@github.com> Message-ID: On Thu, 18 Sep 2025 23:28:07 GMT, Mohamed Issa wrote: >> The upcoming ECore platforms will benefit from using `vblendvps` and `vblendvpd` instructions when the destination register is the same as the source register. This change takes that situation into account. >> >> The JTREG test shown below was used to verify correctness against the [OpenJDK v26-b15](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B15) baseline build. >> >> 1. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` > > Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: > > Use function to identify Darkmont cores instead of global flag src/hotspot/cpu/x86/macroAssembler_x86.cpp line 2900: > 2898: void MacroAssembler::vblendvps(XMMRegister dst, XMMRegister src1, XMMRegister src2, XMMRegister mask, int vector_len, bool compute_mask, XMMRegister scratch) { > 2899: // WARN: Allow dst == (src1|src2), mask == scratch > 2900: bool use_blend_instr = VM_Version::is_intel_darkmont() && (dst == src1); My only real comment is a nit-pick about the variable name.. `use_blend_instr` implies a range of _darkmont and above_ and _'EnableX86CoreOpts' and 'below'_.. which is not the value of this variable (i.e. just darkmont and above). Perhaps `blend_fixed`? `blend_partly_fixed`? Or 'just' add it to the `blend_emulation`... bool blend_emulation = EnableX86ECoreOpts && UseAVX > 1 && VM_Version::is_intel_darkmont() && (dst == src1); // partly fixed on Darkmont ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27354#discussion_r2364153198 From vlivanov at openjdk.org Fri Sep 19 19:41:52 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 19 Sep 2025 19:41:52 GMT Subject: RFR: 8290892: C2: Intrinsify Reference.reachabilityFence [v13] In-Reply-To: References: Message-ID: > This PR introduces C2 support for `Reference.reachabilityFence()`. > > After [JDK-8199462](https://bugs.openjdk.org/browse/JDK-8199462) went in, it was discovered that C2 may break the invariant the fix relied upon [1]. So, this is an attempt to introduce proper support for `Reference.reachabilityFence()` in C2. C1 is left intact for now, because there are no signs yet it is affected. > > `Reference.reachabilityFence()` can be used in performance critical code, so the primary goal for C2 is to reduce its runtime overhead as much as possible. The ultimate goal is to ensure liveness information is attached to interfering safepoints, but it takes multiple steps to properly propagate the information through compilation pipeline without negatively affecting generated code quality. > > Also, I don't consider this fix as complete. It does fix the reported problem, but it doesn't provide any strong guarantees yet. In particular, since `ReachabilityFence` is CFG-only node, nothing explicitly forbids memory operations to float past `Reference.reachabilityFence()` and potentially reaching some other safepoints current analysis treats as non-interfering. Representing `ReachabilityFence` as memory barrier (e.g., `MemBarCPUOrder`) would solve the issue, but performance costs are prohibitively high. Alternatively, the optimization proposed in this PR can be improved to conservatively extend referent's live range beyond `ReachabilityFence` nodes associated with it. It would meet performance criteria, but I prefer to implement it as a followup fix. > > Another known issue relates to reachability fences on constant oops. If such constant is GCed (most likely, due to a bug in Java code), similar reachability issues may arise. For now, RFs on constants are treated as no-ops, but there's a diagnostic flag `PreserveReachabilityFencesOnConstants` to keep the fences. I plan to address it separately. > > [1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/ref/Reference.java#L667 > "HotSpot JVM retains the ref and does not GC it before a call to this method, because the JIT-compilers do not have GC-only safepoints." > > Testing: > - [x] hs-tier1 - hs-tier8 > - [x] hs-tier1 - hs-tier6 w/ -XX:+StressReachabilityFences -XX:+VerifyLoopOptimizations > - [x] java/lang/foreign microbenchmarks Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: Remove comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25315/files - new: https://git.openjdk.org/jdk/pull/25315/files/dc37ccad..68150cc6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25315&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25315&range=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25315/head:pull/25315 PR: https://git.openjdk.org/jdk/pull/25315 From kvn at openjdk.org Fri Sep 19 20:47:53 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 19 Sep 2025 20:47:53 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry [v2] In-Reply-To: References: Message-ID: <_yqpsrOhaFm347Wei3QwpnTkVYWUsto0RDWNI6s1EG4=.946635b8-27c7-40e4-80b9-5f2e4c6fd4c4@github.com> On Fri, 19 Sep 2025 14:57:58 GMT, Ashutosh Mehra wrote: >> This PR removes the need to store entry point addresses in AdapterHandlerEntry by storing a direct pointer to AdapterBlob instead. Entry point addresses can be computed on the fly from the entry point offsets stored in AdapterBlob. > > Ashutosh Mehra 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 five additional commits since the last revision: > > - Merge branch 'master' into store-blob-pointer-adapterhandlerentry-v2 > - Remove unused method and change numeric constants to enums > > Signed-off-by: Ashutosh Mehra > - Address review comments > > Signed-off-by: Ashutosh Mehra > - Do not call generate_i2c2i_adapters() on zero > > Signed-off-by: Ashutosh Mehra > - Store pointer to AdapterBlob in AdapterHandlerEntry > > Signed-off-by: Ashutosh Mehra Test runtime/cds/appcds/aotClassLinking/StringConcatStress.java#aot crashed on all platforms: # Internal Error (/workspace/open/src/hotspot/share/memory/resourceArea.cpp:54), pid=3871604, tid=3871606 # fatal error: memory leak: allocating without ResourceMark # # JRE version: (26.0) (fastdebug build ) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 26-internal-2025-09-19-1627068.vladimir.kozlov.jdkgit2, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x191e1c6] ResourceArea::verify_has_resource_mark() [clone .part.0]+0x26 # --------------- S U M M A R Y ------------ Command Line: -XX:MaxRAMPercentage=4.16667 -Dtest.boot.jdk=/install/jdk/24/36/bundles/linux-x64/jdk-24_linux-x64_bin.tar.gz/jdk-24 -Djava.io.tmpdir=/tmp -XX:+AOTClassLinking -Xlog:arguments,aot,cds:file=StringConcatStressApp.production.log::filesize=0 -XX:AOTMode=on -XX:AOTCache=StringConcatStressApp.aot StringConcatStressApp --------------- T H R E A D --------------- Current thread (0x00007fad1002ded0): JavaThread "Unknown thread" [_thread_in_vm, id=3871606, stack(0x00007fad140b9000,0x00007fad141b9000) (1024K)] Stack: [0x00007fad140b9000,0x00007fad141b9000], sp=0x00007fad141b59a0, free space=1010k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x191e1c6] ResourceArea::verify_has_resource_mark() [clone .part.0]+0x26 (resourceArea.cpp:54) V [libjvm.so+0x191e55b] (align.hpp:82) V [libjvm.so+0x17e4f87] stringStream::as_string(bool) const+0x57 (ostream.cpp:425) V [libjvm.so+0x1989e3b] AdapterHandlerLibrary::link_aot_adapters()+0x54b (sharedRuntime.cpp:2359) V [libjvm.so+0x198a925] AdapterHandlerLibrary::initialize()+0x3a5 (sharedRuntime.cpp:2558) V [libjvm.so+0x10481b6] init_globals()+0xa6 (init.cpp:168) V [libjvm.so+0x1b7c08e] Threads::create_vm(JavaVMInitArgs*, bool*)+0x34e (threads.cpp:592) V [libjvm.so+0x12159b4] JNI_CreateJavaVM+0x54 (jni.cpp:3587) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27101#issuecomment-3313756166 From apangin at openjdk.org Fri Sep 19 20:59:14 2025 From: apangin at openjdk.org (Andrei Pangin) Date: Fri, 19 Sep 2025 20:59:14 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing [v6] In-Reply-To: References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> Message-ID: On Fri, 19 Sep 2025 13:25:37 GMT, Johannes Bechberger wrote: >> This change hopefully fixes the test failures by making the test cases more resilient. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Add synchronized Marked as reviewed by apangin (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/27293#pullrequestreview-3247082079 From asmehra at openjdk.org Fri Sep 19 21:01:34 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 19 Sep 2025 21:01:34 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v4] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 02:05:46 GMT, Ioi Lam wrote: >>> Note, the check of the above requirement has been moved to AOTClassInitializer::check_aot_annotations(). The previous check in ClassFileParser was not executed because the class is loaded in the AOT training run, where CDSConfig::is_initing_classes_at_dump_time() returns false (this function returns true only in the AOT assembly phase). >> >> So this is a bug already present in the code and effectively disables super type checks for AOTSafeClassInitializer annotation, is that right? >> There is a reference to ClassFileParser in the documentation for AOTSafeClassInitializer. I think it needs to be updated as well: https://github.com/openjdk/jdk/blob/18dc186a8f4820ed78c21173713dd127ef512e1f/src/java.base/share/classes/jdk/internal/vm/annotation/AOTSafeClassInitializer.java#L124-L129 > >> > Note, the check of the above requirement has been moved to AOTClassInitializer::check_aot_annotations(). The previous check in ClassFileParser was not executed because the class is loaded in the AOT training run, where CDSConfig::is_initing_classes_at_dump_time() returns false (this function returns true only in the AOT assembly phase). >> >> So this is a bug already present in the code and effectively disables super type checks for AOTSafeClassInitializer annotation, is that right? > > Yes, that's a bug in the current code in the mainline. > >> There is a reference to ClassFileParser in the documentation for AOTSafeClassInitializer. I think it needs to be updated as well: >> >> https://github.com/openjdk/jdk/blob/18dc186a8f4820ed78c21173713dd127ef512e1f/src/java.base/share/classes/jdk/internal/vm/annotation/AOTSafeClassInitializer.java#L124-L129 > > I updated the requirements about safety and supertypes for both `AOTInitialize` and `AOTSafeClassInitializer` to use the exact same wording. I think it's OK to describe the effect (the AOT assembly phase will fail) without the details about where we do the checks: > > > /// Before adding this annotation to a class _X_, the author must determine > /// that it's safe to execute the static initializer of _X_ during the AOT > /// assembly phase. In addition, all supertypes of _X_ must also have this > /// annotation. If a supertype of _X_ is found to be missing this annotation, > /// the AOT assembly phase will fail. @iklam Reading up the description of the bug tracker, it seems we are trying to find out more opportunities to AOT initialize classes than the current state. Is that correct? I may be missing something here, why not "force initialize" classes annotated with `AOTSafeClassInitializer` in `AOTMetaspace::try_link_class`, instead of introducing new annotation? Wouldn't that serve the same purpose? And I think we also need to track the classes that are actually initialized in the training phase, and apply "force initialization" only on that subset. Otherwise we can end up in situation where a classes is loaded and not initialized in training phase, but still gets AOT initialized because it is annotated with `AOTInitialize`. > Also, in AOTMetaspace::try_link_class(), which is called before we enter the CDS safepoint, we try to initialize all force_aot_initialization() classes in this loop: @iklam I missed this. It clarifies the situation I was referring to. Thanks for the explanation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27024#issuecomment-3313786069 PR Review Comment: https://git.openjdk.org/jdk/pull/27024#discussion_r2364513736 From asmehra at openjdk.org Fri Sep 19 21:45:16 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 19 Sep 2025 21:45:16 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry [v3] In-Reply-To: References: Message-ID: > This PR removes the need to store entry point addresses in AdapterHandlerEntry by storing a direct pointer to AdapterBlob instead. Entry point addresses can be computed on the fly from the entry point offsets stored in AdapterBlob. Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: Add missing ResourceMark Signed-off-by: Ashutosh Mehra ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27101/files - new: https://git.openjdk.org/jdk/pull/27101/files/fff99163..b939ee98 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27101&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27101&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27101.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27101/head:pull/27101 PR: https://git.openjdk.org/jdk/pull/27101 From asmehra at openjdk.org Fri Sep 19 21:45:20 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 19 Sep 2025 21:45:20 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry [v2] In-Reply-To: <_yqpsrOhaFm347Wei3QwpnTkVYWUsto0RDWNI6s1EG4=.946635b8-27c7-40e4-80b9-5f2e4c6fd4c4@github.com> References: <_yqpsrOhaFm347Wei3QwpnTkVYWUsto0RDWNI6s1EG4=.946635b8-27c7-40e4-80b9-5f2e4c6fd4c4@github.com> Message-ID: On Fri, 19 Sep 2025 20:44:57 GMT, Vladimir Kozlov wrote: >> Ashutosh Mehra 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 five additional commits since the last revision: >> >> - Merge branch 'master' into store-blob-pointer-adapterhandlerentry-v2 >> - Remove unused method and change numeric constants to enums >> >> Signed-off-by: Ashutosh Mehra >> - Address review comments >> >> Signed-off-by: Ashutosh Mehra >> - Do not call generate_i2c2i_adapters() on zero >> >> Signed-off-by: Ashutosh Mehra >> - Store pointer to AdapterBlob in AdapterHandlerEntry >> >> Signed-off-by: Ashutosh Mehra > > Test runtime/cds/appcds/aotClassLinking/StringConcatStress.java#aot crashed on all platforms: > > > # Internal Error (/workspace/open/src/hotspot/share/memory/resourceArea.cpp:54), pid=3871604, tid=3871606 > # fatal error: memory leak: allocating without ResourceMark > # > # JRE version: (26.0) (fastdebug build ) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 26-internal-2025-09-19-1627068.vladimir.kozlov.jdkgit2, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) > # Problematic frame: > # V [libjvm.so+0x191e1c6] ResourceArea::verify_has_resource_mark() [clone .part.0]+0x26 > # > > --------------- S U M M A R Y ------------ > > Command Line: -XX:MaxRAMPercentage=4.16667 -Dtest.boot.jdk=/install/jdk/24/36/bundles/linux-x64/jdk-24_linux-x64_bin.tar.gz/jdk-24 -Djava.io.tmpdir=/tmp -XX:+AOTClassLinking -Xlog:arguments,aot,cds:file=StringConcatStressApp.production.log::filesize=0 -XX:AOTMode=on -XX:AOTCache=StringConcatStressApp.aot StringConcatStressApp > > --------------- T H R E A D --------------- > > Current thread (0x00007fad1002ded0): JavaThread "Unknown thread" [_thread_in_vm, id=3871606, stack(0x00007fad140b9000,0x00007fad141b9000) (1024K)] > > Stack: [0x00007fad140b9000,0x00007fad141b9000], sp=0x00007fad141b59a0, free space=1010k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x191e1c6] ResourceArea::verify_has_resource_mark() [clone .part.0]+0x26 (resourceArea.cpp:54) > V [libjvm.so+0x191e55b] (align.hpp:82) > V [libjvm.so+0x17e4f87] stringStream::as_string(bool) const+0x57 (ostream.cpp:425) > V [libjvm.so+0x1989e3b] AdapterHandlerLibrary::link_aot_adapters()+0x54b (sharedRuntime.cpp:2359) > V [libjvm.so+0x198a925] AdapterHandlerLibrary::initialize()+0x3a5 (sharedRuntime.cpp:2558) > V [libjvm.so+0x10481b6] init_globals()+0xa6 (init.cpp:168) > V [libjvm.so+0x1b7c08e] Threads::create_vm(JavaVMInitArgs*, bool*)+0x34e (threads.cpp:592) > V [libjvm.so+0x12159b4] JNI_CreateJavaVM+0x54 (jni.cpp:3587) @vnkozlov I incorrectly removed a ResourceMark in `AdapterHandlerEntry::link()` which is causing the crash. Pushed a commit to add it back. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27101#issuecomment-3313916585 From missa at openjdk.org Fri Sep 19 21:57:30 2025 From: missa at openjdk.org (Mohamed Issa) Date: Fri, 19 Sep 2025 21:57:30 GMT Subject: RFR: 8367611: Enable vblendvp[sd] on Future ECore [v3] In-Reply-To: <_Jk5fv1iO9ZPZyOtUAXeUez481RibKJR4FsUT_BnKm8=.2f68f9ee-9ce2-4dbb-be8b-1b9f910ba0e0@github.com> References: <_Jk5fv1iO9ZPZyOtUAXeUez481RibKJR4FsUT_BnKm8=.2f68f9ee-9ce2-4dbb-be8b-1b9f910ba0e0@github.com> Message-ID: > The upcoming ECore platforms will benefit from using `vblendvps` and `vblendvpd` instructions when the destination register is the same as the source register. This change takes that situation into account. > > The JTREG test shown below was used to verify correctness against the [OpenJDK v26-b15](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B15) baseline build. This test frequently calls vblendvps() and vblendvpd() in the macro assembler. On Darkmont and non-Darkmont cores, the right code paths are followed when checking with asserts. > > 1. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: Combine boolean flags to avoid ambiguity ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27354/files - new: https://git.openjdk.org/jdk/pull/27354/files/88ac7733..5e5c0275 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27354&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27354&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27354.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27354/head:pull/27354 PR: https://git.openjdk.org/jdk/pull/27354 From missa at openjdk.org Fri Sep 19 21:57:33 2025 From: missa at openjdk.org (Mohamed Issa) Date: Fri, 19 Sep 2025 21:57:33 GMT Subject: RFR: 8367611: Enable vblendvp[sd] on Future ECore [v2] In-Reply-To: References: <_Jk5fv1iO9ZPZyOtUAXeUez481RibKJR4FsUT_BnKm8=.2f68f9ee-9ce2-4dbb-be8b-1b9f910ba0e0@github.com> Message-ID: On Fri, 19 Sep 2025 18:57:20 GMT, Volodymyr Paprotski wrote: >> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: >> >> Use function to identify Darkmont cores instead of global flag > > src/hotspot/cpu/x86/macroAssembler_x86.cpp line 2900: > >> 2898: void MacroAssembler::vblendvps(XMMRegister dst, XMMRegister src1, XMMRegister src2, XMMRegister mask, int vector_len, bool compute_mask, XMMRegister scratch) { >> 2899: // WARN: Allow dst == (src1|src2), mask == scratch >> 2900: bool use_blend_instr = VM_Version::is_intel_darkmont() && (dst == src1); > > My only real comment is a nit-pick about the variable name.. `use_blend_instr` implies a range of _darkmont and above_ and _'EnableX86CoreOpts' and 'below'_.. which is not the value of this variable (i.e. just darkmont and above). Perhaps `blend_fixed`? `blend_partly_fixed`? Or 'just' add it to the `blend_emulation`... > > bool blend_emulation = EnableX86ECoreOpts && UseAVX > 1 > && VM_Version::is_intel_darkmont() && (dst == src1); // partly fixed on Darkmont I added it to `blend_emulation` as that seems to make the most sense. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27354#discussion_r2364615340 From kvn at openjdk.org Sat Sep 20 00:39:18 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 20 Sep 2025 00:39:18 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry [v3] In-Reply-To: References: Message-ID: <62uyiH6FhBDP3AfGgGQJbc0gbg7vtfFGw_z9sM1blBk=.d32f7b33-1b89-42cd-a3b2-904b0113eef3@github.com> On Fri, 19 Sep 2025 21:45:16 GMT, Ashutosh Mehra wrote: >> This PR removes the need to store entry point addresses in AdapterHandlerEntry by storing a direct pointer to AdapterBlob instead. Entry point addresses can be computed on the fly from the entry point offsets stored in AdapterBlob. > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Add missing ResourceMark > > Signed-off-by: Ashutosh Mehra I submitted new testing ------------- PR Comment: https://git.openjdk.org/jdk/pull/27101#issuecomment-3314299716 From iklam at openjdk.org Sat Sep 20 00:57:09 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 20 Sep 2025 00:57:09 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v10] In-Reply-To: References: Message-ID: > This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. > > - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. > - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. > - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @ashu-mehra comment - AOTLinkedClassBulkLoader::link_or_init_javabase_classes() should also call exit_on_exception() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26375/files - new: https://git.openjdk.org/jdk/pull/26375/files/9ec10f5f..9072a1df Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=08-09 Stats: 20 lines in 3 files changed: 14 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26375/head:pull/26375 PR: https://git.openjdk.org/jdk/pull/26375 From iklam at openjdk.org Sat Sep 20 00:57:12 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 20 Sep 2025 00:57:12 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v9] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 18:35:36 GMT, Ashutosh Mehra wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed 32-bit builds > > src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 184: > >> 182: >> 183: void AOTLinkedClassBulkLoader::link_or_init_javabase_classes(TRAPS) { >> 184: link_or_init_classes_for_loader(Handle(), AOTLinkedClassTable::get()->boot1(), CHECK); > > Is exception check not needed here, like it is done in `link_or_init_non_javabase_classes()`? I changed this function to do the same check as in `link_or_init_non_javabase_classes()`. I also updated the comments to explain why this is necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2364925599 From iklam at openjdk.org Sat Sep 20 01:26:18 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 20 Sep 2025 01:26:18 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v4] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 02:05:46 GMT, Ioi Lam wrote: >>> Note, the check of the above requirement has been moved to AOTClassInitializer::check_aot_annotations(). The previous check in ClassFileParser was not executed because the class is loaded in the AOT training run, where CDSConfig::is_initing_classes_at_dump_time() returns false (this function returns true only in the AOT assembly phase). >> >> So this is a bug already present in the code and effectively disables super type checks for AOTSafeClassInitializer annotation, is that right? >> There is a reference to ClassFileParser in the documentation for AOTSafeClassInitializer. I think it needs to be updated as well: https://github.com/openjdk/jdk/blob/18dc186a8f4820ed78c21173713dd127ef512e1f/src/java.base/share/classes/jdk/internal/vm/annotation/AOTSafeClassInitializer.java#L124-L129 > >> > Note, the check of the above requirement has been moved to AOTClassInitializer::check_aot_annotations(). The previous check in ClassFileParser was not executed because the class is loaded in the AOT training run, where CDSConfig::is_initing_classes_at_dump_time() returns false (this function returns true only in the AOT assembly phase). >> >> So this is a bug already present in the code and effectively disables super type checks for AOTSafeClassInitializer annotation, is that right? > > Yes, that's a bug in the current code in the mainline. > >> There is a reference to ClassFileParser in the documentation for AOTSafeClassInitializer. I think it needs to be updated as well: >> >> https://github.com/openjdk/jdk/blob/18dc186a8f4820ed78c21173713dd127ef512e1f/src/java.base/share/classes/jdk/internal/vm/annotation/AOTSafeClassInitializer.java#L124-L129 > > I updated the requirements about safety and supertypes for both `AOTInitialize` and `AOTSafeClassInitializer` to use the exact same wording. I think it's OK to describe the effect (the AOT assembly phase will fail) without the details about where we do the checks: > > > /// Before adding this annotation to a class _X_, the author must determine > /// that it's safe to execute the static initializer of _X_ during the AOT > /// assembly phase. In addition, all supertypes of _X_ must also have this > /// annotation. If a supertype of _X_ is found to be missing this annotation, > /// the AOT assembly phase will fail. > @iklam Reading up the description of the bug tracker, it seems we are trying to find out more opportunities to AOT initialize classes than the current state. Is that correct? I may be missing something here, why not "force initialize" classes annotated with `AOTSafeClassInitializer` in `AOTMetaspace::try_link_class`, instead of introducing new annotation? Wouldn't that serve the same purpose? And I think we also need to track the classes that are actually initialized in the training phase, and apply "force initialization" only on that subset. Otherwise we can end up in situation where a classes is loaded and not initialized in training phase, but still gets AOT initialized because it is annotated with `AOTInitialize`. I think this is a better alternative. I will fix the implementation to do what you described (by tracking the set of initialized classes in finalImageRecipes..cpp). To avoid confusion, I will post a separate PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27024#issuecomment-3314360461 From sspitsyn at openjdk.org Sat Sep 20 04:47:47 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 20 Sep 2025 04:47:47 GMT Subject: RFR: 8368159: Significant performance overhead when started with jdwp agent and unattached debugger Message-ID: This update removes a significant performance overhead when an application running millions of virtual threads is started with the JDWP agent but debugger has not been attached. The overhead is 4X-6X slowdown. The tested app normally (without debug agent) takes around 3+ seconds. With debug agent enabled it takes 14 seconds and more. The performance overhead is caused by the `jvmti_yield_cleanup()` recursively calling `JvmtiExport::continuation_yield_cleanup()`. The reason of this overhead is because the function `JvmtiExport::can_post_frame_pop()` is used to identify a need for the JVMTI cleanup which is not precise and triggers unneeded work when debugger has not been attached yet. The fix is to trigger the JVMTI cleanup with new function: `bool JvmtiExport::has_frame_pops(JavaThread* thread)`. Testing: - Insure the 4X-6X slowdown is gone for application an application running millions of virtual threads and started with the JDWP agent - Mach5 tiers 1-6 are all passed ------------- Commit messages: - 8368159: Significant performance overhead when started with jdwp agent and unattached debugger Changes: https://git.openjdk.org/jdk/pull/27403/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27403&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368159 Stats: 21 lines in 3 files changed: 18 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27403.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27403/head:pull/27403 PR: https://git.openjdk.org/jdk/pull/27403 From sspitsyn at openjdk.org Sat Sep 20 05:10:50 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 20 Sep 2025 05:10:50 GMT Subject: RFR: 8368159: Significant performance overhead when started with jdwp agent and unattached debugger [v2] In-Reply-To: References: Message-ID: > This update removes a significant performance overhead when an application running millions of virtual threads is started with the JDWP agent but debugger has not been attached. The overhead is 4X-6X slowdown. > The tested app normally (without debug agent) takes around 3+ seconds. With debug agent enabled it takes 14 seconds and more. The performance overhead is caused by the `jvmti_yield_cleanup()` recursively calling `JvmtiExport::continuation_yield_cleanup()`. The reason of this overhead is because the function `JvmtiExport::can_post_frame_pop()` is used to identify a need for the JVMTI cleanup which is not precise and triggers unneeded work when debugger has not been attached yet. The fix is to trigger the JVMTI cleanup with new function: `bool JvmtiExport::has_frame_pops(JavaThread* thread)`. > > Testing: > - Insure the 4X-6X slowdown is gone for application an application running millions of virtual threads and started with the JDWP agent > - Mach5 tiers 1-6 are all passed Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: fix minimal build broken by incorrect macro usage ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27403/files - new: https://git.openjdk.org/jdk/pull/27403/files/0f63bb17..4b0478fc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27403&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27403&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27403.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27403/head:pull/27403 PR: https://git.openjdk.org/jdk/pull/27403 From sspitsyn at openjdk.org Sat Sep 20 05:58:19 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 20 Sep 2025 05:58:19 GMT Subject: RFR: 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition() [v2] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 03:06:42 GMT, Ioi Lam wrote: >> Simplify the boilerplate code in jvm.cpp that calls `JvmtiThreadState::class_to_verify_considering_redefinition()`, and reduce the number of `InstanceKlass::cast()` calls. >> >> I also changed a few fields/arguments from `Klass*` to `InstanceKlass*` as these are used exclusively with `InstanceKlass*`. > > Ioi Lam 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 three additional commits since the last revision: > > - @coleenp and @dholmes-ora comments -- simplify implementation; fixed code formatting > - Merge branch 'master' into 8367719-refactor-jni-code-that-uses-class_to_verify_considering_redefinition > - 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition() Nice refactoring! Looks good. src/hotspot/share/prims/jvm.cpp line 2259: > 2257: // get_klass_considering_redefinition(), or > 2258: // get_instance_klass_considering_redefinition() > 2259: // These function return JvmtiThreadState::_scratch_class if the verifier Nit: Replaces: `These function` => `These functions` ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27303#pullrequestreview-3248533772 PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2365340212 From sspitsyn at openjdk.org Sat Sep 20 06:01:20 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 20 Sep 2025 06:01:20 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v5] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 16:30:01 GMT, Coleen Phillimore wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix rename > > You might want @sspitsyn to review the jvmtiRedefineClasses changes since he did this work for the existing operands arrays. > @coleenp said: You might want @sspitsyn to review the jvmtiRedefineClasses changes since he did this work for the existing operands arrays. Thanks. I'm looking at this update. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27198#issuecomment-3314615646 From iklam at openjdk.org Sat Sep 20 06:43:00 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 20 Sep 2025 06:43:00 GMT Subject: RFR: 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition() [v3] In-Reply-To: References: Message-ID: <2aaupl63WuQcMIaF_FtAudQrlhGo_fqJeF_9on4Jyz0=.0475b16d-6d9a-47e8-ad01-a091c8924398@github.com> > Simplify the boilerplate code in jvm.cpp that calls `JvmtiThreadState::class_to_verify_considering_redefinition()`, and reduce the number of `InstanceKlass::cast()` calls. > > I also changed a few fields/arguments from `Klass*` to `InstanceKlass*` as these are used exclusively with `InstanceKlass*`. Ioi Lam 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 five additional commits since the last revision: - @sspitsyn comment -- fixed typo - Merge branch 'master' into 8367719-refactor-jni-code-that-uses-class_to_verify_considering_redefinition - @coleenp and @dholmes-ora comments -- simplify implementation; fixed code formatting - Merge branch 'master' into 8367719-refactor-jni-code-that-uses-class_to_verify_considering_redefinition - 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27303/files - new: https://git.openjdk.org/jdk/pull/27303/files/2504e1a6..aeec713a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27303&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27303&range=01-02 Stats: 5977 lines in 131 files changed: 4735 ins; 1009 del; 233 mod Patch: https://git.openjdk.org/jdk/pull/27303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27303/head:pull/27303 PR: https://git.openjdk.org/jdk/pull/27303 From iklam at openjdk.org Sat Sep 20 06:43:02 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 20 Sep 2025 06:43:02 GMT Subject: RFR: 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition() [v2] In-Reply-To: References: Message-ID: On Sat, 20 Sep 2025 05:54:38 GMT, Serguei Spitsyn wrote: >> Ioi Lam 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 three additional commits since the last revision: >> >> - @coleenp and @dholmes-ora comments -- simplify implementation; fixed code formatting >> - Merge branch 'master' into 8367719-refactor-jni-code-that-uses-class_to_verify_considering_redefinition >> - 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition() > > src/hotspot/share/prims/jvm.cpp line 2259: > >> 2257: // get_klass_considering_redefinition(), or >> 2258: // get_instance_klass_considering_redefinition() >> 2259: // These function return JvmtiThreadState::_scratch_class if the verifier > > Nit: Replaces: `These function` => `These functions` Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27303#discussion_r2365353625 From stuefe at openjdk.org Sat Sep 20 07:30:48 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 20 Sep 2025 07:30:48 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports Message-ID: On Linux, ASAN only shows some internal thread designation on reports, e.g. `T49`, which is useless. This patch adds the ability to see the real internal JVM thread names or user-supplied Java thread names in ASAN. This makes it possible to correlate ASAN reports with hs-err file reports (if ASAN is run with `halt_on_error=0` to give us a chance to get an hs-err file) or with a thread dump done beforehand. Note that it can only show up to 15 characters, though. Therefore, the patch tries to be smart about names that end in digits: such numbers are preserved such that the truncation happens in the middle of the name, e.g.: `"MyAllocationWorkerThread#4411"` -> `"MyAllocat..4411"` This latter improvement now also applies to thread names in gdb, since they are subject to the same limitation. ----- Some examples from ASAN report: Before: WRITE of size 8 at 0x7b749d2d9190 thread T49 Now: WRITE of size 8 at 0x7bfc2f0d8380 thread T49 (MyThread#0) ==593899==ERROR: AddressSanitizer: attempting free .. in thread T76 (MyAllocati..29) ------------- Commit messages: - fix comments - remove comment duplicates - factor out string utility; provide tests - be smart about thread names with numbers - start Changes: https://git.openjdk.org/jdk/pull/27395/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27395&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368124 Stats: 116 lines in 4 files changed: 112 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27395.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27395/head:pull/27395 PR: https://git.openjdk.org/jdk/pull/27395 From stuefe at openjdk.org Sat Sep 20 07:52:58 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 20 Sep 2025 07:52:58 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v2] In-Reply-To: References: Message-ID: > On Linux, ASAN only shows some internal thread designation on reports, e.g. `T49`, which is useless. > > This patch adds the ability to see the real internal JVM thread names or user-supplied Java thread names in ASAN. This makes it possible to correlate ASAN reports with hs-err file reports (if ASAN is run with `halt_on_error=0` to give us a chance to get an hs-err file) or with a thread dump done beforehand. > > Note that it can only show up to 15 characters, though. Therefore, the patch tries to be smart about names that end in digits: such numbers are preserved such that the truncation happens in the middle of the name, e.g.: > > `"MyAllocationWorkerThread#4411"` -> `"MyAllocat..4411"` > > This latter improvement now also applies to thread names in gdb, since they are subject to the same limitation. > > ----- > > Some examples from ASAN report: > > Before: > > WRITE of size 8 at 0x7b749d2d9190 thread T49 > > > Now: > > WRITE of size 8 at 0x7bfc2f0d8380 thread T49 (MyThread#0) > > > > ==593899==ERROR: AddressSanitizer: attempting free .. in thread T76 (MyAllocati..29) Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: windows build error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27395/files - new: https://git.openjdk.org/jdk/pull/27395/files/5c719128..68244fc0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27395&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27395&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27395.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27395/head:pull/27395 PR: https://git.openjdk.org/jdk/pull/27395 From syan at openjdk.org Sat Sep 20 14:35:15 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 20 Sep 2025 14:35:15 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v2] In-Reply-To: References: Message-ID: On Sat, 20 Sep 2025 07:52:58 GMT, Thomas Stuefe wrote: >> On Linux, ASAN only shows some internal thread designation on reports, e.g. `T49`, which is useless. >> >> This patch adds the ability to see the real internal JVM thread names or user-supplied Java thread names in ASAN. This makes it possible to correlate ASAN reports with hs-err file reports (if ASAN is run with `halt_on_error=0` to give us a chance to get an hs-err file) or with a thread dump done beforehand. >> >> Note that it can only show up to 15 characters, though. Therefore, the patch tries to be smart about names that end in digits: such numbers are preserved such that the truncation happens in the middle of the name, e.g.: >> >> `"MyAllocationWorkerThread#4411"` -> `"MyAllocat..4411"` >> >> This latter improvement now also applies to thread names in gdb, since they are subject to the same limitation. >> >> ----- >> >> Some examples from ASAN report: >> >> Before: >> >> WRITE of size 8 at 0x7b749d2d9190 thread T49 >> >> >> Now: >> >> WRITE of size 8 at 0x7bfc2f0d8380 thread T49 (MyThread#0) >> >> >> >> ==593899==ERROR: AddressSanitizer: attempting free .. in thread T76 (MyAllocati..29) > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > windows build error Should we update the copyright year for src/hotspot/share/utilities/stringUtils.hpp ------------- PR Comment: https://git.openjdk.org/jdk/pull/27395#issuecomment-3315005950 From coleenp at openjdk.org Sat Sep 20 14:36:17 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Sat, 20 Sep 2025 14:36:17 GMT Subject: RFR: 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition() [v3] In-Reply-To: <2aaupl63WuQcMIaF_FtAudQrlhGo_fqJeF_9on4Jyz0=.0475b16d-6d9a-47e8-ad01-a091c8924398@github.com> References: <2aaupl63WuQcMIaF_FtAudQrlhGo_fqJeF_9on4Jyz0=.0475b16d-6d9a-47e8-ad01-a091c8924398@github.com> Message-ID: <3dQlxiAERWNIVA2WmoGCA6-UKilgMpDtnMLtwsEU8Tg=.34328b04-e918-49e6-bff9-88743d0ebcf9@github.com> On Sat, 20 Sep 2025 06:43:00 GMT, Ioi Lam wrote: >> Simplify the boilerplate code in jvm.cpp that calls `JvmtiThreadState::class_to_verify_considering_redefinition()`, and reduce the number of `InstanceKlass::cast()` calls. >> >> I also changed a few fields/arguments from `Klass*` to `InstanceKlass*` as these are used exclusively with `InstanceKlass*`. > > Ioi Lam 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 five additional commits since the last revision: > > - @sspitsyn comment -- fixed typo > - Merge branch 'master' into 8367719-refactor-jni-code-that-uses-class_to_verify_considering_redefinition > - @coleenp and @dholmes-ora comments -- simplify implementation; fixed code formatting > - Merge branch 'master' into 8367719-refactor-jni-code-that-uses-class_to_verify_considering_redefinition > - 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition() Marked as reviewed by coleenp (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27303#pullrequestreview-3249059326 From kvn at openjdk.org Sat Sep 20 15:16:14 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 20 Sep 2025 15:16:14 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry [v3] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 21:45:16 GMT, Ashutosh Mehra wrote: >> This PR removes the need to store entry point addresses in AdapterHandlerEntry by storing a direct pointer to AdapterBlob instead. Entry point addresses can be computed on the fly from the entry point offsets stored in AdapterBlob. > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Add missing ResourceMark > > Signed-off-by: Ashutosh Mehra My new testing passed. You need second review. @adinn please look. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27101#pullrequestreview-3249089230 PR Comment: https://git.openjdk.org/jdk/pull/27101#issuecomment-3315043798 From jwaters at openjdk.org Sat Sep 20 16:28:17 2025 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 20 Sep 2025 16:28:17 GMT Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2] In-Reply-To: References: Message-ID: <-TQ8gJfoLtBxR5Xwb2cxl0Eg46xdkE1O_MzwSBlIWHU=.447120d3-b162-46f0-8679-65c9bc959032@github.com> On Tue, 17 Dec 2024 14:54:03 GMT, Julian Waters wrote: >> This is a general cleanup and improvement of LTO, as well as a quick fix to remove a workaround in the Makefiles that disabled LTO for g1ParScanThreadState.cpp due to the old poisoning mechanism causing trouble. The -Wno-attribute-warning change here can be removed once Kim's new poisoning solution is integrated. >> >> - -fno-omit-frame-pointer is added to gcc to stop the linker from emitting code without the frame pointer >> - -flto is set to $(JOBS) instead of auto to better match what the user requested >> - -Gy is passed to the Microsoft compiler. This does not fully fix LTO under Microsoft, but prevents warnings about -LTCG:INCREMENTAL at least > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: > > - Merge branch 'openjdk:master' into patch-16 > - -fno-omit-frame-pointer in JvmFeatures.gmk > - Revert compilerWarnings_gcc.hpp > - General LTO fixes JvmFeatures.gmk > - Revert DISABLE_POISONING_STOPGAP compilerWarnings_gcc.hpp > - Merge branch 'openjdk:master' into patch-16 > - Revert os.cpp > - Fix memory leak in jvmciEnv.cpp > - Stopgap fix in os.cpp > - Declaration fix in compilerWarnings_gcc.hpp > - ... and 2 more: https://git.openjdk.org/jdk/compare/668267cb...9d05cb8e Please give me more time, the flatten issue on my end is still causing problems ------------- PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3315086813 From iklam at openjdk.org Sat Sep 20 17:28:21 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 20 Sep 2025 17:28:21 GMT Subject: RFR: 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition() [v2] In-Reply-To: References: Message-ID: <_uDtUDGwRSizq-t31RNtjZPO-fid74m9015wvtjD58U=.de4de404-587b-48c8-9514-38dbb74616aa@github.com> On Sat, 20 Sep 2025 05:55:06 GMT, Serguei Spitsyn wrote: >> Ioi Lam 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 three additional commits since the last revision: >> >> - @coleenp and @dholmes-ora comments -- simplify implementation; fixed code formatting >> - Merge branch 'master' into 8367719-refactor-jni-code-that-uses-class_to_verify_considering_redefinition >> - 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition() > > Nice refactoring! Looks good. Thanks @sspitsyn @coleenp @dholmes-ora for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/27303#issuecomment-3315123837 From iklam at openjdk.org Sat Sep 20 17:31:29 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 20 Sep 2025 17:31:29 GMT Subject: Integrated: 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition() In-Reply-To: References: Message-ID: On Tue, 16 Sep 2025 02:44:26 GMT, Ioi Lam wrote: > Simplify the boilerplate code in jvm.cpp that calls `JvmtiThreadState::class_to_verify_considering_redefinition()`, and reduce the number of `InstanceKlass::cast()` calls. > > I also changed a few fields/arguments from `Klass*` to `InstanceKlass*` as these are used exclusively with `InstanceKlass*`. This pull request has now been integrated. Changeset: cc65836d Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/cc65836d00de7041e7d32e7f15d98108b1ae47a0 Stats: 126 lines in 3 files changed: 16 ins; 33 del; 77 mod 8367719: Refactor JNI code that uses class_to_verify_considering_redefinition() Reviewed-by: coleenp, dholmes, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/27303 From lmesnik at openjdk.org Sat Sep 20 17:35:20 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 20 Sep 2025 17:35:20 GMT Subject: RFR: 8368159: Significant performance overhead when started with jdwp agent and unattached debugger [v2] In-Reply-To: References: Message-ID: On Sat, 20 Sep 2025 05:10:50 GMT, Serguei Spitsyn wrote: >> This update removes a significant performance overhead when an application running millions of virtual threads is started with the JDWP agent but debugger has not been attached. The overhead is 4X-6X slowdown. >> The tested app normally (without debug agent) takes around 3+ seconds. With debug agent enabled it takes 14 seconds and more. The performance overhead is caused by the `jvmti_yield_cleanup()` recursively calling `JvmtiExport::continuation_yield_cleanup()`. The reason of this overhead is because the function `JvmtiExport::can_post_frame_pop()` is used to identify a need for the JVMTI cleanup which is not precise and triggers unneeded work when debugger has not been attached yet. The fix is to trigger the JVMTI cleanup with new function: `bool JvmtiExport::has_frame_pops(JavaThread* thread)`. >> >> Testing: >> - Insure the 4X-6X slowdown is gone for an application running millions of virtual threads and started with JDWP agent >> - Mach5 tiers 1-6 are all passed > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > fix minimal build broken by incorrect macro usage src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1622: > 1620: > 1621: static void invalidate_jvmti_stack(JavaThread* thread) { > 1622: if (JvmtiExport::can_post_frame_pop() || thread->is_interp_only_mode()) { Can you please explain why this change is required? Doesn't 'invalidate_cur_stack_depth' make sense only when interp_only mode is enabled for the threads only? It is invalidated once thread switched to interp only. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27403#discussion_r2365734395 From iklam at openjdk.org Sun Sep 21 00:16:16 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sun, 21 Sep 2025 00:16:16 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v4] In-Reply-To: References: Message-ID: On Sat, 20 Sep 2025 01:23:25 GMT, Ioi Lam wrote: > > @iklam Reading up the description of the bug tracker, it seems we are trying to find out more opportunities to AOT initialize classes than the current state. Is that correct? I may be missing something here, why not "force initialize" classes annotated with `AOTSafeClassInitializer` in `AOTMetaspace::try_link_class`, instead of introducing new annotation? Wouldn't that serve the same purpose? And I think we also need to track the classes that are actually initialized in the training phase, and apply "force initialization" only on that subset. Otherwise we can end up in situation where a classes is loaded and not initialized in training phase, but still gets AOT initialized because it is annotated with `AOTInitialize`. > > I think this is a better alternative. I will fix the implementation to do what you described (by tracking the set of initialized classes in finalImageRecipes..cpp). > > To avoid confusion, I will post a separate PR. I have created an alternative PR. https://github.com/openjdk/jdk/pull/27402. @adinn @ashu-mehra @liach please take a look. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27024#issuecomment-3315384179 From wenanjian at openjdk.org Sun Sep 21 00:50:18 2025 From: wenanjian at openjdk.org (Anjian Wen) Date: Sun, 21 Sep 2025 00:50:18 GMT Subject: RFR: 8365732: RISC-V: implement AES CTR intrinsics [v7] In-Reply-To: References: Message-ID: <6-c0fA19VDBsLUwN2ewcYQ_bPSD7Zt6h5lsIOhTMGpk=.80f0aca5-601b-48dd-9c0e-c79612976da9@github.com> On Fri, 19 Sep 2025 07:09:27 GMT, Fei Yang wrote: >> Anjian Wen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into aes_ctr >> - fix the counter increase at limit and add test >> - change format >> - update reg use and instruction >> - change some name and format >> - delete useless Label, change L_judge_used to L_slow_loop >> - add Flags and fix the stubid name >> - RISC-V: implement AES-CTR mode intrinsics > > src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 2667: > >> 2665: __ addi(t0, counter, 8); >> 2666: __ ld(tmp, Address(t0)); >> 2667: __ rev8(tmp, tmp); > > Note that `rev8` is only available under `UseZbb`. Maybe you should use `revb/revbw` instead which considers that the availability of Zbb extension. I used the zbb and zvbb instructions in my patch?which seem not easy to replace in vector operations, and there are some optimizations when using them, so I think we may add a extension check in vm_version_riscv.cpp? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25281#discussion_r2365883933 From wenanjian at openjdk.org Sun Sep 21 00:57:40 2025 From: wenanjian at openjdk.org (Anjian Wen) Date: Sun, 21 Sep 2025 00:57:40 GMT Subject: RFR: 8365732: RISC-V: implement AES CTR intrinsics [v9] In-Reply-To: References: Message-ID: > Hi everyone, please help review this patch which Implement the _counterMode_AESCrypt with Zvkned. On my QEMU, with Zvkned extension enabled, the tests in test/hotspot/jtreg/compiler/codegen/aes/ Passed. Anjian Wen has updated the pull request incrementally with one additional commit since the last revision: add zbb and zvbb check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25281/files - new: https://git.openjdk.org/jdk/pull/25281/files/35f82e0a..529f7cf8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25281&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25281&range=07-08 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25281.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25281/head:pull/25281 PR: https://git.openjdk.org/jdk/pull/25281 From duke at openjdk.org Sun Sep 21 04:10:23 2025 From: duke at openjdk.org (Yuri Gaevsky) Date: Sun, 21 Sep 2025 04:10:23 GMT Subject: RFR: 8324124: RISC-V: implement _vectorizedMismatch intrinsic [v6] In-Reply-To: <9ciX8uRwGiW2rzmWjA6rAEHTaY1qjXR5VaImXs7JBqg=.376697c6-0eb8-4ed8-903e-96e75c6c4a32@github.com> References: <9ciX8uRwGiW2rzmWjA6rAEHTaY1qjXR5VaImXs7JBqg=.376697c6-0eb8-4ed8-903e-96e75c6c4a32@github.com> Message-ID: <4tjveS0vc8-VgiNjwbOUk3tO_M9OlDHYr43FZJ3Rdmk=.97aa6aab-2999-4ce5-bd99-6140e2fe14f6@github.com> On Tue, 12 Aug 2025 19:54:14 GMT, Yuri Gaevsky wrote: >> Hello All, >> >> Please review these changes to enable the __vectorizedMismatch_ intrinsic on RISC-V platform with RVV instructions supported. >> >> Thank you, >> -Yuri Gaevsky >> >> **Correctness checks:** >> hotspot/jtreg/compiler/{intrinsic/c1/c2}/ under QEMU-8.1 with RVV v1.0.0 and -XX:TieredStopAtLevel=1/2/3/4. > > Yuri Gaevsky has updated the pull request incrementally with one additional commit since the last revision: > > removed unneeded check for zero length; changed lmul from m8 to m2. . ------------- PR Comment: https://git.openjdk.org/jdk/pull/17750#issuecomment-3315484133 From iwalulya at openjdk.org Mon Sep 22 05:56:58 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 22 Sep 2025 05:56:58 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v9] In-Reply-To: References: Message-ID: > Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. > > Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. > > Testing: Tier 1-7 Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - Remove lock - remove assert - make universal - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs - Revert - Thomas Review - return on timeout - ... and 8 more: https://git.openjdk.org/jdk/compare/cc65836d...87c80194 ------------- Changes: https://git.openjdk.org/jdk/pull/27190/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=08 Stats: 98 lines in 15 files changed: 71 ins; 20 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27190.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27190/head:pull/27190 PR: https://git.openjdk.org/jdk/pull/27190 From iwalulya at openjdk.org Mon Sep 22 05:56:59 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 22 Sep 2025 05:56:59 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v8] In-Reply-To: <2zZ0C8QMjO3VjsicHXhLbNuy1d_Vg9HsmltsW5BU1kY=.95ac00a0-d202-4ae3-9ae3-7568bd9e6d1d@github.com> References: <2zZ0C8QMjO3VjsicHXhLbNuy1d_Vg9HsmltsW5BU1kY=.95ac00a0-d202-4ae3-9ae3-7568bd9e6d1d@github.com> Message-ID: On Fri, 19 Sep 2025 10:01:43 GMT, Albert Mingkun Yang wrote: >> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: >> >> remove assert > > src/hotspot/share/gc/shared/collectedHeap.cpp line 626: > >> 624: // triggers a GC. >> 625: MonitorLocker ml(VMExit_lock); >> 626: ml.wait(2 * MILLIUNITS); > > I think one can use `ThreadBlockInVM` + sleep to achieve the blocking-current-thread purpose. Then, there is no need for a new lock, as there is no critical-region anyway. Changed to just using sleep. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2366793152 From aboldtch at openjdk.org Mon Sep 22 06:06:31 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 22 Sep 2025 06:06:31 GMT Subject: RFR: 8368214: ZGC: Remove double newlines Message-ID: We avoid having two empty newlines in a row. But we have a hand full. Trivial change to remove them. ------------- Commit messages: - 8368214: ZGC: Remove double newlines Changes: https://git.openjdk.org/jdk/pull/27417/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27417&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368214 Stats: 18 lines in 14 files changed: 0 ins; 18 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27417.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27417/head:pull/27417 PR: https://git.openjdk.org/jdk/pull/27417 From dholmes at openjdk.org Mon Sep 22 06:13:15 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 22 Sep 2025 06:13:15 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v2] In-Reply-To: References: Message-ID: On Sat, 20 Sep 2025 07:52:58 GMT, Thomas Stuefe wrote: >> On Linux, ASAN only shows some internal thread designation on reports, e.g. `T49`, which is useless. >> >> This patch adds the ability to see the real internal JVM thread names or user-supplied Java thread names in ASAN. This makes it possible to correlate ASAN reports with hs-err file reports (if ASAN is run with `halt_on_error=0` to give us a chance to get an hs-err file) or with a thread dump done beforehand. >> >> Note that it can only show up to 15 characters, though. Therefore, the patch tries to be smart about names that end in digits: such numbers are preserved such that the truncation happens in the middle of the name, e.g.: >> >> `"MyAllocationWorkerThread#4411"` -> `"MyAllocat..4411"` >> >> This latter improvement now also applies to thread names in gdb, since they are subject to the same limitation. >> >> ----- >> >> Some examples from ASAN report: >> >> Before: >> >> WRITE of size 8 at 0x7b749d2d9190 thread T49 >> >> >> Now: >> >> WRITE of size 8 at 0x7bfc2f0d8380 thread T49 (MyThread#0) >> >> >> >> ==593899==ERROR: AddressSanitizer: attempting free .. in thread T76 (MyAllocati..29) > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > windows build error src/hotspot/os/linux/os_linux.cpp line 4867: > 4865: StringUtils::abbreviate_preserve_trailing_number(name, buf, sizeof(buf)); > 4866: // set name in kernel > 4867: int rc = prctl(PR_SET_NAME, buf); So really this little part is the actual crux of this PR - the thing that makes the name appear to ASAN. But why do we have to do this for ASAN and not gdb for example? According to the doc: > PR_SET_NAME (since Linux 2.6.9) Set the name of the calling thread, using the value in the location pointed to by (char *) arg2. The name can be up to 16 bytes long, including the terminating null byte. (If the length of the string, including the terminating null byte, exceeds 16 bytes, the string is silently truncated.) This is the same attribute that can be set via pthread_setname_np(3) and retrieved using pthread_getname_np(3). The attribute is likewise accessible via /proc/self/task/tid/comm (see proc(5)), where tid is the thread ID of the calling thread, as returned by get? tid(2). So as we already use `pthread_setname_np` why is this not sufficient for ASAN? And given both of these API's claim to write the name to the same place in /proc why would we now do it twice?? FWIW I think your truncation approach is over-engineered given the type of names it will actually be useful for. Why not simply print the first and last 6 chars with `...` between them? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27395#discussion_r2366818128 From dholmes at openjdk.org Mon Sep 22 06:18:14 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 22 Sep 2025 06:18:14 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v2] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 06:10:37 GMT, David Holmes wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> windows build error > > src/hotspot/os/linux/os_linux.cpp line 4867: > >> 4865: StringUtils::abbreviate_preserve_trailing_number(name, buf, sizeof(buf)); >> 4866: // set name in kernel >> 4867: int rc = prctl(PR_SET_NAME, buf); > > So really this little part is the actual crux of this PR - the thing that makes the name appear to ASAN. But why do we have to do this for ASAN and not gdb for example? According to the doc: >> PR_SET_NAME (since Linux 2.6.9) > Set the name of the calling thread, using the value in the location pointed to by (char *) arg2. The name can be > up to 16 bytes long, including the terminating null byte. (If the length of the string, including the terminating > null byte, exceeds 16 bytes, the string is silently truncated.) This is the same attribute that can be set via > pthread_setname_np(3) and retrieved using pthread_getname_np(3). The attribute is likewise accessible via > /proc/self/task/tid/comm (see proc(5)), where tid is the thread ID of the calling thread, as returned by get? > tid(2). > > So as we already use `pthread_setname_np` why is this not sufficient for ASAN? And given both of these API's claim to write the name to the same place in /proc why would we now do it twice?? > > FWIW I think your truncation approach is over-engineered given the type of names it will actually be useful for. Why not simply print the first and last 6 chars with `...` between them? I see now in JBS that you say you don't know why what we have doesn't work for ASAN, but I think we need to determine that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27395#discussion_r2366825196 From aboldtch at openjdk.org Mon Sep 22 06:26:13 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 22 Sep 2025 06:26:13 GMT Subject: RFR: 8367972: ZGC: Reduce ZBarrierSet includes In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 11:48:30 GMT, Francesco Andreuzzi wrote: > Hi @xmas92, some more data about this change. Thanks for checking @fandreuz. Seems like a nice improvement. But it is unclear to me where we draw the line for inclusion in precompiled headers. Looking at that data we see that we reduced the number of times we include these files by 95% but also increased the average time we spent per inclusion by ~700%. Meaning that before the includes resulted in very little extra job for most compilation units (but still added up). But now most includes actually make use of the files and require more time. I believe @stefank has mentioned to me at some point the ability to have precompiled headers on a per directory basis. Because it looks like none of the gc/z includes really qualify for being in the `precompiled.hpp` file, but may belong in a hypothetical `gc/z/precompiled.hpp` file. I say this as someone that almost always configure my local builds without precompiled headers and have limited knowledge and experience of when they are beneficial. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27386#issuecomment-3317120303 From ayang at openjdk.org Mon Sep 22 07:18:58 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 22 Sep 2025 07:18:58 GMT Subject: RFR: 8368072: Remove redundant arguments of MarkingNMethodClosure [v3] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 08:34:37 GMT, Albert Mingkun Yang wrote: >> "Inline" statically known value to callee to simplify `MarkingNMethodClosure`. >> >> Test: tier1 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27382#issuecomment-3317298325 From mhaessig at openjdk.org Mon Sep 22 07:19:00 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Mon, 22 Sep 2025 07:19:00 GMT Subject: RFR: 8367862: debug.cpp: Do not print help message for methods ifdef'd out [v2] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 10:37:18 GMT, Kerem Kat wrote: >> The `help` command in `debug.cpp` was out of date, listing only a fraction of the available functions. This and other commands callable from gdb via `call help()`. >> >> I added all commands to the help message, except `pns2` as it is documented as not being useful when called from gdb. >> >> Also fixed is the message for the conditional `pns` command appearing in PRODUCT builds. > > Kerem Kat has updated the pull request incrementally with one additional commit since the last revision: > > address comments Thank you for addressing my comments, @krk. You missed one "s" (see below), otherwise this looks good to me. src/hotspot/share/utilities/debug.cpp line 687: > 685: tty->print_cr("method metadata."); > 686: tty->print_cr(" blob(CodeBlob* p) - print CodeBlob"); > 687: tty->print_cr(" dump_vtable(address p) - dumps vtable of the Klass"); Suggestion: tty->print_cr(" dump_vtable(address p) - dump vtable of the Klass"); ------------- Marked as reviewed by mhaessig (Committer). PR Review: https://git.openjdk.org/jdk/pull/27341#pullrequestreview-3250904144 PR Review Comment: https://git.openjdk.org/jdk/pull/27341#discussion_r2366937608 From jsjolen at openjdk.org Mon Sep 22 07:19:40 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 22 Sep 2025 07:19:40 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v6] In-Reply-To: References: Message-ID: <_-rP9r52cIQ72jHM6FkynToLo0rZ7S4CUmlNvCoEvTU=.32262b01-b691-4863-9d87-db142ddcf92f@github.com> > Hi, > > This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array` to store the offsets in and an `Array` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`. > > We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately. > > For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc. > > On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement. > > Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Apply suggestions from code review Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27198/files - new: https://git.openjdk.org/jdk/pull/27198/files/6f47508b..0f60034c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=04-05 Stats: 11 lines in 4 files changed: 2 ins; 2 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27198/head:pull/27198 PR: https://git.openjdk.org/jdk/pull/27198 From ayang at openjdk.org Mon Sep 22 07:23:55 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 22 Sep 2025 07:23:55 GMT Subject: Integrated: 8368072: Remove redundant arguments of MarkingNMethodClosure In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 07:47:45 GMT, Albert Mingkun Yang wrote: > "Inline" statically known value to callee to simplify `MarkingNMethodClosure`. > > Test: tier1 This pull request has now been integrated. Changeset: f10fbe1f Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/f10fbe1fb40645633b91fad2af3d7c2cbb005b39 Stats: 23 lines in 6 files changed: 0 ins; 12 del; 11 mod 8368072: Remove redundant arguments of MarkingNMethodClosure Reviewed-by: stefank, fandreuzzi ------------- PR: https://git.openjdk.org/jdk/pull/27382 From stefank at openjdk.org Mon Sep 22 07:24:46 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 22 Sep 2025 07:24:46 GMT Subject: RFR: 8368214: ZGC: Remove double newlines In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 05:59:47 GMT, Axel Boldt-Christmas wrote: > We avoid having two empty newlines in a row. But we have a hand full. Trivial change to remove them. Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27417#pullrequestreview-3250925180 From fyang at openjdk.org Mon Sep 22 07:25:55 2025 From: fyang at openjdk.org (Fei Yang) Date: Mon, 22 Sep 2025 07:25:55 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v4] In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 08:18:24 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> >> Currently, the cpu features of riscv are stored in separate RVFeature subclasses. >> But to support the store/restore CPU features for aot in the future, we need to store the cpu features in a continuous memory. >> As the riscv extensions are introduced continuously, I think it's better to do it via an simple bitmap at the beginning. >> Currently, just suppose the non-extension features will not be stored in aot image, so I also split the extension and non-extenion features. When we implement the related aot feature in the short future, we can revisit the way of splitting the features. Currently, just change the storage way of cpu features, lay the foundation for future aot. >> >> Thanks > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > fix typo Thanks for the update. Several minor comments remain. src/hotspot/cpu/riscv/vm_version_riscv.hpp line 238: > 236: decl(ext_Zvfh , Zvfh , RV_NO_FLAG_BIT, 30, true , UPDATE_DEFAULT_DEP(UseZvfh, ext_V)) \ > 237: decl(ext_Zvkn , Zvkn , RV_NO_FLAG_BIT, 31, true , UPDATE_DEFAULT_DEP(UseZvkn, ext_V)) \ > 238: decl(ext_Zicond , Zicond , RV_NO_FLAG_BIT, 32, true , UPDATE_DEFAULT(UseZicond)) \ I assume the `cpu feature index` field is not subject to change in the future when we have AOT support, right? Then I think the code will be cleaner if we group these features in aphabetic order before that. src/hotspot/cpu/riscv/vm_version_riscv.hpp line 298: > 296: } > 297: > 298: static int element_index(RVFeatureIndex feature) { For consistency in naming, should we further rename this into something like `features_bitmap_element_index`? src/hotspot/cpu/riscv/vm_version_riscv.hpp line 305: > 303: > 304: static uint64_t bit_mask(RVFeatureIndex feature) { > 305: return (1ULL << (feature & features_bitmap_element_mask())); The two functions `features_bitmap_element_mask` and `bit_mask` look very confusing to me. Is it better to factor out `features_bitmap_element_mask` and rename this `bit_mask` into something like `features_bitmap_element_bit_mask`? ------------- PR Review: https://git.openjdk.org/jdk/pull/27152#pullrequestreview-3250899495 PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2366944935 PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2366936409 PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2366934178 From mhaessig at openjdk.org Mon Sep 22 07:28:15 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Mon, 22 Sep 2025 07:28:15 GMT Subject: RFR: 8367611: Enable vblendvp[sd] on Future ECore [v2] In-Reply-To: References: <_Jk5fv1iO9ZPZyOtUAXeUez481RibKJR4FsUT_BnKm8=.2f68f9ee-9ce2-4dbb-be8b-1b9f910ba0e0@github.com> Message-ID: <2QodBQQIkP3GqBq1yUDqVS1a8EaYkN1FMTkuNHyKUcs=.1cc28add-901c-4731-a2de-0adaa768c54e@github.com> On Fri, 19 Sep 2025 06:51:50 GMT, Manuel H?ssig wrote: >> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: >> >> Use function to identify Darkmont cores instead of global flag > > Thank you for this improvement, @missa-prime! The change looks good to me, but I have a question. > >> The JTREG test shown below was used to verify correctness against the [OpenJDK v26-b15](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B15) baseline build. >> - jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java > > Can you elaborate, what this verification entails? Why this test? > @mhaessig I used this test because it frequently calls vblendvps() and vblendvpd() in the macro assembler. On Darkmont and non-Darkmont cores, I checked the right code paths were followed with asserts. Also, I wrote some sample code and checked the instructions generated at runtime. Did you also run a some tests generating vblendvps with sde to verify the correct result with the new code paths? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27354#issuecomment-3317327037 From stefank at openjdk.org Mon Sep 22 07:33:08 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 22 Sep 2025 07:33:08 GMT Subject: RFR: 8367989: Remove InstanceKlass::allocate_objArray and ArrayKlass::allocate_arrayArray [v3] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 13:18:09 GMT, Coleen Phillimore wrote: >> This change removes InstanceKlass::allocate_objArray and has its caller call ObjArrayKlass::allocate_instance directly from oopFactory, like the other array allocations do. See CR for more information why we should have this change. I also removed element_klass_addr() and moved element_klass_offset() to be in a more logical place near element_klass() functions. This upstreams a tiny valhalla diff. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Use virtual function rather than if statement, still need one cast though. This looks good to me. Please test this thoroughly given the complexity inside the called functions. ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27372#pullrequestreview-3250956254 From dholmes at openjdk.org Mon Sep 22 07:58:59 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 22 Sep 2025 07:58:59 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v9] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 05:56:58 GMT, Ivan Walulya wrote: >> Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. >> >> Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. >> >> Testing: Tier 1-7 > > Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - Remove lock > - remove assert > - make universal > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - Revert > - Thomas Review > - return on timeout > - ... and 8 more: https://git.openjdk.org/jdk/compare/cc65836d...87c80194 src/hotspot/share/gc/shared/collectedHeap.cpp line 625: > 623: // - short enough to avoid excessive stall time if the shutdown itself > 624: // triggers a GC. > 625: JavaThread::current()->sleep(2 * MILLIUNITS); I prefer this to the Monitor::wait too. Thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2367032872 From jsjolen at openjdk.org Mon Sep 22 08:02:57 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 22 Sep 2025 08:02:57 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7] In-Reply-To: References: Message-ID: > Hi, > > This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array` to store the offsets in and an `Array` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`. > > We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately. > > For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc. > > On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement. > > Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again. Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision: - Merge remote-tracking branch 'origin/operands-again' into operands-again - Fix BSM naming ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27198/files - new: https://git.openjdk.org/jdk/pull/27198/files/0f60034c..d8624f09 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=05-06 Stats: 33 lines in 3 files changed: 0 ins; 0 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/27198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27198/head:pull/27198 PR: https://git.openjdk.org/jdk/pull/27198 From jsjolen at openjdk.org Mon Sep 22 08:03:00 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 22 Sep 2025 08:03:00 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v5] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 16:30:01 GMT, Coleen Phillimore wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix rename > > You might want @sspitsyn to review the jvmtiRedefineClasses changes since he did this work for the existing operands arrays. @coleenp, I can move the new classes to its own file, but let's wait until all other reviewing is done (makes it less confusing). Thanks David for finding all of the style issues. I had a go at removing any mention of 'operands' in the sense of "the BSM attribute of a constant pool". ------------- PR Comment: https://git.openjdk.org/jdk/pull/27198#issuecomment-3317438712 From mli at openjdk.org Mon Sep 22 08:32:09 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 22 Sep 2025 08:32:09 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v4] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 07:17:58 GMT, Fei Yang wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> fix typo > > src/hotspot/cpu/riscv/vm_version_riscv.hpp line 238: > >> 236: decl(ext_Zvfh , Zvfh , RV_NO_FLAG_BIT, 30, true , UPDATE_DEFAULT_DEP(UseZvfh, ext_V)) \ >> 237: decl(ext_Zvkn , Zvkn , RV_NO_FLAG_BIT, 31, true , UPDATE_DEFAULT_DEP(UseZvkn, ext_V)) \ >> 238: decl(ext_Zicond , Zicond , RV_NO_FLAG_BIT, 32, true , UPDATE_DEFAULT(UseZicond)) \ > > I assume the `cpu feature index` field is not subject to change in the future when we have AOT support, right? Then I think the code will be cleaner if we group these features in aphabetic order before that. There is dependency between some extensions, which enforce some order not subject to this constraint. So, not sure if it's an good idea to force the aphabetic order, especailly in this pr. If you think it's necessary to do so, I can do it in another separate pr, and I hope to do it after https://github.com/openjdk/jdk/pull/27171. > src/hotspot/cpu/riscv/vm_version_riscv.hpp line 298: > >> 296: } >> 297: >> 298: static int element_index(RVFeatureIndex feature) { > > For consistency in naming, should we further rename this into something like `features_bitmap_element_index`? Seems the too long name is not helpful, especially all the methods got the same prefix. Maybe it's better to shorten all the names without the prefix, anyway they are all simple methods and private ones. How do you think about it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2367109820 PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2367108257 From alanb at openjdk.org Mon Sep 22 08:41:39 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 22 Sep 2025 08:41:39 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final Message-ID: Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500). Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP. HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX). There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package. Testing: tier1-6 ------------- Commit messages: - Merge branch 'master' into JDK-8353835 - Test cleanup - More improvements - Update for jtreg 8 - Merge branch 'master' into JDK-8353835 - Cleanup - Merge branch 'master' into JDK-8353835 - TestDefaultConfigurations failing - Test failures - Merge branch 'master' into JDK-8353835 - ... and 6 more: https://git.openjdk.org/jdk/compare/682fd784...bfad2bbe Changes: https://git.openjdk.org/jdk/pull/25115/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25115&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353835 Stats: 4547 lines in 61 files changed: 4387 ins; 43 del; 117 mod Patch: https://git.openjdk.org/jdk/pull/25115.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25115/head:pull/25115 PR: https://git.openjdk.org/jdk/pull/25115 From liach at openjdk.org Mon Sep 22 08:41:40 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 22 Sep 2025 08:41:40 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final In-Reply-To: References: Message-ID: On Thu, 8 May 2025 11:22:30 GMT, Alan Bateman wrote: > Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500). > > Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP. > > HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX). > > There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package. > > Testing: tier1-6 For such a draft pull request, is the rename from "ignore" to the actual issue title an indicator for starting a review for the overall design without concerns about typos or bikeshedding? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-2869958248 From alanb at openjdk.org Mon Sep 22 08:41:41 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 22 Sep 2025 08:41:41 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final In-Reply-To: References: Message-ID: On Sun, 11 May 2025 16:04:05 GMT, Chen Liang wrote: > For such a draft pull request, is the rename from "ignore" to the actual issue title an indicator for starting a review for the overall design without concerns about typos or bikeshedding? Skara adds the "rfr" label to PRs that are ready for review. Design questions are for the JEP, not the PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-2870006199 From swen at openjdk.org Mon Sep 22 08:41:42 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 22 Sep 2025 08:41:42 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final In-Reply-To: References: Message-ID: On Thu, 8 May 2025 11:22:30 GMT, Alan Bateman wrote: > Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500). > > Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP. > > HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX). > > There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package. > > Testing: tier1-6 src/java.base/share/classes/java/lang/reflect/Field.java line 887: > 885: if (isFinalInstanceInNormalClass() && obj != null) { > 886: checkAllowedToSetFinal(Reflection.getCallerClass()); > 887: } There are multiple duplicate codes here, or put them all in one method, like this @ForceInline private void checkAllowedToSetFinalIfFinalInstanceInNormalClass(Object obj) throws IllegalAccessException { if (Modifier.isFinal(modifiers) && !Modifier.isStatic(modifiers) && !clazz.isRecord() && !clazz.isHidden() && obj != null) { checkAllowedToSetFinal(Reflection.getCallerClass(), false); } } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2092083985 From tschatzl at openjdk.org Mon Sep 22 08:57:23 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 22 Sep 2025 08:57:23 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v62] In-Reply-To: References: Message-ID: <9QFGKuKT_g9DUQCDaZ3yMJv-SNXBULg_c5zVQxA3p5U=.9ad6d425-4168-46a2-9d9d-129690017725@github.com> > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 82 commits: - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * iwalulya review * documentation for a few PSS members * rename some member variables to contain _ct and _rt suffixes in remembered set verification - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * therealaph suggestion for avoiding the register aliasin in gen_write_ref_array_post - * walulyai review - * walulyai review * tried to remove "logged card" terminology for the current "pending card" one - * aph review, fix some comment - Merge branch 'master' into 8342382-card-table-instead-of-dcq - Merge branch 'master' into 8342382-card-table-instead-of-dcq - * iwalulya: remove confusing comment - ... and 72 more: https://git.openjdk.org/jdk/compare/5efaa997...b5d22d52 ------------- Changes: https://git.openjdk.org/jdk/pull/23739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=61 Stats: 7178 lines in 113 files changed: 2606 ins; 3588 del; 984 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From jsikstro at openjdk.org Mon Sep 22 08:58:23 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 22 Sep 2025 08:58:23 GMT Subject: RFR: 8368214: ZGC: Remove double newlines In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 05:59:47 GMT, Axel Boldt-Christmas wrote: > We avoid having two empty newlines in a row. But we have a hand full. Trivial change to remove them. Marked as reviewed by jsikstro (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27417#pullrequestreview-3251269236 From kevinw at openjdk.org Mon Sep 22 09:12:30 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 22 Sep 2025 09:12:30 GMT Subject: RFR: 8367862: debug.cpp: Do not print help message for methods ifdef'd out [v2] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 10:37:18 GMT, Kerem Kat wrote: >> The `help` command in `debug.cpp` was out of date, listing only a fraction of the available functions. This and other commands callable from gdb via `call help()`. >> >> I added all commands to the help message, except `pns2` as it is documented as not being useful when called from gdb. >> >> Also fixed is the message for the conditional `pns` command appearing in PRODUCT builds. > > Kerem Kat has updated the pull request incrementally with one additional commit since the last revision: > > address comments As was mentioned previously, users of these functions should understand they are pretty much on their own, no guarantees... But good to make it presentable where we can. ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27341#pullrequestreview-3251329180 From mli at openjdk.org Mon Sep 22 09:22:39 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 22 Sep 2025 09:22:39 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v5] In-Reply-To: References: Message-ID: > Hi, > Can you help to review this patch? > > Currently, the cpu features of riscv are stored in separate RVFeature subclasses. > But to support the store/restore CPU features for aot in the future, we need to store the cpu features in a continuous memory. > As the riscv extensions are introduced continuously, I think it's better to do it via an simple bitmap at the beginning. > Currently, just suppose the non-extension features will not be stored in aot image, so I also split the extension and non-extenion features. When we implement the related aot feature in the short future, we can revisit the way of splitting the features. Currently, just change the storage way of cpu features, lay the foundation for future aot. > > Thanks Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: simplify names ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27152/files - new: https://git.openjdk.org/jdk/pull/27152/files/6b33210c..eac955a1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27152&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27152&range=03-04 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/27152.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27152/head:pull/27152 PR: https://git.openjdk.org/jdk/pull/27152 From jbechberger at openjdk.org Mon Sep 22 09:29:05 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Mon, 22 Sep 2025 09:29:05 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing [v7] In-Reply-To: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> Message-ID: > This change hopefully fixes the test failures by making the test cases more resilient. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Make main assertion less strict ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27293/files - new: https://git.openjdk.org/jdk/pull/27293/files/d927a0dc..7c4697b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27293&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27293&range=05-06 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27293.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27293/head:pull/27293 PR: https://git.openjdk.org/jdk/pull/27293 From tschatzl at openjdk.org Mon Sep 22 09:31:58 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 22 Sep 2025 09:31:58 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v63] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * improved gen_write_ref_array_post_barrier() for riscv, contributed by @realfyang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/b5d22d52..53ef008a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=62 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=61-62 Stats: 24 lines in 1 file changed: 13 ins; 2 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From krk at openjdk.org Mon Sep 22 09:55:23 2025 From: krk at openjdk.org (Kerem Kat) Date: Mon, 22 Sep 2025 09:55:23 GMT Subject: RFR: 8367862: debug.cpp: Do not print help message for methods ifdef'd out [v3] In-Reply-To: References: Message-ID: > The `help` command in `debug.cpp` was out of date, listing only a fraction of the available functions. This and other commands callable from gdb via `call help()`. > > I added all commands to the help message, except `pns2` as it is documented as not being useful when called from gdb. > > Also fixed is the message for the conditional `pns` command appearing in PRODUCT builds. Kerem Kat has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/utilities/debug.cpp Co-authored-by: Manuel H?ssig ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27341/files - new: https://git.openjdk.org/jdk/pull/27341/files/6077d252..1cf2bf59 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27341&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27341&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27341.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27341/head:pull/27341 PR: https://git.openjdk.org/jdk/pull/27341 From adinn at openjdk.org Mon Sep 22 10:04:26 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 22 Sep 2025 10:04:26 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry [v3] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 21:45:16 GMT, Ashutosh Mehra wrote: >> This PR removes the need to store entry point addresses in AdapterHandlerEntry by storing a direct pointer to AdapterBlob instead. Entry point addresses can be computed on the fly from the entry point offsets stored in AdapterBlob. > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Add missing ResourceMark > > Signed-off-by: Ashutosh Mehra src/hotspot/share/code/codeBlob.cpp line 457: > 455: (entry_offset[i] == -1), > 456: "invalid entry offset[%d] = 0x%x", i, entry_offset[i]); > 457: } In the header the getters for the first 3 entries (i.e. entry_offset[I2C], entry_offset[C2I] and entry_offset[C2I_Unverified]) are all valid. So, we need to assert that as well as requiring the I2C entry being at offset 0. Suggestion: assert(entry_offset[I2C] == 0, "sanity check"); for (int i = 1; i < AdapterBlob::ENTRY_COUNT; i++) { // The entry is within the adapter blob or, in the case of the last one, unset. int offset = entry_offset[i]; assert((offset > 0 && offset < cb->insts()->size()) || (i >= C2I_No_Clinit_Check && offset == -1), "invalid entry offset[%d] = 0x%x", i, entry_offset[i]); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27101#discussion_r2367392909 From adinn at openjdk.org Mon Sep 22 10:12:04 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 22 Sep 2025 10:12:04 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry [v3] In-Reply-To: References: Message-ID: <1G62FqEtGv4PUVe4Cmuuf76ZztmhbEHeesSzjOioanc=.b5cfa387-10fe-4904-94ea-d8ed2fbb2d12@github.com> On Fri, 19 Sep 2025 21:45:16 GMT, Ashutosh Mehra wrote: >> This PR removes the need to store entry point addresses in AdapterHandlerEntry by storing a direct pointer to AdapterBlob instead. Entry point addresses can be computed on the fly from the entry point offsets stored in AdapterBlob. > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Add missing ResourceMark > > Signed-off-by: Ashutosh Mehra src/hotspot/share/oops/method.cpp line 1290: > 1288: } else if (_adapter == nullptr) { > 1289: (void) make_adapters(h_method, CHECK); > 1290: #ifndef ZERO With your change to sharedRuntime_zero.cpp I believe the preceding call to `make_adapters` will hit `ShouldNotReachHere()` and hence will not return. So, this #ifndef ZERO appears to be unnecessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27101#discussion_r2367420303 From tschatzl at openjdk.org Mon Sep 22 10:19:02 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 22 Sep 2025 10:19:02 GMT Subject: RFR: 8363932: G1: Better distribute KlassCleaningTask [v2] In-Reply-To: <4wv4YEc8jXOrh142RF4lbiAOx5HSEe8tcDc-BYQC-5I=.461e968b-21dd-493e-9dfb-dcc9f962700a@github.com> References: <4wv4YEc8jXOrh142RF4lbiAOx5HSEe8tcDc-BYQC-5I=.461e968b-21dd-493e-9dfb-dcc9f962700a@github.com> Message-ID: > Hi all, > > please review this change to parallel klass cleaning to improve performance. > > The current implementation only parallelizes cleaning of weak class links, while the main work, cleaning the object tree is single-threaded. Hence in practice, the current mechanism does not scale beyond 2-3 threads. > > Cleaning an object graph in an application that loads some jars and instantiates central classes within them, with around 180k classes the current `G1 Complete Cleaning` task (which executes this code) can take 80ms (with 25 threads). > > The suggested change is to walk the object graph by (live) `ClassLoaderData` klass by klass, fixing only the links of that particular klass. > > E.g. > > CLD1 has klasses A, B, C, CLD2 has klasses a, b, c and CLD3 has klasses 0, 1, 2, 4; > vertical links are subklass references, while horizontal links are sibling references. > > j.l.O > | > A - B - c - 3 > | > 0 - 2 - C - 1 > > > CLD 3 is dead. Thread 1 claims CLD 1, Thread 2 claims CLD 2 (and nobody claims CLD3 because it's dead). > > So thread 1, when reaching `A` fixes its subklass link to `C`, and otherwise does nothing with `A`. When looking at `C`, it will remove the link to `1`. > Thread 2 will only remove the link to `3` of `c`. > > The result is > > j.l.O > | > A - B - c > | > C > > > There should be no unnecessary object graph walking. > > There is a slight change in printing during unlinking: previously the code, when cleaning subklasses it printed `unlinking class (subclass)`for every class that has been removed on the way to the next live one. In above case, it would print > > > unlinking class (subclass): 0 > unlinking class (subclass): 2 > > > With the change, to avoid following the subklasses of the graph twice, it prints > > > ?unlinking class (subclass): 0 > unlinking class (sibling): 0 > > > because the string in brackets is the actual link that is followed. I can revert that change. > > With the change "Complete Cleaning" time for 200k classes takes 7.6ms (The test is a bit random on when it does the class unloading). > > Testing: tier1-5 > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * ayang review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27316/files - new: https://git.openjdk.org/jdk/pull/27316/files/c6e3522d..4c0a9cbb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27316&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27316&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27316.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27316/head:pull/27316 PR: https://git.openjdk.org/jdk/pull/27316 From tschatzl at openjdk.org Mon Sep 22 10:23:51 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 22 Sep 2025 10:23:51 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v64] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * iwalulya: "Amount of" -> "Number of" in new flag description ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/53ef008a..6e37f8de Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=63 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=62-63 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From mhaessig at openjdk.org Mon Sep 22 10:26:42 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Mon, 22 Sep 2025 10:26:42 GMT Subject: RFR: 8367862: debug.cpp: Do not print help message for methods ifdef'd out [v3] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 09:55:23 GMT, Kerem Kat wrote: >> The `help` command in `debug.cpp` was out of date, listing only a fraction of the available functions. This and other commands callable from gdb via `call help()`. >> >> I added all commands to the help message, except `pns2` as it is documented as not being useful when called from gdb. >> >> Also fixed is the message for the conditional `pns` command appearing in PRODUCT builds. > > Kerem Kat has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/utilities/debug.cpp > > Co-authored-by: Manuel H?ssig Still good ------------- Marked as reviewed by mhaessig (Committer). PR Review: https://git.openjdk.org/jdk/pull/27341#pullrequestreview-3251710436 From luhenry at openjdk.org Mon Sep 22 10:28:56 2025 From: luhenry at openjdk.org (Ludovic Henry) Date: Mon, 22 Sep 2025 10:28:56 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v5] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 09:22:39 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> >> Currently, the cpu features of riscv are stored in separate RVFeature subclasses. >> But to support the store/restore CPU features for aot in the future, we need to store the cpu features in a continuous memory. >> As the riscv extensions are introduced continuously, I think it's better to do it via an simple bitmap at the beginning. >> Currently, just suppose the non-extension features will not be stored in aot image, so I also split the extension and non-extenion features. When we implement the related aot feature in the short future, we can revisit the way of splitting the features. Currently, just change the storage way of cpu features, lay the foundation for future aot. >> >> Thanks > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > simplify names src/hotspot/cpu/riscv/vm_version_riscv.hpp line 68: > 66: } > 67: const char* pretty() { return _pretty; } > 68: uint64_t feature_bit() { return _linux_feature_bit; } Why the renaming? src/hotspot/cpu/riscv/vm_version_riscv.hpp line 275: > 273: public: > 274: enum RVFeatureIndex { > 275: #define DECLARE_RV_FEATURE_ENUM(NAME, PRETTY, LINUX_BIT, CPU_FEATURE_INDEX, FSTRING, FLAGF) CPU_##NAME=(CPU_FEATURE_INDEX), Instead of explicitly setting the feature index, can't we use the implicit numbering of the enum and remove the `cpu feature index` from `RV_EXT_FEATURE_FLAGS` entirely? The only other use I can see of `CPU_FEATURE_INDEX` is at https://github.com/openjdk/jdk/pull/27152/files#diff-7b173d6e5834de13749c8333192fef5a874628a67b90a5d8d06235d507542ac4R39 and I wonder if we can't use the enum `CPU_#NAME` there directy. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2367502775 PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2367493775 From adinn at openjdk.org Mon Sep 22 10:32:03 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 22 Sep 2025 10:32:03 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry [v3] In-Reply-To: <1G62FqEtGv4PUVe4Cmuuf76ZztmhbEHeesSzjOioanc=.b5cfa387-10fe-4904-94ea-d8ed2fbb2d12@github.com> References: <1G62FqEtGv4PUVe4Cmuuf76ZztmhbEHeesSzjOioanc=.b5cfa387-10fe-4904-94ea-d8ed2fbb2d12@github.com> Message-ID: <1-FLVATUqom1H2poFIkSAUTvgeh9ojHeZ3W4gTgMRyo=.962d3ddb-8d02-4ab3-a15e-91b64194b8e3@github.com> On Mon, 22 Sep 2025 10:09:00 GMT, Andrew Dinn wrote: >> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: >> >> Add missing ResourceMark >> >> Signed-off-by: Ashutosh Mehra > > src/hotspot/share/oops/method.cpp line 1290: > >> 1288: } else if (_adapter == nullptr) { >> 1289: (void) make_adapters(h_method, CHECK); >> 1290: #ifndef ZERO > > With your change to sharedRuntime_zero.cpp I believe the preceding call to `make_adapters` will hit `ShouldNotReachHere()` and hence will not return. So, this #ifndef ZERO appears to be unnecessary. Ok, scratch that. I see that `generate_adapter_code` bypasses the call to `generate_i2c2i_adapters` in the ZERO case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27101#discussion_r2367518481 From luhenry at openjdk.org Mon Sep 22 10:33:04 2025 From: luhenry at openjdk.org (Ludovic Henry) Date: Mon, 22 Sep 2025 10:33:04 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v5] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 09:22:39 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> >> Currently, the cpu features of riscv are stored in separate RVFeature subclasses. >> But to support the store/restore CPU features for aot in the future, we need to store the cpu features in a continuous memory. >> As the riscv extensions are introduced continuously, I think it's better to do it via an simple bitmap at the beginning. >> Currently, just suppose the non-extension features will not be stored in aot image, so I also split the extension and non-extenion features. When we implement the related aot feature in the short future, we can revisit the way of splitting the features. Currently, just change the storage way of cpu features, lay the foundation for future aot. >> >> Thanks > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > simplify names src/hotspot/cpu/riscv/vm_version_riscv.hpp line 415: > 413: // Null terminated list > 414: static RVFeatureValue* _feature_list[]; > 415: static RVExtFeatures* _rv_ext_features; Does that need to be a pointer? Can't it be `static RVExtFeatures _rv_ext_features` directly? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2367519227 From mli at openjdk.org Mon Sep 22 10:38:20 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 22 Sep 2025 10:38:20 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v5] In-Reply-To: References: Message-ID: <9wAipOtQrE3J8rcxbaHUFxS0_74vAGyYjC_6kgv87e8=.ece47ea0-89d8-4f3f-b759-7105b712286f@github.com> On Mon, 22 Sep 2025 10:26:03 GMT, Ludovic Henry wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> simplify names > > src/hotspot/cpu/riscv/vm_version_riscv.hpp line 68: > >> 66: } >> 67: const char* pretty() { return _pretty; } >> 68: uint64_t feature_bit() { return _linux_feature_bit; } > > Why the renaming? Two reasons: 1. There is another field `_cpu_feature_index` introduced in `RVExtFeatureValue`. 2. the `_feature_bit ` here is indeed linux feature rather cpu features. So, to be precise and avoid confusing, it's better to rename it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2367549901 From tschatzl at openjdk.org Mon Sep 22 10:40:53 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 22 Sep 2025 10:40:53 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v65] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * walulyai: remove cost_per_pending_card_ms_default array since we only use one value ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/6e37f8de..311bb3e1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=64 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=63-64 Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From adinn at openjdk.org Mon Sep 22 10:41:49 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 22 Sep 2025 10:41:49 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry [v3] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 21:45:16 GMT, Ashutosh Mehra wrote: >> This PR removes the need to store entry point addresses in AdapterHandlerEntry by storing a direct pointer to AdapterBlob instead. Entry point addresses can be computed on the fly from the entry point offsets stored in AdapterBlob. > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Add missing ResourceMark > > Signed-off-by: Ashutosh Mehra src/hotspot/share/runtime/sharedRuntime.hpp line 736: > 734: } > 735: > 736: address get_i2c_entry() const { return _adapter_blob != nullptr ? _adapter_blob->i2c_entry() : nullptr; } Should these getters assert `_adapter_blob != nullptr`? I think we should only ever have an AdapterHandlerEntry with a null blob on ZERO and in that case an attempt to use the entry would be invalid. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27101#discussion_r2367566558 From ayang at openjdk.org Mon Sep 22 10:46:56 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 22 Sep 2025 10:46:56 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v9] In-Reply-To: References: Message-ID: <5m-KOi8viCfIqep2x2tlZP4E7_zzhC3bzj-SU06iiMY=.38ae38f8-c401-419a-a53f-2bee5571b35c@github.com> On Mon, 22 Sep 2025 05:56:58 GMT, Ivan Walulya wrote: >> Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. >> >> Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. >> >> Testing: Tier 1-7 > > Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - Remove lock > - remove assert > - make universal > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - Merge remote-tracking branch 'upstream/master' into shutting_down_gcs > - Revert > - Thomas Review > - return on timeout > - ... and 8 more: https://git.openjdk.org/jdk/compare/cc65836d...87c80194 src/hotspot/share/memory/universe.cpp line 1349: > 1347: void Universe::before_exit() { > 1348: { > 1349: MutexLocker hl(Heap_lock); Could you add some comment for why locking is needed here? Better reference the read of `_is_shutting_down` in `VM_GC_Operation::doit_prologue`. Good otherwise. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27190#discussion_r2367596946 From adinn at openjdk.org Mon Sep 22 10:49:52 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 22 Sep 2025 10:49:52 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry [v3] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 21:45:16 GMT, Ashutosh Mehra wrote: >> This PR removes the need to store entry point addresses in AdapterHandlerEntry by storing a direct pointer to AdapterBlob instead. Entry point addresses can be computed on the fly from the entry point offsets stored in AdapterBlob. > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Add missing ResourceMark > > Signed-off-by: Ashutosh Mehra Looks good modulo a few suggested tweaks. ------------- Changes requested by adinn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27101#pullrequestreview-3251863471 From adinn at openjdk.org Mon Sep 22 10:49:55 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 22 Sep 2025 10:49:55 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry [v3] In-Reply-To: References: Message-ID: <-yLhQKZ2PYW4Vv0IZPVyNnx228JJdO4buACBhgREsQ8=.99b6468e-c82e-467e-acae-4a93a07a04fe@github.com> On Mon, 22 Sep 2025 10:38:36 GMT, Andrew Dinn wrote: >> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: >> >> Add missing ResourceMark >> >> Signed-off-by: Ashutosh Mehra > > src/hotspot/share/runtime/sharedRuntime.hpp line 736: > >> 734: } >> 735: >> 736: address get_i2c_entry() const { return _adapter_blob != nullptr ? _adapter_blob->i2c_entry() : nullptr; } > > Should these getters assert `_adapter_blob != nullptr`? > I think we should only ever have an AdapterHandlerEntry with a null blob on ZERO and in that case an attempt to use the entry would be invalid. n.b. I guess that would require modifying `print_adapter_on` to check the adapter blob and avoid calling the entry lookup methods/printing the entry address details. It normally gets called when we have a known entry address as a starting point to look up an adapter handle but it is also called from `print_adapter_handler_info` when we may have a handler with a null blob. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27101#discussion_r2367607731 From tschatzl at openjdk.org Mon Sep 22 11:10:28 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 22 Sep 2025 11:10:28 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v66] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * walulyai: remove unnecessarily introduced newline ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/311bb3e1..d80d6902 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=65 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=64-65 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From ayang at openjdk.org Mon Sep 22 11:18:53 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 22 Sep 2025 11:18:53 GMT Subject: RFR: 8368261: Serial: Use more precise nmethod scope during Full GC marking Message-ID: Small patch of extracting out the nmethod-marking-scope logic in Serial full-gc. The new `NMethodMarkingScope` is placed in `nmethod.hpp` like its counterpart `ThreadsClaimTokenScope`. The new `struct` is almost identical to the existing `MarkScope`, so there is a planned followup PR that will address all other users of `StrongRootsScope` to use the recently introduced `ThreadsClaimTokenScope` and the new `NMethodMarkingScope` introduced in this PR, which would make it less abtract than the name `StrongRootsScope`. Test: tier1-3 ------------- Commit messages: - sgc-nmethod-scope Changes: https://git.openjdk.org/jdk/pull/27423/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27423&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368261 Stats: 20 lines in 2 files changed: 14 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27423.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27423/head:pull/27423 PR: https://git.openjdk.org/jdk/pull/27423 From kevinw at openjdk.org Mon Sep 22 11:19:57 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 22 Sep 2025 11:19:57 GMT Subject: RFR: 8367862: debug.cpp: Do not print help message for methods ifdef'd out [v3] In-Reply-To: References: Message-ID: <2OFI1JXuQnNE7iq66RgQaXn_5VxsopIO7B80FyqjAWQ=.3e5bab53-c5b6-4527-b2e6-891cd5966052@github.com> On Mon, 22 Sep 2025 09:55:23 GMT, Kerem Kat wrote: >> The `help` command in `debug.cpp` was out of date, listing only a fraction of the available functions. This and other commands callable from gdb via `call help()`. >> >> I added all commands to the help message, except `pns2` as it is documented as not being useful when called from gdb. >> >> Also fixed is the message for the conditional `pns` command appearing in PRODUCT builds. > > Kerem Kat has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/utilities/debug.cpp > > Co-authored-by: Manuel H?ssig Marked as reviewed by kevinw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27341#pullrequestreview-3252028607 From mli at openjdk.org Mon Sep 22 11:22:22 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 22 Sep 2025 11:22:22 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v5] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 10:24:06 GMT, Ludovic Henry wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> simplify names > > src/hotspot/cpu/riscv/vm_version_riscv.hpp line 275: > >> 273: public: >> 274: enum RVFeatureIndex { >> 275: #define DECLARE_RV_FEATURE_ENUM(NAME, PRETTY, LINUX_BIT, CPU_FEATURE_INDEX, FSTRING, FLAGF) CPU_##NAME=(CPU_FEATURE_INDEX), > > Instead of explicitly setting the feature index, can't we use the implicit numbering of the enum and remove the `cpu feature index` from `RV_EXT_FEATURE_FLAGS` entirely? The only other use I can see of `CPU_FEATURE_INDEX` is at https://github.com/openjdk/jdk/pull/27152/files#diff-7b173d6e5834de13749c8333192fef5a874628a67b90a5d8d06235d507542ac4R39 and I wonder if we can't use the enum `CPU_#NAME` there directy. Yes, it'll be good if we can just remove the explicit numbering of the enum, but seems there is no good way to pass in the enum value to the constructor of `NAME##RVExtFeatureValue` in `DEF_RV_EXT_FEATURE`. We could do it with an static member of RVExtFeatureValue, increment it in RVExtFeatureValue constructor, but seems it's not straight and clear. So my preference is to keep the explicit enum value in `RV_EXT_FEATURE_FLAGS`. How do you think about it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2367768118 From mli at openjdk.org Mon Sep 22 11:32:11 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 22 Sep 2025 11:32:11 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v5] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 10:29:52 GMT, Ludovic Henry wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> simplify names > > src/hotspot/cpu/riscv/vm_version_riscv.hpp line 415: > >> 413: // Null terminated list >> 414: static RVFeatureValue* _feature_list[]; >> 415: static RVExtFeatures* _rv_ext_features; > > Does that need to be a pointer? Can't it be `static RVExtFeatures _rv_ext_features` directly? The reason to put `RVExtFeatures` as a pointer here is that, there is such dependency relationship among classes and macro here: `DECLARE_RV_EXT_FEATURE` -(deps)-> `RVFeatureValue`/`RVExtFeatureValue`/`RVNonExtFeatureValue` -(deps)-> `RVExtFeatures` -> `RVFeatureIndex` -> `DECLARE_RV_EXT_FEATURE`. One way to break the cyclic deps is to use a pointer of RVExtFeatures in `RVExtFeatureValue`/`RVNonExtFeatureValue`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2367815808 From tschatzl at openjdk.org Mon Sep 22 11:40:01 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 22 Sep 2025 11:40:01 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v67] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * walulyai: bufferNodeList can be removed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/d80d6902..3c889e9f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=66 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=65-66 Stats: 81 lines in 3 files changed: 0 ins; 81 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739 From jsikstro at openjdk.org Mon Sep 22 11:50:13 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 22 Sep 2025 11:50:13 GMT Subject: RFR: 8368251: Parallel: Refactor lgrp_id used in MutableNUMASpace Message-ID: <88Djo0LC5If0BwK55jK6e80Pr-k-HP7H0kRu__16Wfk=.500f12aa-4b38-40d8-88c8-7372004cdda5@github.com> Hello, There are multiple cases which handle if the locality group (lgrp) id is negative (-1) in Parallel, specifically in MutableNUMASpace. -1 was historically used to indicate that the hardware topology has changed and that the lgrp id needs to be updated. This is no longer the case, since HotSpot doesn't support CPU/NUMA hotplugging, and the last piece of code setting the lgrp id to -1 was removed in [JDK-8301149](https://bugs.openjdk.org/browse/JDK-8301149). I propose we simplify the code a bit by not handling edge cases where the lgrp id is -1 and removing os::numa_has_group_homing(), which always return false Testing: * Running through Oracle's tier 1-4 * Local NUMA testing tier1-4 with `-XX:+UseParallelGC -XX:+UseNUMA` ------------- Commit messages: - 8368251: Parallel: Refactor lgrp_id used in MutableNUMASpace Changes: https://git.openjdk.org/jdk/pull/27424/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27424&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368251 Stats: 117 lines in 10 files changed: 9 ins; 88 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/27424.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27424/head:pull/27424 PR: https://git.openjdk.org/jdk/pull/27424 From duke at openjdk.org Mon Sep 22 11:55:44 2025 From: duke at openjdk.org (Ruben) Date: Mon, 22 Sep 2025 11:55:44 GMT Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1 volatile field loads [v2] In-Reply-To: References: <7rOmFYwzssNyo-r4sU_9563VootV4M61h-6MYsNU7Zc=.23d773f2-43a3-4ea0-8a1d-f1b740bdcdbb@github.com> Message-ID: On Fri, 19 Sep 2025 09:43:16 GMT, Andrew Haley wrote: > But that could be handled in another patch. Sure, I can prepare a separate patch with the fix. Is there anything you would like to be modified within this patch before it can be integrated? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26748#issuecomment-3318515869 From iwalulya at openjdk.org Mon Sep 22 12:05:22 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 22 Sep 2025 12:05:22 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v10] In-Reply-To: References: Message-ID: > Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. > > Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. > > Testing: Tier 1-7 Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: Albert suggestion ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27190/files - new: https://git.openjdk.org/jdk/pull/27190/files/87c80194..f1ec9692 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27190&range=08-09 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27190.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27190/head:pull/27190 PR: https://git.openjdk.org/jdk/pull/27190 From iwalulya at openjdk.org Mon Sep 22 12:18:30 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 22 Sep 2025 12:18:30 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v67] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 11:40:01 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * walulyai: bufferNodeList can be removed Still Good! ------------- Marked as reviewed by iwalulya (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23739#pullrequestreview-3252343247 From ayang at openjdk.org Mon Sep 22 12:22:42 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 22 Sep 2025 12:22:42 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v10] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 12:05:22 GMT, Ivan Walulya wrote: >> Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. >> >> Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. >> >> Testing: Tier 1-7 > > Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: > > Albert suggestion Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27190#pullrequestreview-3252368494 From cnorrbin at openjdk.org Mon Sep 22 13:00:24 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 22 Sep 2025 13:00:24 GMT Subject: Integrated: 8367536: Change RBTree to use C++17 features In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 13:59:51 GMT, Casper Norrbin wrote: > Hi everyone, > > C++17 lets us tidy up som of the ugly templating done in the red-black tree. We can replace the `std::false_type`/`std::true_type` tricks used to discover comparator and verifier signatures with the new `std::is_invocable(_r_v)`, and most of the overload/SFINAE noise can disappear thanks to `if constexpr`. > > We can now write one-liners such as: > ```c++ > static constexpr bool HasKeyComparator = std::is_invocable_r_v; > > > and then select the right branch with > ```c++ > if constexpr (HasKeyComparator) { } > > inside a single function instead of having several `ENABLE_IF` overloads. > > This results in fewer lines, clearer intent, and more readable errors, while keeping behaviour identical. > > Testing: > - Oracle tiers 1-3 This pull request has now been integrated. Changeset: 2131584a Author: Casper Norrbin URL: https://git.openjdk.org/jdk/commit/2131584add9ab46c3380bbf35170307e4878ce51 Stats: 62 lines in 2 files changed: 7 ins; 23 del; 32 mod 8367536: Change RBTree to use C++17 features Reviewed-by: kbarrett, ayang ------------- PR: https://git.openjdk.org/jdk/pull/27260 From cnorrbin at openjdk.org Mon Sep 22 13:00:23 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 22 Sep 2025 13:00:23 GMT Subject: RFR: 8367536: Change RBTree to use C++17 features [v5] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 08:55:09 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> C++17 lets us tidy up som of the ugly templating done in the red-black tree. We can replace the `std::false_type`/`std::true_type` tricks used to discover comparator and verifier signatures with the new `std::is_invocable(_r_v)`, and most of the overload/SFINAE noise can disappear thanks to `if constexpr`. >> >> We can now write one-liners such as: >> ```c++ >> static constexpr bool HasKeyComparator = std::is_invocable_r_v; >> >> >> and then select the right branch with >> ```c++ >> if constexpr (HasKeyComparator) { } >> >> inside a single function instead of having several `ENABLE_IF` overloads. >> >> This results in fewer lines, clearer intent, and more readable errors, while keeping behaviour identical. >> >> Testing: >> - Oracle tiers 1-3 > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > typo Thank you everyone for reviewing! Everything seems to build fine now, so let's integrate :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27260#issuecomment-3318835975 From stefank at openjdk.org Mon Sep 22 13:36:12 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 22 Sep 2025 13:36:12 GMT Subject: RFR: 8368261: Serial: Use more precise nmethod scope during Full GC marking In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 11:08:39 GMT, Albert Mingkun Yang wrote: > Small patch of extracting out the nmethod-marking-scope logic in Serial full-gc. The new `NMethodMarkingScope` is placed in `nmethod.hpp` like its counterpart `ThreadsClaimTokenScope`. > > The new `struct` is almost identical to the existing `MarkScope`, so there is a planned followup PR that will address all other users of `StrongRootsScope` to use the recently introduced `ThreadsClaimTokenScope` and the new `NMethodMarkingScope` introduced in this PR, which would make it less abtract than the name `StrongRootsScope`. > > Test: tier1-3 Looks good. Do you think it would be good to get rid of the scope starting at line 485. ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27423#pullrequestreview-3252821532 From ayang at openjdk.org Mon Sep 22 13:45:39 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 22 Sep 2025 13:45:39 GMT Subject: RFR: 8368261: Serial: Use more precise nmethod scope during Full GC marking In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 13:33:00 GMT, Stefan Karlsson wrote: > Do you think it would be good to get rid of the scope starting at line 485. I think it's missing a scoped timer there. For example, Parallel full-gc has `GCTraceTime(Debug, gc, phases) tm("Par Mark", &_gc_timer);` in the corresponding place. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27423#issuecomment-3319125514 From tschatzl at openjdk.org Mon Sep 22 13:45:56 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 22 Sep 2025 13:45:56 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v67] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 11:40:01 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * walulyai: bufferNodeList can be removed Aaand, off it goes... Thanks @walulyai @albertnetymk @theRealAph @TheRealMDoerr @robcasloz @RealFYang @offamitkumar @tarsa @tstuefe for your help to complete this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3319127975 From tschatzl at openjdk.org Mon Sep 22 13:51:01 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 22 Sep 2025 13:51:01 GMT Subject: Integrated: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization In-Reply-To: References: Message-ID: <9Q7wwYABAQAZ5qlfJ_hzlDw45cI3ckG2TGJU2SdzJBk=.82ed13fa-23fa-4941-876d-f4a9bc73f582@github.com> On Sun, 23 Feb 2025 18:53:33 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad; // synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se... This pull request has now been integrated. Changeset: 8d5c0056 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/8d5c0056420731cbbd83f2d23837bbb5cdc9e4cc Stats: 7273 lines in 115 files changed: 2616 ins; 3672 del; 985 mod 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization Co-authored-by: Amit Kumar Co-authored-by: Martin Doerr Co-authored-by: Carlo Refice Co-authored-by: Fei Yang Reviewed-by: iwalulya, rcastanedalo, aph, ayang ------------- PR: https://git.openjdk.org/jdk/pull/23739 From missa at openjdk.org Mon Sep 22 14:28:12 2025 From: missa at openjdk.org (Mohamed Issa) Date: Mon, 22 Sep 2025 14:28:12 GMT Subject: RFR: 8367611: Enable vblendvp[sd] on Future ECore [v2] In-Reply-To: <2QodBQQIkP3GqBq1yUDqVS1a8EaYkN1FMTkuNHyKUcs=.1cc28add-901c-4731-a2de-0adaa768c54e@github.com> References: <_Jk5fv1iO9ZPZyOtUAXeUez481RibKJR4FsUT_BnKm8=.2f68f9ee-9ce2-4dbb-be8b-1b9f910ba0e0@github.com> <2QodBQQIkP3GqBq1yUDqVS1a8EaYkN1FMTkuNHyKUcs=.1cc28add-901c-4731-a2de-0adaa768c54e@github.com> Message-ID: On Mon, 22 Sep 2025 07:24:50 GMT, Manuel H?ssig wrote: > > @mhaessig I used this test because it frequently calls vblendvps() and vblendvpd() in the macro assembler. On Darkmont and non-Darkmont cores, I checked the right code paths were followed with asserts. Also, I wrote some sample code and checked the instructions generated at runtime. > > Did you also run a some tests generating vblendvps with sde to verify the correct result with the new code paths? Yes, I ran tests with SDE using different platform flags and verified the results. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27354#issuecomment-3319372628 From mdoerr at openjdk.org Mon Sep 22 14:50:40 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 22 Sep 2025 14:50:40 GMT Subject: RFR: 8342382: Implement JEP 522: G1 GC: Improve Throughput by Reducing Synchronization [v67] In-Reply-To: References: Message-ID: <6SnHJ_DA3BBYNyb5po8OWnRa38wnA-k_MeANsUpT21U=.2e9dad9d-9d53-4eb9-ae83-d740e5d1eaff@github.com> On Mon, 22 Sep 2025 11:40:01 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible. >> >> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad; // synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining. >> >> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * walulyai: bufferNodeList can be removed Congratulations! And thanks for updating it for such a long time! ------------- PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-3319517386 From aph at openjdk.org Mon Sep 22 15:04:04 2025 From: aph at openjdk.org (Andrew Haley) Date: Mon, 22 Sep 2025 15:04:04 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v6] In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: > In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. > > Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. > > This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. > > The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. > > We mark all sites that we know will write to code memory with > `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. > > We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. > > It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. > > One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ... Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - Merge from master - Merge from master - Reviewer comments - Reviewer comments - Tmp - Update src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com> - Update src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp Co-authored-by: Bernhard Urban-Forster - Cleanup - More - More - ... and 8 more: https://git.openjdk.org/jdk/compare/bf726e82...2843000e ------------- Changes: https://git.openjdk.org/jdk/pull/26562/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=05 Stats: 286 lines in 34 files changed: 227 ins; 23 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/26562.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26562/head:pull/26562 PR: https://git.openjdk.org/jdk/pull/26562 From aph at openjdk.org Mon Sep 22 15:20:13 2025 From: aph at openjdk.org (Andrew Haley) Date: Mon, 22 Sep 2025 15:20:13 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v7] In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: > In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. > > Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. > > This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. > > The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. > > We mark all sites that we know will write to code memory with > `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. > > We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. > > It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. > > One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ... Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: More ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26562/files - new: https://git.openjdk.org/jdk/pull/26562/files/2843000e..febe873d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=05-06 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26562.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26562/head:pull/26562 PR: https://git.openjdk.org/jdk/pull/26562 From duke at openjdk.org Mon Sep 22 15:06:08 2025 From: duke at openjdk.org (duke) Date: Mon, 22 Sep 2025 15:06:08 GMT Subject: RFR: 8367862: debug.cpp: Do not print help message for methods ifdef'd out [v3] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 09:55:23 GMT, Kerem Kat wrote: >> The `help` command in `debug.cpp` was out of date, listing only a fraction of the available functions. This and other commands callable from gdb via `call help()`. >> >> I added all commands to the help message, except `pns2` as it is documented as not being useful when called from gdb. >> >> Also fixed is the message for the conditional `pns` command appearing in PRODUCT builds. > > Kerem Kat has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/utilities/debug.cpp > > Co-authored-by: Manuel H?ssig @krk Your change (at version 1cf2bf5989cb0584a304e2197e5ac4046575f06f) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27341#issuecomment-3319598153 From shade at openjdk.org Mon Sep 22 15:31:38 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 22 Sep 2025 15:31:38 GMT Subject: RFR: 8367862: debug.cpp: Do not print help message for methods ifdef'd out [v3] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 09:55:23 GMT, Kerem Kat wrote: >> The `help` command in `debug.cpp` was out of date, listing only a fraction of the available functions. This and other commands callable from gdb via `call help()`. >> >> I added all commands to the help message, except `pns2` as it is documented as not being useful when called from gdb. >> >> Also fixed is the message for the conditional `pns` command appearing in PRODUCT builds. > > Kerem Kat has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/utilities/debug.cpp > > Co-authored-by: Manuel H?ssig Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27341#pullrequestreview-3253553018 From krk at openjdk.org Mon Sep 22 15:35:04 2025 From: krk at openjdk.org (Kerem Kat) Date: Mon, 22 Sep 2025 15:35:04 GMT Subject: Integrated: 8367862: debug.cpp: Do not print help message for methods ifdef'd out In-Reply-To: References: Message-ID: <1UWfVxmuU9C45O11A9KjQ3vJk5-lPZfD3V7htyxHi4U=.f11f7df5-12c8-4258-a3f3-51d2ff246840@github.com> On Wed, 17 Sep 2025 11:27:27 GMT, Kerem Kat wrote: > The `help` command in `debug.cpp` was out of date, listing only a fraction of the available functions. This and other commands callable from gdb via `call help()`. > > I added all commands to the help message, except `pns2` as it is documented as not being useful when called from gdb. > > Also fixed is the message for the conditional `pns` command appearing in PRODUCT builds. This pull request has now been integrated. Changeset: 2f74e143 Author: Kerem Kat Committer: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/2f74e1433489bccf1fe493417715c0861f88a995 Stats: 43 lines in 1 file changed: 25 ins; 0 del; 18 mod 8367862: debug.cpp: Do not print help message for methods ifdef'd out Reviewed-by: mhaessig, kevinw, shade, phh ------------- PR: https://git.openjdk.org/jdk/pull/27341 From coleenp at openjdk.org Mon Sep 22 15:59:53 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 22 Sep 2025 15:59:53 GMT Subject: RFR: 8367989: Remove InstanceKlass::allocate_objArray and ArrayKlass::allocate_arrayArray [v3] In-Reply-To: References: Message-ID: <-7fFGmP3rqhpZZYoUsuAc23NsU3veWqeDjv25hqK89U=.01df3c7e-e66f-4c10-9881-e5b66ff71dea@github.com> On Fri, 19 Sep 2025 13:18:09 GMT, Coleen Phillimore wrote: >> This change removes InstanceKlass::allocate_objArray and has its caller call ObjArrayKlass::allocate_instance directly from oopFactory, like the other array allocations do. See CR for more information why we should have this change. I also removed element_klass_addr() and moved element_klass_offset() to be in a more logical place near element_klass() functions. This upstreams a tiny valhalla diff. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Use virtual function rather than if statement, still need one cast though. Thanks Stefan. I'm running tier1-8 testing now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27372#issuecomment-3319890488 From aph at openjdk.org Mon Sep 22 16:59:41 2025 From: aph at openjdk.org (Andrew Haley) Date: Mon, 22 Sep 2025 16:59:41 GMT Subject: RFR: 8368303: AlwaysAtomicAccesses is excessively strict Message-ID: In C1, the experimental flag `AlwaysAtomicAccesses` treats accesses to all fields as if they were volatile fields. This is correct but excessive: we only need single-copy atomicity to satisfy `AlwaysAtomicAccesses`. We need this in order to allow progress on JDK-8365147. ------------- Commit messages: - First try Changes: https://git.openjdk.org/jdk/pull/27432/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27432&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368303 Stats: 11 lines in 1 file changed: 9 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27432.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27432/head:pull/27432 PR: https://git.openjdk.org/jdk/pull/27432 From aph at openjdk.org Mon Sep 22 17:00:36 2025 From: aph at openjdk.org (Andrew Haley) Date: Mon, 22 Sep 2025 17:00:36 GMT Subject: RFR: 8365147: AArch64: Replace DMB + LD + DMB with LDAR for C1 volatile field loads [v2] In-Reply-To: References: Message-ID: On Tue, 19 Aug 2025 13:42:19 GMT, Samuel Chee wrote: >> Replaces the DMB ISH + LD + DMB ISHLD sequence with LDAR for volatile field loads - for example, AtomicLong::get. >> >> This is valid, as originally the DMBs were necessary due to the case described here - https://bugs.openjdk.org/browse/JDK-8179954. As in the rare case where the LD can be reordered with an LDAR or STLR from the C2 implementation for stores and loads, these DMBs are required. >> However, acquire/release operations use a sequentially consistent model which does not allow reordering between them. Hence, the LD can be replaced with an LDAR to disallow reordering with a STLR/LDAR and the first DMB can be removed. >> >> The LDAR has acquire semantics, so it's impossible for memory accesses after to be reordered before; the DMB ISHLD is not required. Therefore, a singular LDAR is sufficient. > > Samuel Chee has updated the pull request incrementally with two additional commits since the last revision: > > - Address review comments > > Change-Id: Ica13be8094ac0f057066042ef0a5ec5927b98dfd > - Refine code generation for mem2reg_volatile > > The patch is contributed by @theRealAph. > > Change-Id: I7ab1854dd238cdce72a4ab218b5b4ee84ad39586 See https://github.com/openjdk/jdk/pull/27432 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26748#issuecomment-3320194897 From liach at openjdk.org Mon Sep 22 17:15:42 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 22 Sep 2025 17:15:42 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final In-Reply-To: References: Message-ID: On Thu, 8 May 2025 11:22:30 GMT, Alan Bateman wrote: > Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500). > > Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP. > > HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX). > > There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package. > > Testing: tier1-6 src/hotspot/share/prims/jni.cpp line 1931: > 1929: } \ > 1930: o->Fieldname##_field_put(offset, value); \ > 1931: log_debug_if_final_instance_field(thread, "SetField", k, offset); \ Just curious, can we use macros to convert generic `SetField` to specific ones, such as using ##Result## in the string? src/hotspot/share/prims/jniCheck.cpp line 1252: > 1250: IN_VM( \ > 1251: checkInstanceFieldID(thr, fieldID, obj, FieldType); \ > 1252: checkCanSetInstanceField(thr, fieldID, obj); \ Same remark, could we pass ##Result## so we avoid `SetField`? src/java.base/share/classes/java/lang/Module.java line 950: > 948: *

Opening a package with this method does not allow the given module to > 949: * {@linkplain Field#set(Object, Object) reflectively set} a final field declared > 950: * in a class in the package, or Suggestion: * {@linkplain Field#set(Object, Object) reflectively set} or src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 3449: > 3447: } > 3448: // check if write access to final field allowed > 3449: if (!field.isStatic() && isAccessible && allowedModes != TRUSTED) { I don't think we need this allowedModes special permission - I see no scenario in which the core libraries implementation needs to perform such a reflective operation. src/java.base/share/classes/java/lang/reflect/AccessibleObject.java line 173: > 171: *

The {@code accessible} flag when {@code true} suppresses Java language access > 172: * control checks to only enable {@linkplain Field#get read} access to > 173: * these non-modifiable final fields. Note to reviewers: this is moved to Field.setAccessible. src/java.base/share/classes/java/lang/reflect/Field.java line 1439: > 1437: } else { > 1438: // no java caller, only allowed if field is public in exported package > 1439: if (!Reflection.verifyPublicMemberAccess(clazz, modifiers)) { Is this sufficient? I know core libraries has APIs as public non-static final fields, like java.lang.constant.DirectMethodHandleDesc$Kind.refKind. Don't think they should be allowed to be modified by native code, for example. src/java.base/share/classes/java/lang/reflect/Field.java line 1461: > 1459: return Modifier.isFinal(modifiers) > 1460: && !Modifier.isStatic(modifiers) > 1461: && !clazz.isRecord() This check cannot constant fold in the edge case where the declaring class extends `java.lang.Record` but does not have a `Record` attribute. I have seen such classes in proguard-stripped code. test/langtools/jdk/jshell/CompletionSuggestionTest.java line 35: > 33: * @build toolbox.ToolBox toolbox.JarTask toolbox.JavacTask > 34: * @build KullaTesting TestingInputStream Compiler > 35: * @run junit/othervm/timeout=480 CompletionSuggestionTest Why does this need an update? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2349051829 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2349061108 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2362845215 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2349087370 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2349097202 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2349771906 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2369472297 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2369489143 From alanb at openjdk.org Mon Sep 22 17:37:55 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 22 Sep 2025 17:37:55 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 18:18:02 GMT, Chen Liang wrote: >> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500). >> >> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP. >> >> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX). >> >> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package. >> >> Testing: tier1-6 > > src/java.base/share/classes/java/lang/reflect/Field.java line 1439: > >> 1437: } else { >> 1438: // no java caller, only allowed if field is public in exported package >> 1439: if (!Reflection.verifyPublicMemberAccess(clazz, modifiers)) { > > Is this sufficient? I know core libraries has APIs as public non-static final fields, like java.lang.constant.DirectMethodHandleDesc$Kind.refKind. Don't think they should be allowed to be modified by native code, for example. If a JNI attached thread does an upcall to Field.set with no Java frames on the stack, then it is can mutate a public final field in a public class in an exported package when "illegal final field mutation" is allowed. If denied then IAE will be thrown. > test/langtools/jdk/jshell/CompletionSuggestionTest.java line 35: > >> 33: * @build toolbox.ToolBox toolbox.JarTask toolbox.JavacTask >> 34: * @build KullaTesting TestingInputStream Compiler >> 35: * @run junit/othervm/timeout=480 CompletionSuggestionTest > > Why does this need an update? I mentioned this in the PR description because it is necessary to change a small number of tests ro run in /othervm mode. This is because jtreg reflectively opening a package isn't sufficient, it has to run the test with `--add-opens`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2369566678 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2369572798 From alanb at openjdk.org Mon Sep 22 17:43:02 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 22 Sep 2025 17:43:02 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 17:08:20 GMT, Chen Liang wrote: >> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500). >> >> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP. >> >> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX). >> >> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package. >> >> Testing: tier1-6 > > src/java.base/share/classes/java/lang/reflect/Field.java line 1461: > >> 1459: return Modifier.isFinal(modifiers) >> 1460: && !Modifier.isStatic(modifiers) >> 1461: && !clazz.isRecord() > > This check cannot constant fold in the edge case where the declaring class extends `java.lang.Record` but does not have a `Record` attribute. I have seen such classes in proguard-stripped code. If this were to become an issue then we could separate the isFinal check. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2369589705 From liach at openjdk.org Mon Sep 22 17:58:04 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 22 Sep 2025 17:58:04 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 17:33:56 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/lang/reflect/Field.java line 1439: >> >>> 1437: } else { >>> 1438: // no java caller, only allowed if field is public in exported package >>> 1439: if (!Reflection.verifyPublicMemberAccess(clazz, modifiers)) { >> >> Is this sufficient? I know core libraries has APIs as public non-static final fields, like java.lang.constant.DirectMethodHandleDesc$Kind.refKind. Don't think they should be allowed to be modified by native code, for example. > > If a JNI attached thread does an upcall to Field.set with no Java frames on the stack, then it is can mutate a public final field in a public class in an exported package when "illegal final field mutation" is allowed. If denied then IAE will be thrown. This is a good transition measure. I assume that we can allow JIT compilers to constant fold when both illegal final field mutations are disabled, and no module is opening the member's package and enabling field mutation at the same time. (We might add such a check for "safe for constant folding" in the compiler interface as later work) >> test/langtools/jdk/jshell/CompletionSuggestionTest.java line 35: >> >>> 33: * @build toolbox.ToolBox toolbox.JarTask toolbox.JavacTask >>> 34: * @build KullaTesting TestingInputStream Compiler >>> 35: * @run junit/othervm/timeout=480 CompletionSuggestionTest >> >> Why does this need an update? > > I mentioned this in the PR description because it is necessary to change a small number of tests ro run in /othervm mode. This is because jtreg reflectively opening a package isn't sufficient, it has to run the test with `--add-opens`. Do you think we should update jtreg to fail in the future if `@modules` is specified without othervm, like how `@enablePreview` works today? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2369641672 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2369650042 From alanb at openjdk.org Mon Sep 22 18:01:19 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 22 Sep 2025 18:01:19 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 13:13:22 GMT, Chen Liang wrote: >> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500). >> >> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP. >> >> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX). >> >> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package. >> >> Testing: tier1-6 > > src/java.base/share/classes/java/lang/Module.java line 950: > >> 948: *

Opening a package with this method does not allow the given module to >> 949: * {@linkplain Field#set(Object, Object) reflectively set} a final field declared >> 950: * in a class in the package, or > > Suggestion: > > * {@linkplain Field#set(Object, Object) reflectively set} or Okay, we could make that wording work if there is a comma after ".. write access". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2369665043 From coleenp at openjdk.org Mon Sep 22 18:03:26 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 22 Sep 2025 18:03:26 GMT Subject: RFR: 8363932: G1: Better distribute KlassCleaningTask [v2] In-Reply-To: References: <4wv4YEc8jXOrh142RF4lbiAOx5HSEe8tcDc-BYQC-5I=.461e968b-21dd-493e-9dfb-dcc9f962700a@github.com> Message-ID: <5428RDHuq7W2B2z2nRKYOL9EOFpYXRFH_AzuKmpiyPM=.988afe07-15c3-44f8-9424-8080a158b6ae@github.com> On Mon, 22 Sep 2025 10:19:02 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to parallel klass cleaning to improve performance. >> >> The current implementation only parallelizes cleaning of weak class links, while the main work, cleaning the object tree is single-threaded. Hence in practice, the current mechanism does not scale beyond 2-3 threads. >> >> Cleaning an object graph in an application that loads some jars and instantiates central classes within them, with around 180k classes the current `G1 Complete Cleaning` task (which executes this code) can take 80ms (with 25 threads). >> >> The suggested change is to walk the object graph by (live) `ClassLoaderData` klass by klass, fixing only the links of that particular klass. >> >> E.g. >> >> CLD1 has klasses A, B, C, CLD2 has klasses a, b, c and CLD3 has klasses 0, 1, 2, 4; >> vertical links are subklass references, while horizontal links are sibling references. >> >> j.l.O >> | >> A - B - c - 3 >> | >> 0 - 2 - C - 1 >> >> >> CLD 3 is dead. Thread 1 claims CLD 1, Thread 2 claims CLD 2 (and nobody claims CLD3 because it's dead). >> >> So thread 1, when reaching `A` fixes its subklass link to `C`, and otherwise does nothing with `A`. When looking at `C`, it will remove the link to `1`. >> Thread 2 will only remove the link to `3` of `c`. >> >> The result is >> >> j.l.O >> | >> A - B - c >> | >> C >> >> >> There should be no unnecessary object graph walking. >> >> There is a slight change in printing during unlinking: previously the code, when cleaning subklasses it printed `unlinking class (subclass)`for every class that has been removed on the way to the next live one. In above case, it would print >> >> >> unlinking class (subclass): 0 >> unlinking class (subclass): 2 >> >> >> With the change, to avoid following the subklasses of the graph twice, it prints >> >> >> ?unlinking class (subclass): 0 >> unlinking class (sibling): 0 >> >> >> because the string in brackets is the actual link that is followed. I can revert that change. >> >> With the change "Complete Cleaning" time for 200k classes takes 7.6ms (The test is a bit random on when it does the class unloading). >> >> Testing: tier1-5 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * ayang review This looks good to me. I think your explanation makes sense and the example helps very much. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27316#pullrequestreview-3254366360 From alanb at openjdk.org Mon Sep 22 18:09:53 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 22 Sep 2025 18:09:53 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 17:55:22 GMT, Chen Liang wrote: >> I mentioned this in the PR description because it is necessary to change a small number of tests ro run in /othervm mode. This is because jtreg reflectively opening a package isn't sufficient, it has to run the test with `--add-opens`. > > Do you think we should update jtreg to fail in the future if `@modules` is specified without othervm, like how `@enablePreview` works today? No, we need to allow jtreg continue to use its injected JTRegModuleHelper to do this, otherwise it would mean a lot more forking of VMs in test runs for the sake of the tiny number of tests that are hacking finals. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2369695722 From sviswanathan at openjdk.org Mon Sep 22 18:31:40 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Mon, 22 Sep 2025 18:31:40 GMT Subject: RFR: 8367611: Enable vblendvp[sd] on Future ECore [v3] In-Reply-To: References: <_Jk5fv1iO9ZPZyOtUAXeUez481RibKJR4FsUT_BnKm8=.2f68f9ee-9ce2-4dbb-be8b-1b9f910ba0e0@github.com> Message-ID: On Fri, 19 Sep 2025 21:57:30 GMT, Mohamed Issa wrote: >> The upcoming ECore platforms will benefit from using `vblendvps` and `vblendvpd` instructions when the destination register is the same as the source register. This change takes that situation into account. >> >> The JTREG test shown below was used to verify correctness against the [OpenJDK v26-b15](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B15) baseline build. This test frequently calls vblendvps() and vblendvpd() in the macro assembler. On Darkmont and non-Darkmont cores, the right code paths are followed when checking with asserts. >> >> 1. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` > > Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: > > Combine boolean flags to avoid ambiguity Looks good to me. ------------- Marked as reviewed by sviswanathan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27354#pullrequestreview-3254504880 From fparain at openjdk.org Mon Sep 22 19:14:54 2025 From: fparain at openjdk.org (Frederic Parain) Date: Mon, 22 Sep 2025 19:14:54 GMT Subject: RFR: 8367989: Remove InstanceKlass::allocate_objArray and ArrayKlass::allocate_arrayArray [v3] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 13:18:09 GMT, Coleen Phillimore wrote: >> This change removes InstanceKlass::allocate_objArray and has its caller call ObjArrayKlass::allocate_instance directly from oopFactory, like the other array allocations do. See CR for more information why we should have this change. I also removed element_klass_addr() and moved element_klass_offset() to be in a more logical place near element_klass() functions. This upstreams a tiny valhalla diff. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Use virtual function rather than if statement, still need one cast though. Marked as reviewed by fparain (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27372#pullrequestreview-3254718221 From asmehra at openjdk.org Mon Sep 22 19:30:40 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Mon, 22 Sep 2025 19:30:40 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v10] In-Reply-To: References: Message-ID: On Sat, 20 Sep 2025 00:57:09 GMT, Ioi Lam wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @ashu-mehra comment - AOTLinkedClassBulkLoader::link_or_init_javabase_classes() should also call exit_on_exception() lgtm ------------- Marked as reviewed by asmehra (Committer). PR Review: https://git.openjdk.org/jdk/pull/26375#pullrequestreview-3254807664 From vlivanov at openjdk.org Mon Sep 22 19:38:23 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 22 Sep 2025 19:38:23 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final In-Reply-To: References: Message-ID: On Thu, 8 May 2025 11:22:30 GMT, Alan Bateman wrote: > Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500). > > Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP. > > HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX). > > There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package. > > Testing: tier1-6 Hotspot changes look good. src/hotspot/share/runtime/fieldDescriptor.cpp line 49: > 47: } > 48: > 49: bool fieldDescriptor::is_mutable_static_final() const { Please, migrate `ciField::initialize_from()` from ad-hoc checks to `fieldDescriptor::is_mutable_static_final()`. diff --git a/src/hotspot/share/ci/ciField.cpp b/src/hotspot/share/ci/ciField.cpp index cbe0cadbc93..dffc387612d 100644 --- a/src/hotspot/share/ci/ciField.cpp +++ b/src/hotspot/share/ci/ciField.cpp @@ -267,17 +267,7 @@ void ciField::initialize_from(fieldDescriptor* fd) { // not be constant is when the field is a *special* static & final field // whose value may change. The three examples are java.lang.System.in, // java.lang.System.out, and java.lang.System.err. - assert(vmClasses::System_klass() != nullptr, "Check once per vm"); - if (k == vmClasses::System_klass()) { - // Check offsets for case 2: System.in, System.out, or System.err - if (_offset == java_lang_System::in_offset() || - _offset == java_lang_System::out_offset() || - _offset == java_lang_System::err_offset()) { - _is_constant = false; - return; - } - } - _is_constant = true; + _is_constant = !fd->is_mutable_static_final(); } else { // An instance field can be constant if it's a final static field or if // it's a final non-static field of a trusted class (classes in ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25115#pullrequestreview-3254635791 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2369888932 From asmehra at openjdk.org Mon Sep 22 19:55:09 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Mon, 22 Sep 2025 19:55:09 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry [v4] In-Reply-To: References: Message-ID: > This PR removes the need to store entry point addresses in AdapterHandlerEntry by storing a direct pointer to AdapterBlob instead. Entry point addresses can be computed on the fly from the entry point offsets stored in AdapterBlob. Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: Address adinn's review comments Signed-off-by: Ashutosh Mehra ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27101/files - new: https://git.openjdk.org/jdk/pull/27101/files/b939ee98..1c3d1744 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27101&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27101&range=02-03 Stats: 53 lines in 3 files changed: 38 ins; 4 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/27101.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27101/head:pull/27101 PR: https://git.openjdk.org/jdk/pull/27101 From asmehra at openjdk.org Mon Sep 22 20:01:06 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Mon, 22 Sep 2025 20:01:06 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry [v3] In-Reply-To: <-yLhQKZ2PYW4Vv0IZPVyNnx228JJdO4buACBhgREsQ8=.99b6468e-c82e-467e-acae-4a93a07a04fe@github.com> References: <-yLhQKZ2PYW4Vv0IZPVyNnx228JJdO4buACBhgREsQ8=.99b6468e-c82e-467e-acae-4a93a07a04fe@github.com> Message-ID: On Mon, 22 Sep 2025 10:46:09 GMT, Andrew Dinn wrote: >> src/hotspot/share/runtime/sharedRuntime.hpp line 736: >> >>> 734: } >>> 735: >>> 736: address get_i2c_entry() const { return _adapter_blob != nullptr ? _adapter_blob->i2c_entry() : nullptr; } >> >> Should these getters assert `_adapter_blob != nullptr`? >> I think we should only ever have an AdapterHandlerEntry with a null blob on ZERO and in that case an attempt to use the entry would be invalid. > > n.b. I guess that would require modifying `print_adapter_on` to check the adapter blob and avoid calling the entry lookup methods/printing the entry address details. It normally gets called when we have a known entry address as a starting point to look up an adapter handle but it is also called from `print_adapter_handler_info` when we may have a handler with a null blob. > I updated the code to add the assert for non ZERO builds Should these getters assert _adapter_blob != nullptr? Also updated `print_adapter_on` to do a null check on adapter_blob. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27101#discussion_r2370148096 From vpaprotski at openjdk.org Mon Sep 22 20:43:12 2025 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Mon, 22 Sep 2025 20:43:12 GMT Subject: RFR: 8367611: Enable vblendvp[sd] on Future ECore [v3] In-Reply-To: References: <_Jk5fv1iO9ZPZyOtUAXeUez481RibKJR4FsUT_BnKm8=.2f68f9ee-9ce2-4dbb-be8b-1b9f910ba0e0@github.com> Message-ID: On Fri, 19 Sep 2025 21:57:30 GMT, Mohamed Issa wrote: >> The upcoming ECore platforms will benefit from using `vblendvps` and `vblendvpd` instructions when the destination register is the same as the source register. This change takes that situation into account. >> >> The JTREG test shown below was used to verify correctness against the [OpenJDK v26-b15](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B15) baseline build. This test frequently calls vblendvps() and vblendvpd() in the macro assembler. On Darkmont and non-Darkmont cores, the right code paths are followed when checking with asserts. >> >> 1. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` > > Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: > > Combine boolean flags to avoid ambiguity (missed making my last comment an 'approve') ------------- Marked as reviewed by vpaprotski (Committer). PR Review: https://git.openjdk.org/jdk/pull/27354#pullrequestreview-3255112336 From missa at openjdk.org Mon Sep 22 20:43:12 2025 From: missa at openjdk.org (Mohamed Issa) Date: Mon, 22 Sep 2025 20:43:12 GMT Subject: RFR: 8367611: Enable vblendvp[sd] on Future ECore [v3] In-Reply-To: References: <_Jk5fv1iO9ZPZyOtUAXeUez481RibKJR4FsUT_BnKm8=.2f68f9ee-9ce2-4dbb-be8b-1b9f910ba0e0@github.com> Message-ID: On Fri, 19 Sep 2025 21:57:30 GMT, Mohamed Issa wrote: >> The upcoming ECore platforms will benefit from using `vblendvps` and `vblendvpd` instructions when the destination register is the same as the source register. This change takes that situation into account. >> >> The JTREG test shown below was used to verify correctness against the [OpenJDK v26-b15](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B15) baseline build. This test frequently calls vblendvps() and vblendvpd() in the macro assembler. On Darkmont and non-Darkmont cores, the right code paths are followed when checking with asserts. >> >> 1. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` > > Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: > > Combine boolean flags to avoid ambiguity @eme64 Could you launch tests for this one? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27354#issuecomment-3321415509 From cjplummer at openjdk.org Mon Sep 22 21:16:45 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 22 Sep 2025 21:16:45 GMT Subject: RFR: 8368159: Significant performance overhead when started with jdwp agent and unattached debugger [v2] In-Reply-To: References: Message-ID: On Sat, 20 Sep 2025 17:32:35 GMT, Leonid Mesnik wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> fix minimal build broken by incorrect macro usage > > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1622: > >> 1620: >> 1621: static void invalidate_jvmti_stack(JavaThread* thread) { >> 1622: if (JvmtiExport::can_post_frame_pop() || thread->is_interp_only_mode()) { > > Can you please explain why this change is required? Doesn't 'invalidate_cur_stack_depth' make sense only when interp_only mode is enabled for the threads only? > It is invalidated once thread switched to interp only. It seems odd to me that a method called `invalidate_jvmti_stack()` sometimes doesn't invalidate the stack. Even before this change it was not invalidating unless it was in interp_only mode, which also seems odd. If the cached value is not used for compiled frames, why bother with the interp_only check? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27403#discussion_r2370319721 From dholmes at openjdk.org Mon Sep 22 21:56:05 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 22 Sep 2025 21:56:05 GMT Subject: RFR: 8368303: AlwaysAtomicAccesses is excessively strict In-Reply-To: References: Message-ID: <1mIEZ6M1DXIOKeY50UTR46ES3d7BO-7GCwZ8fFVtcD4=.ea2a2b25-f225-4b58-914f-f5b15f0b30e0@github.com> On Mon, 22 Sep 2025 16:51:08 GMT, Andrew Haley wrote: > In C1, the experimental flag `AlwaysAtomicAccesses` treats accesses to all fields as if they were volatile fields. This is correct but excessive: we only need single-copy atomicity to satisfy `AlwaysAtomicAccesses`. > > We need this in order to allow progress on JDK-8365147. This flag also affects C2 - or did when it was introduced. Seems to me this flag is not really serving any useful purpose though - the JMM updates it was supposed to support evaluation of never eventuated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27432#issuecomment-3321609544 From kvn at openjdk.org Tue Sep 23 02:05:15 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 23 Sep 2025 02:05:15 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v10] In-Reply-To: References: Message-ID: On Sat, 20 Sep 2025 00:57:09 GMT, Ioi Lam wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @ashu-mehra comment - AOTLinkedClassBulkLoader::link_or_init_javabase_classes() should also call exit_on_exception() Few comments. src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 60: > 58: // Preloading requires that the Java heap objects of java.lang.Class, java.lang.Package and > 59: // java.security.ProtectionDomain already exist for the preloaded classes. Therefore, we support preloading > 60: // only for the classes in the static CDS archive. Classes in the dynamic archive are not supported because "for the classes in the static CDS archive"? Do you mean "AOT cache"? Or this feature also works for old static CDS archive? src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 97: > 95: } > 96: > 97: ClassLoaderData* loader_data = ClassLoaderData::class_loader_data(loader()); `loader_data` is not used in this method. src/hotspot/share/cds/aotLinkedClassBulkLoader.hpp line 52: > 50: // > 51: // [2] load_javabase_classes() and load_non_javabase_classes(): > 52: // This happens after some Java code is executed, to load aot-linked classes in the dynamic archive. Previous comment say that dynamic archive is not supported. src/hotspot/share/cds/aotLinkedClassTable.hpp line 45: > 43: > 44: Array* _boot1; // boot classes in java.base module > 45: Array* _boot2; // boot classes in all other (named and unnamed) modules Do you mean JDK's modules or user's modules too? ------------- PR Review: https://git.openjdk.org/jdk/pull/26375#pullrequestreview-3255743679 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2370759818 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2370778138 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2370797359 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2370798743 From kvn at openjdk.org Tue Sep 23 02:05:16 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 23 Sep 2025 02:05:16 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v10] In-Reply-To: References: Message-ID: <5Tw9z22Y6nsL7pGxDqShTXtMBnaaoWUAG1AjXOhUL2s=.104e2915-21b3-4474-8a12-2b4f435d268b@github.com> On Tue, 23 Sep 2025 01:18:29 GMT, Vladimir Kozlov wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @ashu-mehra comment - AOTLinkedClassBulkLoader::link_or_init_javabase_classes() should also call exit_on_exception() > > src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 60: > >> 58: // Preloading requires that the Java heap objects of java.lang.Class, java.lang.Package and >> 59: // java.security.ProtectionDomain already exist for the preloaded classes. Therefore, we support preloading >> 60: // only for the classes in the static CDS archive. Classes in the dynamic archive are not supported because > > "for the classes in the static CDS archive"? Do you mean "AOT cache"? Or this feature also works for old static CDS archive? I see `precond(CDSConfig::is_using_aot_linked_classes())` on following cod. Which means it only works for AOT cache. Please update comment to avoid confusion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2370761057 From iklam at openjdk.org Tue Sep 23 03:24:28 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 23 Sep 2025 03:24:28 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v11] In-Reply-To: References: Message-ID: > This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. > > - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. > - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. > - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: - @vnkozlov review comments - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - @ashu-mehra comment - AOTLinkedClassBulkLoader::link_or_init_javabase_classes() should also call exit_on_exception() - Fixed 32-bit builds - Removed JVMCI-specific checks that are no longer necessary with class preloading -- all CP entries discoverable by JVMCI will always point to already-loaded classes - Simplify implementation after JDK-8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap - @ashu-mehra comment: removed AOTLinkedClassBulkLoader::is_pending_aot_linked_class - @ashu-mehra review comments - ... and 21 more: https://git.openjdk.org/jdk/compare/61c5245b...bd08a0b5 ------------- Changes: https://git.openjdk.org/jdk/pull/26375/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26375&range=10 Stats: 941 lines in 43 files changed: 534 ins; 236 del; 171 mod Patch: https://git.openjdk.org/jdk/pull/26375.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26375/head:pull/26375 PR: https://git.openjdk.org/jdk/pull/26375 From iklam at openjdk.org Tue Sep 23 03:24:30 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 23 Sep 2025 03:24:30 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v10] In-Reply-To: <5Tw9z22Y6nsL7pGxDqShTXtMBnaaoWUAG1AjXOhUL2s=.104e2915-21b3-4474-8a12-2b4f435d268b@github.com> References: <5Tw9z22Y6nsL7pGxDqShTXtMBnaaoWUAG1AjXOhUL2s=.104e2915-21b3-4474-8a12-2b4f435d268b@github.com> Message-ID: On Tue, 23 Sep 2025 01:19:59 GMT, Vladimir Kozlov wrote: >> src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 60: >> >>> 58: // Preloading requires that the Java heap objects of java.lang.Class, java.lang.Package and >>> 59: // java.security.ProtectionDomain already exist for the preloaded classes. Therefore, we support preloading >>> 60: // only for the classes in the static CDS archive. Classes in the dynamic archive are not supported because >> >> "for the classes in the static CDS archive"? Do you mean "AOT cache"? Or this feature also works for old static CDS archive? > > I see `precond(CDSConfig::is_using_aot_linked_classes())` on following cod. Which means it only works for AOT cache. Please update comment to avoid confusion. AOTClassLinking for the dynamic archive has been removed in [JDK-8367366](https://bugs.openjdk.org/browse/JDK-8367366). Currently, AOT-linked classes are supported for both the static archive and AOT cache. I've updated the comments to reflect that. We probably should remove AOTClassLinking from static CDS archive as well. I've created [JDK-8368350](https://bugs.openjdk.org/browse/JDK-8368350) for that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2370946875 From iklam at openjdk.org Tue Sep 23 03:24:34 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 23 Sep 2025 03:24:34 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v10] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 01:29:00 GMT, Vladimir Kozlov wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @ashu-mehra comment - AOTLinkedClassBulkLoader::link_or_init_javabase_classes() should also call exit_on_exception() > > src/hotspot/share/cds/aotLinkedClassBulkLoader.cpp line 97: > >> 95: } >> 96: >> 97: ClassLoaderData* loader_data = ClassLoaderData::class_loader_data(loader()); > > `loader_data` is not used in this method. Removed. > src/hotspot/share/cds/aotLinkedClassBulkLoader.hpp line 52: > >> 50: // >> 51: // [2] load_javabase_classes() and load_non_javabase_classes(): >> 52: // This happens after some Java code is executed, to load aot-linked classes in the dynamic archive. > > Previous comment say that dynamic archive is not supported. That comment was written before AOTClassLinking was removed from dynamic archive. I have removed it. I also added a comment about the new `link_or_init_xxx()` functions added in this PR. > src/hotspot/share/cds/aotLinkedClassTable.hpp line 45: > >> 43: >> 44: Array* _boot1; // boot classes in java.base module >> 45: Array* _boot2; // boot classes in all other (named and unnamed) modules > > Do you mean JDK's modules or user's modules too? Currently it's not possible to use `--module-path` to add user modules to the boot loader, so the only kind of user classes that can be loaded in `boot2` are the ones from `-Xbootclasspath/a`, which are loaded from the unnamed module. I updated the comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2370946983 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2370947364 PR Review Comment: https://git.openjdk.org/jdk/pull/26375#discussion_r2370948225 From sspitsyn at openjdk.org Tue Sep 23 04:26:29 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 23 Sep 2025 04:26:29 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 08:02:57 GMT, Johan Sj?len wrote: >> Hi, >> >> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array` to store the offsets in and an `Array` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`. >> >> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately. >> >> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc. >> >> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement. >> >> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again. > > Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision: > > - Merge remote-tracking branch 'origin/operands-again' into operands-again > - Fix BSM naming src/hotspot/share/oops/constantPool.hpp line 116: > 114: return _argument_count; > 115: } > 116: int argument(int n) const { Q: Why was the function name changed? src/hotspot/share/oops/constantPool.hpp line 139: > 137: int _cur_offset; > 138: // Current unused offset into BSMAEs bsm-data array > 139: int _cur_array; Nit: I'd suggest to rename this to something like `_cur_bsm_entry`. src/hotspot/share/prims/jvmtiRedefineClasses.hpp line 440: > 438: int append_bsm_entry(const constantPoolHandle& scratch_cp, int scratch_bootstrap_spec_index, > 439: constantPoolHandle *merge_cp_p, int *merge_cp_length_p); > 440: void finalize_bsmentries_merge(const constantPoolHandle& merge_cp, TRAPS); Nit: A suggestion to rename: `finalize_bsmentries_merge` => `finalize_bsm_entries_merge` src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java line 95: > 93: Type bsmaetype = db.lookupType("BSMAttributeEntries"); > 94: bsmaentries_offsets = bsmaetype.getAddressField("_offsets"); > 95: bsmaentries_bootstrap_methods = bsmaetype.getAddressField("_bootstrap_methods"); Nit: A suggestion to rename: `bsmaentries` => `bsma_entries` or `bsm_entries` `bsmaetype` => `bsma_type` or `bsm_type` `bsmaentries_offsets` => `bsma_entries_offsets` or `bsm_entries_offsets` `bsmaentries_bootstrap_methods` => `bsma_entries_bootstrap_methods` or `bsm_entries_bootstrap_methods` src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java line 122: > 120: private static long bsmaentries; // Offset in the constantpool where the BSMAEntries are found > 121: private static AddressField bsmaentries_offsets; > 122: private static AddressField bsmaentries_bootstrap_methods; Nit: Same renaming suggestion as above. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java line 482: > 480: int basePos = offs.at(bsmIndex); > 481: int argv = basePos + INDY_ARGV_OFFSET; > 482: int argc = getBootstrapMethodArgsCount(bsmIndex); Nit: Consider to make it shorter: `getBootstrapMethods` => `getBSMs` `getBootstrapMethodArgsCount` => `getBSMArgsCount` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2371074352 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2371075707 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2371078749 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2371084318 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2371084929 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2371087738 From sspitsyn at openjdk.org Tue Sep 23 04:33:42 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 23 Sep 2025 04:33:42 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 08:02:57 GMT, Johan Sj?len wrote: >> Hi, >> >> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array` to store the offsets in and an `Array` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`. >> >> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately. >> >> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc. >> >> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement. >> >> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again. > > Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision: > > - Merge remote-tracking branch 'origin/operands-again' into operands-again > - Fix BSM naming src/hotspot/share/oops/constantPool.hpp line 128: > 126: > 127: // The BSMAttributeEntries stores the state of the BootstrapMethods attribute. > 128: class BSMAttributeEntries { Nit: I'm thinking if it would make sense to rename it to `BSMEntries`. Then we could rename this as well: `BSMAttributeEntry` => `BSMEntry`. It feels like it will increase the readability as it is already clear that `BSMEntry` is about `BSM` attributes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2371104606 From sspitsyn at openjdk.org Tue Sep 23 04:42:43 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 23 Sep 2025 04:42:43 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 08:02:57 GMT, Johan Sj?len wrote: >> Hi, >> >> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array` to store the offsets in and an `Array` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`. >> >> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately. >> >> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc. >> >> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement. >> >> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again. > > Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision: > > - Merge remote-tracking branch 'origin/operands-again' into operands-again > - Fix BSM naming src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 393: > 391: void JvmtiClassFileReconstituter::write_bootstrapmethod_attribute() { > 392: write_attribute_name_index("BootstrapMethods"); > 393: u4 length = sizeof(u2) + // Size of num_bootstrap_methods Nit: The comment update is confusing. Should it remain as it was? : u4 length = sizeof(u2); // num_bootstrap_methods ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2371115648 From dholmes at openjdk.org Tue Sep 23 05:46:40 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 23 Sep 2025 05:46:40 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final In-Reply-To: References: Message-ID: <_p9u9mX5mBTeHuKdLY3uATLLs-hrHENJleIpMN2mMko=.6a686db2-314c-4b76-8876-d94558fbbd41@github.com> On Thu, 8 May 2025 11:22:30 GMT, Alan Bateman wrote: > Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500). > > Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP. > > HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX). > > There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package. > > Testing: tier1-6 Hotspot changes are okay in principle but the JNI checks could be more streamlined to avoid duplication. There is also a more general cleanup of `Klass*` versus `InstanceKlass*` that simplifies things somewhat, though much of that would be external to this PR. src/hotspot/share/prims/jni.cpp line 1870: > 1868: } > 1869: > 1870: static void log_debug_if_final_static_field(JavaThread* thread, const char* func_name, Klass* klass, int offset) { If `thread` is required to be the current thread, please call it `current`. src/hotspot/share/prims/jni.cpp line 1873: > 1871: if (log_is_enabled(Debug, jni)) { > 1872: fieldDescriptor fd; > 1873: bool found = InstanceKlass::cast(klass)->find_field_from_offset(offset, true, &fd); If you are assuming/expecting an `InstanceKlass` then that should be the type of the parameter. (The existing code needs a cleanup in this area too but that is outside the scope of this PR.) src/hotspot/share/prims/jniCheck.cpp line 1224: > 1222: WRAPPER_GetField(jdouble, Double, T_DOUBLE) > 1223: > 1224: static void checkCanSetInstanceField(JavaThread* thr, jfieldID fid, jobject obj) { There is a lot of duplication here with logic already performed in `checkInstanceFieldID` - can you not just pass an extra argument `is_set` to that and include the new checks there? And similarly for the static case. src/hotspot/share/runtime/fieldDescriptor.cpp line 53: > 51: // write protected fields (JLS 17.5.4) > 52: if (is_final() && is_static() && ik == vmClasses::System_klass() && > 53: (offset() == java_lang_System::in_offset() || offset() == java_lang_System::out_offset() || offset() == java_lang_System::err_offset())) { I thought the ability to mutate these fields was restricted to the native implementations of `setIn` et al. and was not allowed via regular reflection? Otherwise how can these fields be considered as "trusted finals"?? test/jdk/java/lang/reflect/Field/mutateFinals/jni/JNIAttachMutatorTest.java line 29: > 27: * @summary Test native thread attaching to the VM with JNI AttachCurrentThread and directly > 28: * invoking Field.set to set a final field > 29: * @requires (os.family == "linux" | os.family == "mac") This test should work for any non-Windows platform using pthreads. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25115#pullrequestreview-3256235026 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2371150541 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2371151309 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2371182004 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2371207094 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2371211878 From stuefe at openjdk.org Tue Sep 23 05:49:17 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 23 Sep 2025 05:49:17 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v2] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 06:15:20 GMT, David Holmes wrote: > I see now in JBS that you say you don't know why what we have doesn't work for ASAN, but I think we need to determine that. Hmm, I see in glibc that they also do prctl; int __pthread_setname_np (pthread_t th, const char *name) { const struct pthread *pd = (const struct pthread *) th; /* Unfortunately the kernel headers do not export the TASK_COMM_LEN macro. So we have to define it here. */ #define TASK_COMM_LEN 16 size_t name_len = strlen (name); if (name_len >= TASK_COMM_LEN) return ERANGE; if (pd == THREAD_SELF) return __prctl (PR_SET_NAME, name) ? errno : 0; #define FMT "/proc/self/task/%u/comm" char fname[sizeof (FMT) + 8]; sprintf (fname, FMT, (unsigned int) pd->tid); int fd = __open64_nocancel (fname, O_RDWR); if (fd == -1) return errno; int res = 0; ssize_t n = TEMP_FAILURE_RETRY (__write_nocancel (fd, name, name_len)); if (n < 0) res = errno; else if (n != name_len) res = EIO; __close_nocancel_nostatus (fd); return res; } No idea why this doesn't work on my machines. I run Fedora 42 and Debian 12. Will look a bit deeper. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27395#discussion_r2371223381 From swen at openjdk.org Tue Sep 23 06:47:37 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 23 Sep 2025 06:47:37 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final In-Reply-To: References: Message-ID: On Thu, 8 May 2025 11:22:30 GMT, Alan Bateman wrote: > Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500). > > Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP. > > HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX). > > There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package. > > Testing: tier1-6 Duplicate Code in Field.java In the java.lang.reflect.Field class, the set* methods (such as set, setBoolean, setByte, etc.) contain a lot of duplicate code for handling access control of final fields. Recommendation: Consider creating a generic helper method to handle the access control check for final fields, thus reducing code duplication. @CallerSensitive @ForceInline // to ensure Reflection.getCallerClass optimization public void set(Object obj, Object value) throws IllegalArgumentException, IllegalAccessException { handleFinalFieldModification( Reflection.getCallerClass(), obj, () -> getOverrideFieldAccessor() .set(obj, value)); } @CallerSensitive @ForceInline // to ensure Reflection.getCallerClass optimization public void setBoolean(Object obj, boolean z) throws IllegalArgumentException, IllegalAccessException { handleFinalFieldModification( Reflection.getCallerClass(), obj, () -> getOverrideFieldAccessor() .setBoolean(obj, z)); } @CallerSensitive @ForceInline // to ensure Reflection.getCallerClass optimization public void setByte(Object obj, byte b) throws IllegalArgumentException, IllegalAccessException { handleFinalFieldModification( Reflection.getCallerClass(), obj, () -> getOverrideFieldAccessor() .setByte(obj, b)); } @CallerSensitive @ForceInline // to ensure Reflection.getCallerClass optimization public void setChar(Object obj, char c) throws IllegalArgumentException, IllegalAccessException { handleFinalFieldModification( Reflection.getCallerClass(), obj, () -> getOverrideFieldAccessor() .setChar(obj, c)); } @CallerSensitive @ForceInline // to ensure Reflection.getCallerClass optimization public void setShort(Object obj, short s) throws IllegalArgumentException, IllegalAccessException { handleFinalFieldModification( Reflection.getCallerClass(), obj, () -> getOverrideFieldAccessor() .setShort(obj, s)); } @CallerSensitive @ForceInline // to ensure Reflection.getCallerClass optimization public void setInt(Object obj, int i) throws IllegalArgumentException, IllegalAccessException { handleFinalFieldModification( Reflection.getCallerClass(), obj, () -> getOverrideFieldAccessor() .setInt(obj, i)); } @CallerSensitive @ForceInline // to ensure Reflection.getCallerClass optimization public void setLong(Object obj, long l) throws IllegalArgumentException, IllegalAccessException { handleFinalFieldModification( Reflection.getCallerClass(), obj, () -> getOverrideFieldAccessor() .setLong(obj, l)); } @CallerSensitive @ForceInline // to ensure Reflection.getCallerClass optimization public void setFloat(Object obj, float f) throws IllegalArgumentException, IllegalAccessException { handleFinalFieldModification( Reflection.getCallerClass(), obj, () -> getOverrideFieldAccessor() .setFloat(obj, f)); } @CallerSensitive @ForceInline // to ensure Reflection.getCallerClass optimization public void setDouble(Object obj, double d) throws IllegalArgumentException, IllegalAccessException { handleFinalFieldModification( Reflection.getCallerClass(), obj, () -> getOverrideFieldAccessor() .setDouble(obj, d)); } private interface Setter { void run() throws IllegalAccessException; } @ForceInline private void handleFinalFieldModification(Class callerClass, Object obj, Setter setter) throws IllegalAccessException { if (!override) { checkAccess(callerClass, obj); setter.run(); return; } if (!isFinalInstanceInNormalClass()) { setter.run(); return; } // final field in normal class handling preSetFinal(callerClass, obj); setter.run(); postSetFinal(callerClass); } ------------- PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3322635579 From mhaessig at openjdk.org Tue Sep 23 06:54:52 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Tue, 23 Sep 2025 06:54:52 GMT Subject: RFR: 8367611: Enable vblendvp[sd] on Future ECore [v3] In-Reply-To: References: <_Jk5fv1iO9ZPZyOtUAXeUez481RibKJR4FsUT_BnKm8=.2f68f9ee-9ce2-4dbb-be8b-1b9f910ba0e0@github.com> Message-ID: On Fri, 19 Sep 2025 21:57:30 GMT, Mohamed Issa wrote: >> The upcoming ECore platforms will benefit from using `vblendvps` and `vblendvpd` instructions when the destination register is the same as the source register. This change takes that situation into account. >> >> The JTREG test shown below was used to verify correctness against the [OpenJDK v26-b15](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B15) baseline build. This test frequently calls vblendvps() and vblendvpd() in the macro assembler. On Darkmont and non-Darkmont cores, the right code paths are followed when checking with asserts. >> >> 1. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` > > Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: > > Combine boolean flags to avoid ambiguity > @eme64 Could you launch tests for this one? Emanuel is on vacation. I ran the tests in the background and they passed. ------------- Marked as reviewed by mhaessig (Committer). PR Review: https://git.openjdk.org/jdk/pull/27354#pullrequestreview-3256500013 From aboldtch at openjdk.org Tue Sep 23 07:15:26 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 23 Sep 2025 07:15:26 GMT Subject: RFR: 8368214: ZGC: Remove double newlines In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 05:59:47 GMT, Axel Boldt-Christmas wrote: > We avoid having two empty newlines in a row. But we have a hand full. Trivial change to remove them. Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27417#issuecomment-3322707834 From aboldtch at openjdk.org Tue Sep 23 07:15:27 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 23 Sep 2025 07:15:27 GMT Subject: Integrated: 8368214: ZGC: Remove double newlines In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 05:59:47 GMT, Axel Boldt-Christmas wrote: > We avoid having two empty newlines in a row. But we have a hand full. Trivial change to remove them. This pull request has now been integrated. Changeset: 43531064 Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/43531064c290928cbbac9ee3662674a0ea3b0240 Stats: 18 lines in 14 files changed: 0 ins; 18 del; 0 mod 8368214: ZGC: Remove double newlines Reviewed-by: stefank, jsikstro ------------- PR: https://git.openjdk.org/jdk/pull/27417 From fyang at openjdk.org Tue Sep 23 07:29:50 2025 From: fyang at openjdk.org (Fei Yang) Date: Tue, 23 Sep 2025 07:29:50 GMT Subject: RFR: 8368366: RISC-V: AlignVector is mistakenly set to AvoidUnalignedAccesses Message-ID: Hi, please consider this small change fixing setting of `AlignVector` flag. According to the latest RISC-V linux hardware probing syscall [1], the performance of misaligned memory accesses has been divided into two cases: `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` and `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` for scalar and vector respectively. And `RISCV_HWPROBE_KEY_CPUPERF_0` is now deprecated and it now returns similar values to `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`. Previously, we use `RISCV_HWPROBE_KEY_CPUPERF_0` to detect support for misaligned memory accesses and reflect the result on VM flags like `AvoidUnalignedAccesses`, `UseUnalignedAccesses` and `AlignVector`. But it doesn't seem correct to update AlignVector according to this value. And this is causing issues on hardwares which have fast misaligned accesses only for scalar. I see they will trigger SIGBUG error in the case of vector misaligned accesses. So we should align AlignVector with `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` instead. This patch just reverts the previous setting of AlignVector and just let it have the default value which is true. I will try to add detection in a separate PR for `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` and update `AlignVector` accordingly. [1] https://docs.kernel.org/arch/riscv/hwprobe.html ------------- Commit messages: - 8368366: RISC-V: AlignVector is mistakenly set to AvoidUnalignedAccesses Changes: https://git.openjdk.org/jdk/pull/27445/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27445&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368366 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27445.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27445/head:pull/27445 PR: https://git.openjdk.org/jdk/pull/27445 From fyang at openjdk.org Tue Sep 23 07:31:28 2025 From: fyang at openjdk.org (Fei Yang) Date: Tue, 23 Sep 2025 07:31:28 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v4] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 08:29:01 GMT, Hamlin Li wrote: >> src/hotspot/cpu/riscv/vm_version_riscv.hpp line 238: >> >>> 236: decl(ext_Zvfh , Zvfh , RV_NO_FLAG_BIT, 30, true , UPDATE_DEFAULT_DEP(UseZvfh, ext_V)) \ >>> 237: decl(ext_Zvkn , Zvkn , RV_NO_FLAG_BIT, 31, true , UPDATE_DEFAULT_DEP(UseZvkn, ext_V)) \ >>> 238: decl(ext_Zicond , Zicond , RV_NO_FLAG_BIT, 32, true , UPDATE_DEFAULT(UseZicond)) \ >> >> I assume the `cpu feature index` field is not subject to change in the future when we have AOT support, right? Then I think the code will be cleaner if we group these features in aphabetic order before that. > > There is dependency between some extensions, which enforce some order not subject to this constraint. So, not sure if it's an good idea to force the aphabetic order, especailly in this pr. > If you think it's necessary to do so, I can do it in another separate pr, and I hope to do it after https://github.com/openjdk/jdk/pull/27171. Sure. That works for me. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2371427726 From adinn at openjdk.org Tue Sep 23 07:39:40 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 23 Sep 2025 07:39:40 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry [v4] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 19:55:09 GMT, Ashutosh Mehra wrote: >> This PR removes the need to store entry point addresses in AdapterHandlerEntry by storing a direct pointer to AdapterBlob instead. Entry point addresses can be computed on the fly from the entry point offsets stored in AdapterBlob. > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Address adinn's review comments > > Signed-off-by: Ashutosh Mehra Good. ------------- Marked as reviewed by adinn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27101#pullrequestreview-3256660028 From fjiang at openjdk.org Tue Sep 23 07:45:02 2025 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 23 Sep 2025 07:45:02 GMT Subject: RFR: 8368366: RISC-V: AlignVector is mistakenly set to AvoidUnalignedAccesses In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 07:21:47 GMT, Fei Yang wrote: > Hi, please consider this small change fixing setting of `AlignVector` flag on RISC-V. > > According to the latest RISC-V linux hardware probing syscall [1], the performance of misaligned memory accesses > has been divided into two cases: `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` and `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` > for scalar and vector respectively. And `RISCV_HWPROBE_KEY_CPUPERF_0` is now deprecated and it returns similar values > to `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`. > > Previously, we use `RISCV_HWPROBE_KEY_CPUPERF_0` to detect support for misaligned memory accesses and reflect the result > on these VM flags: `AvoidUnalignedAccesses`, `UseUnalignedAccesses` and `AlignVector`. But it doesn't seem correct to update > `AlignVector` according to this value. And this is causing issues on RISC-V hardwares which have fast misaligned accesses only > for the scalar case. I witnessed SIGBUG error on these hardwares in the case of vector misaligned accesses. > > So we should align AlignVector with `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` instead. This patch just reverts the previous > setting of AlignVector and just let it have the default value which is true. I will try to add detection in a separate PR > for `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` and update `AlignVector` accordingly. > > [1] https://docs.kernel.org/arch/riscv/hwprobe.html Thanks for finding this! ------------- Marked as reviewed by fjiang (Committer). PR Review: https://git.openjdk.org/jdk/pull/27445#pullrequestreview-3256678974 From adinn at openjdk.org Tue Sep 23 08:13:55 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 23 Sep 2025 08:13:55 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v4] In-Reply-To: <3YcffjFi1BYw2B5BGUywyv0H_0ASrWgSPxvJaGTbfhg=.c83cf0f0-c0dc-460b-add2-decaf841383e@github.com> References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> <3YcffjFi1BYw2B5BGUywyv0H_0ASrWgSPxvJaGTbfhg=.c83cf0f0-c0dc-460b-add2-decaf841383e@github.com> Message-ID: On Wed, 17 Sep 2025 06:15:25 GMT, Amit Kumar wrote: >> Ruben has updated the pull request incrementally with two additional commits since the last revision: >> >> - Offset the deoptimization handler entry point >> >> Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722 >> - Revert "Ensure stub code is not adjacent to a call" > > on s390, I see couple of test failure with: > > > # Internal Error (/home/amit/jdk/src/hotspot/share/code/nmethod.cpp:669), pid=574704, tid=574714 > # guarantee(pd != nullptr) failed: scope must be present > > # Problematic frame: > # V [libjvm.so+0x11253f4] nmethod::scope_desc_at(unsigned char*)+0x14c > > > BT: > > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x11253f4] nmethod::scope_desc_at(unsigned char*)+0x14c (nmethod.cpp:669) > V [libjvm.so+0x159b46c] compiledVFrame::compiledVFrame(frame const*, RegisterMap const*, JavaThread*, nmethod*)+0x6c (vframe_hp.cpp:305) > V [libjvm.so+0x158f354] vframe::new_vframe(frame const*, RegisterMap const*, JavaThread*) [clone .part.0]+0x5c (vframe.cpp:75) > V [libjvm.so+0x825f42] Deoptimization::fetch_unroll_info_helper(JavaThread*, int)+0x222 (deoptimization.cpp:517) > V [libjvm.so+0x827214] Deoptimization::fetch_unroll_info(JavaThread*, int)+0x64 (deoptimization.cpp:299) > v ~DeoptimizationBlob 0x000003ffa064fb92 > J 265 c2 java.net.URL.(Ljava/lang/String;Ljava/lang/String;ILjava/lang/String;Ljava/net/URLStreamHandler;)V java.base at 26-internal (417 bytes) @ 0x000003ffa066b08c [0x000003ffa066a680+0x0000000000000a0c] > J 256 c2 sun.net.www.ParseUtil.fileToEncodedURL(Ljava/io/File;)Ljava/net/URL; java.base at 26-internal (90 bytes) @ 0x000003ffa06688a0 [0x000003ffa0668740+0x0000000000000160] > j jdk.internal.loader.URLClassPath.toFileURL(Ljava/lang/String;)Ljava/net/URL;+13 java.base at 26-internal > j jdk.internal.loader.URLClassPath.(Ljava/lang/String;Z)V+96 java.base at 26-internal > j jdk.internal.loader.ClassLoaders.()V+153 java.base at 26-internal > v ~StubRoutines::Stub Generator call_stub_stub 0x000003ffa0500adc > C 0x000003ffb07ff840 > V [libjvm.so+0xbec91a] JavaCalls::call(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x42 (javaCalls.cpp:323) > V [libjvm.so+0xb9a602] InstanceKlass::call_class_initializer(JavaThread*)+0x2ba (instanceKlass.cpp:1713) > V [libjvm.so+0xb9dcec] InstanceKlass::initialize_impl(JavaThread*)+0x60c (instanceKlass.cpp:1321) > V [libjvm.so+0xb9e2ea] InstanceKlass::initialize(JavaThread*)+0xb2 (instanceKlass.cpp:819) > V [libjvm.so+0xf337f6] LinkResolver::resolve_static_call(CallInfo&, LinkInfo const&, bool, JavaThread*)+0xce (linkResolver.cpp:1115) > V [libjvm.so+0xf33ad0] LinkResolver::resolve_invokestatic(CallInfo&, constantPoolHandle const&, int, JavaThread*)+0x88 (linkResolver.cpp:1744) > V [libjvm.so+0xf377e4] LinkRes... @offamitkumar That error means one of two different things. It could mean that the pc pulled out of the compiledVFrame and passed into nmethod::scope_desc_at is invalid (i.e. does not lie in the range of the nmethod code). Alternatively, it could be that the pc is correct but array of PcDesc objects installed when the nmethod was created does not contain an entry for that pc. The former problem would indicate that the frame code or frame unroll helper need updating to deal with the change in how the the deopt stub is entered. The latter would indicate some issue at compile time recording the entry into the deopt stub from the handler stub embedded at the end of the method. The best way to find out is to reproduce the error in a debug build and see what happens when nmethod::scope_desc_at calls nmethod::pc_desc_at. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3322876364 From iwalulya at openjdk.org Tue Sep 23 08:18:20 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 23 Sep 2025 08:18:20 GMT Subject: RFR: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown [v10] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 12:05:22 GMT, Ivan Walulya wrote: >> Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. >> >> Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. >> >> Testing: Tier 1-7 > > Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision: > > Albert suggestion Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27190#issuecomment-3322892504 From iwalulya at openjdk.org Tue Sep 23 08:22:42 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 23 Sep 2025 08:22:42 GMT Subject: Integrated: 8366865: Allocation GC Pauses Triggered after JVM has started shutdown In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 09:57:18 GMT, Ivan Walulya wrote: > Please review this patch to skip VM_GC_Collect_Operations if initiated after the VM shutdown process has begun. We add a _is_shutting_down flag to CollectedHeap, which is set while holding the Heap_lock. This ensures mutual exclusion with VM_GC_Collect_Operations, which also require the Heap_lock. > > Skipping VM_GC_Collect_Operation would otherwise cause allocation requests to fail (resulting in OutOfMemoryError) if requesting daemon threads were allowed to continue, we instead block these threads on a monitor. They remain stalled until they are terminated as part of the VM shutdown sequence. > > Testing: Tier 1-7 This pull request has now been integrated. Changeset: 3e5094ed Author: Ivan Walulya URL: https://git.openjdk.org/jdk/commit/3e5094ed12dbfad7587b85ae2168565682c1f1db Stats: 100 lines in 15 files changed: 73 ins; 20 del; 7 mod 8366865: Allocation GC Pauses Triggered after JVM has started shutdown Reviewed-by: ayang, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/27190 From mdoerr at openjdk.org Tue Sep 23 08:30:10 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 23 Sep 2025 08:30:10 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v4] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Fri, 12 Sep 2025 16:36:56 GMT, Ruben wrote: >> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. >> >> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. > > Ruben has updated the pull request incrementally with two additional commits since the last revision: > > - Offset the deoptimization handler entry point > > Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722 > - Revert "Ensure stub code is not adjacent to a call" I guess that the previous version also works on s390 like on ppc64 (with the old deopt handlers). ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3322930604 From tschatzl at openjdk.org Tue Sep 23 08:36:31 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 23 Sep 2025 08:36:31 GMT Subject: RFR: 8363932: G1: Better distribute KlassCleaningTask [v2] In-Reply-To: References: <4wv4YEc8jXOrh142RF4lbiAOx5HSEe8tcDc-BYQC-5I=.461e968b-21dd-493e-9dfb-dcc9f962700a@github.com> Message-ID: <_KqKV0-WVNs8HnTyp-jAjZe8VGJ5zpTC5CjDsKEX27A=.6fc935b0-493f-426d-8e9c-f1a84f3b5eb2@github.com> On Mon, 22 Sep 2025 08:04:30 GMT, Albert Mingkun Yang wrote: > Preexisting: These two methods, `subklass` and `next_sibling`, sounds like plain getters, but they actually query liveness and skip dead klasses. I wonder whether it's possible to prune dead klasses in one go at some place and turn these two methods into plain getters. In my limited understanding of this part of the VM, apart from renaming them, I do not see a good way to improve the code. The klass graph walks may be concurrent to removing them, so at best the dead links could be ignored. The current implementation fixes them up at the same time as walking as well, which is arguable either way to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27316#issuecomment-3322952079 From jbhateja at openjdk.org Tue Sep 23 09:25:33 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 23 Sep 2025 09:25:33 GMT Subject: RFR: 8367611: Enable vblendvp[sd] on Future ECore [v3] In-Reply-To: References: <_Jk5fv1iO9ZPZyOtUAXeUez481RibKJR4FsUT_BnKm8=.2f68f9ee-9ce2-4dbb-be8b-1b9f910ba0e0@github.com> Message-ID: On Mon, 22 Sep 2025 20:40:11 GMT, Mohamed Issa wrote: >> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: >> >> Combine boolean flags to avoid ambiguity > > @eme64 Could you launch tests for this one? Hi @missa-prime , VBLENDVPS was always supported by AVX2 targets. We enabled its software emulation for performance reasons, as these needs microcode assistance on AVX2 targets. image It seems your PR is lifting this limitation for Darkmont under a constraint on dst and src1 register equivalence? Please add appropriate comments in code and documentary reference to the relevant section of the Intel Architectural Set Extension Manual. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27354#issuecomment-3323108638 From stuefe at openjdk.org Tue Sep 23 09:27:32 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 23 Sep 2025 09:27:32 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps Message-ID: When we run with ASAN enabled and ASAN catches an error, it reports, then stops the JVM. hs-err files and crash dumps at that point would be incredibly useful, though. The ASAN error report itself is seldom enlightening since it only contains native stacks. This patch makes it possible to get hs-err files and subsequent crash dumps by using the error callback functionality of ASAN. It registers a callback which gets called when ASAN catches an error. We then - carefully - print out the ASAN report to stderr (as ASAN itself would have done) and proceeed to end the JVM with a `fatal()`, which gives us an hs-err file, a callstack at that point including Java frames, and - if enabled - core dumps. Tested on Fedora 42 and Debian 12, both manually and by running the new companion jtreg test. ------------- Commit messages: - remove stray modification - stupid sort includes test - add jtreg test - fix error in non-asan build - start Changes: https://git.openjdk.org/jdk/pull/27446/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27446&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368365 Stats: 191 lines in 7 files changed: 189 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27446.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27446/head:pull/27446 PR: https://git.openjdk.org/jdk/pull/27446 From krk at openjdk.org Tue Sep 23 10:08:29 2025 From: krk at openjdk.org (Kerem Kat) Date: Tue, 23 Sep 2025 10:08:29 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 07:37:12 GMT, Thomas Stuefe wrote: > When we run with ASAN enabled and ASAN catches an error, it reports, then stops the JVM. hs-err files and crash dumps at that point would be incredibly useful, though. The ASAN error report itself is seldom enlightening since it only contains native stacks. > > This patch makes it possible to get hs-err files and subsequent crash dumps by using the error callback functionality of ASAN. It registers a callback which gets called when ASAN catches an error. We then - carefully - print out the ASAN report to stderr (as ASAN itself would have done) and proceeed to end the JVM with a `fatal()`, which gives us an hs-err file, a callstack at that point including Java frames, and - if enabled - core dumps. > > Tested on Fedora 42 and Debian 12, both manually and by running the new companion jtreg test. Changes requested by krk (no project role). src/hotspot/share/sanitizers/address.cpp line 65: > 63: log_info(asan)("*** Failed to install JVM callback for ASAN. ASAN errors will not generate hs-err files. ***"); > 64: } > 65: //__asan_set_error_report_callback(asan_error_callback); Commented code from debugging? ------------- PR Review: https://git.openjdk.org/jdk/pull/27446#pullrequestreview-3257176050 PR Review Comment: https://git.openjdk.org/jdk/pull/27446#discussion_r2371790409 From aph at openjdk.org Tue Sep 23 10:25:31 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 23 Sep 2025 10:25:31 GMT Subject: RFR: 8368303: AlwaysAtomicAccesses is excessively strict In-Reply-To: <1mIEZ6M1DXIOKeY50UTR46ES3d7BO-7GCwZ8fFVtcD4=.ea2a2b25-f225-4b58-914f-f5b15f0b30e0@github.com> References: <1mIEZ6M1DXIOKeY50UTR46ES3d7BO-7GCwZ8fFVtcD4=.ea2a2b25-f225-4b58-914f-f5b15f0b30e0@github.com> Message-ID: On Mon, 22 Sep 2025 21:53:29 GMT, David Holmes wrote: > This flag also affects C2 - or did when it was introduced. The C2 handling is not too strict, it's fine. > Seems to me this flag is not really serving any useful purpose though - the JMM updates it was supposed to support evaluation of never eventuated. It still has some uses. Quoth @shipilev, "For example, for 64-bit longs on 32-bit platforms, and/or more recently, in Valhalla. I think the flag should stay at least until Valhalla sticks with a particular access atomicity story." ------------- PR Comment: https://git.openjdk.org/jdk/pull/27432#issuecomment-3323362710 From jbhateja at openjdk.org Tue Sep 23 10:41:25 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 23 Sep 2025 10:41:25 GMT Subject: RFR: 8367780: Enable UseAPX on Intel CPUs only when both APX_F and APX_NCI_NDD_NF cpuid features are present [v4] In-Reply-To: References: <-cYOL5wwp8oSisK5utj0B7mHi0D_Ne0i_N_RI-bsbLk=.87c1bc5f-a6a3-4d4e-9530-fc91e676656f@github.com> Message-ID: On Fri, 19 Sep 2025 16:24:44 GMT, Srinivas Vamsi Parasa wrote: >> Thanks for answering my questions.. things we checked: >> - double-checked reg parameter values of cpuid against the spec >> - double-checked endianness of bitset variables in C grammar >> - double-checked how offset to the field std_cpuid29_ebx is computed >> >> Change looks good to me > >> Change looks good to me >> > Thanks Vlad for going through the changes and reviewing the PR! Hi @vamsi-parasa , Before this PR, we could validate APX support using the publicly available latest version 9.58 of Intel software development emulator. EMR>sde64 --version Intel(R) Software Development Emulator. Version: 9.58.0 external (0) Copyright (C) 2008-2025, Intel Corporation. All rights reserved. EMR>sde64 -dmr -ptr_raise -- java -XX:+PrintFlagsFinal -XX:+UnlockExperimentalVMOptions -XX:+UseAPX --version | grep APX bool UseAPX = true {ARCH experimental} {command line} After this PR, UseAPX support is false, I think we should only upstream the support which can be validated. EMR>sde64 -dmr -ptr_raise -- java -XX:+PrintFlagsFinal -XX:+UnlockExperimentalVMOptions -XX:+UseAPX --version | grep APX OpenJDK 64-Bit Server VM warning: UseAPX is not supported on this CPU, setting it to false bool UseAPX = false {ARCH experimental} {command line} Best Regards, Jatin ------------- PR Comment: https://git.openjdk.org/jdk/pull/27320#issuecomment-3323431153 From rehn at openjdk.org Tue Sep 23 10:42:06 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 23 Sep 2025 10:42:06 GMT Subject: RFR: 8368366: RISC-V: AlignVector is mistakenly set to AvoidUnalignedAccesses In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 07:21:47 GMT, Fei Yang wrote: > Hi, please consider this small change fixing setting of `AlignVector` flag on RISC-V. > > According to the latest RISC-V linux hardware probing syscall [1], the performance of misaligned memory accesses > has been divided into two cases: `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` and `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` > for scalar and vector respectively. And `RISCV_HWPROBE_KEY_CPUPERF_0` is now deprecated and it returns similar values > to `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`. > > Previously, we use `RISCV_HWPROBE_KEY_CPUPERF_0` to detect support for misaligned memory accesses and reflect the result > on these VM flags: `AvoidUnalignedAccesses`, `UseUnalignedAccesses` and `AlignVector`. But it doesn't seem correct to update > `AlignVector` according to this value. And this is causing issues on RISC-V hardwares which have fast misaligned accesses only > for the scalar case. I witnessed SIGBUG error on these hardwares when doing vector misaligned accesses. > > So we should align AlignVector with `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` instead. This patch just reverts the previous > setting of AlignVector and just let it have the default value which is true. I will try to add detection in a separate PR > for `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` and update `AlignVector` accordingly. > > [1] https://docs.kernel.org/arch/riscv/hwprobe.html Yes, thanks, I think you are on the right track. But an additional thing: if user sets "-XX:-UseUnalignedAccesses" I think that should be enought to stop all of them all. Also I'm doubt ful of the usefulness of Avoid flag. I don't see any case where I would have Avoid = false but also UseUnAl= false. Right now I always use Avoid = !UseUnal. ------------- Marked as reviewed by rehn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27445#pullrequestreview-3257314698 From stuefe at openjdk.org Tue Sep 23 10:43:11 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 23 Sep 2025 10:43:11 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps [v2] In-Reply-To: References: Message-ID: <-WkhOYIVIwW6mihulRE5GDoJAXFnZhhpeitDypIFEwU=.b6890075-7165-4b8d-9f62-91dcb861352c@github.com> > When we run with ASAN enabled and ASAN catches an error, it reports, then stops the JVM. hs-err files and crash dumps at that point would be incredibly useful, though. The ASAN error report itself is seldom enlightening since it only contains native stacks. > > This patch makes it possible to get hs-err files and subsequent crash dumps by using the error callback functionality of ASAN. It registers a callback which gets called when ASAN catches an error. We then - carefully - print out the ASAN report to stderr (as ASAN itself would have done) and proceeed to end the JVM with a `fatal()`, which gives us an hs-err file, a callstack at that point including Java frames, and - if enabled - core dumps. > > Tested on Fedora 42 and Debian 12, both manually and by running the new companion jtreg test. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Update address.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27446/files - new: https://git.openjdk.org/jdk/pull/27446/files/1b4476b3..69d5cf5d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27446&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27446&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27446.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27446/head:pull/27446 PR: https://git.openjdk.org/jdk/pull/27446 From aph at openjdk.org Tue Sep 23 11:02:43 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 23 Sep 2025 11:02:43 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v2] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: <5Y5h568Saz4vj6uzfH09a1bgtsZ-4LSHFm2gfu8Eb-Q=.121bc2d4-e044-40ec-9347-736fb5c79456@github.com> On Wed, 13 Aug 2025 22:22:04 GMT, Dean Long wrote: >> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp >> >> Co-authored-by: Bernhard Urban-Forster > > src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 265: > >> 263: // is called by the signal handler at arbitrary point of >> 264: // execution. >> 265: ThreadWXEnable wx(WXWrite, thread); > > I'm not sure this ThreadWXEnable needs to use WXWrite. I had changed it to WXExec in my experiments. If it can be WXWrite or WXExec, then we don't need to set it at all, I suppose. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2371920615 From aph at openjdk.org Tue Sep 23 11:05:47 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 23 Sep 2025 11:05:47 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v3] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> Message-ID: On Tue, 19 Aug 2025 06:45:03 GMT, David Holmes wrote: > I think an assert so we gradually eradicate these fallback cases is a good idea. Just hope the stacktrace shows us where we should have placed the call. > > But as Dean points out, we need a way to test the fallback ... maybe a gtest? I added `StressWXHealing` and `TraceWXHealing`, which shows this fallback works. I'll think about how to do a gtest. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2371927367 From tschatzl at openjdk.org Tue Sep 23 11:53:06 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 23 Sep 2025 11:53:06 GMT Subject: RFR: 8352069: Renamings after JEP 522: G1 GC: Improve Throughput by Reducing Synchronization Message-ID: Hi all, please review this change that implements some deferred cleanups from JEP 522. Just some renaming for all platform-specific files. Testing: gha Thanks, Thomas ------------- Commit messages: - 8352069 Changes: https://git.openjdk.org/jdk/pull/27450/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27450&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352069 Stats: 66 lines in 6 files changed: 0 ins; 0 del; 66 mod Patch: https://git.openjdk.org/jdk/pull/27450.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27450/head:pull/27450 PR: https://git.openjdk.org/jdk/pull/27450 From ayang at openjdk.org Tue Sep 23 12:07:14 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 23 Sep 2025 12:07:14 GMT Subject: RFR: 8368303: AlwaysAtomicAccesses is excessively strict In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 16:51:08 GMT, Andrew Haley wrote: > In C1, the experimental flag `AlwaysAtomicAccesses` treats accesses to all fields as if they were volatile fields. This is correct but excessive: we only need single-copy atomicity to satisfy `AlwaysAtomicAccesses`. > > We need this in order to allow progress on JDK-8365147. I get the feeling that this "optimization" (using plain store/move for smaller types) should be done at a lower level/later stage, i.e. in respective backend. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27432#issuecomment-3323721293 From fbredberg at openjdk.org Tue Sep 23 12:17:28 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Tue, 23 Sep 2025 12:17:28 GMT Subject: RFR: 8365191: Cleanup after removing LockingMode related code Message-ID: This is a general cleanup after removing `LockingMode` related code. It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261). It includes: - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking. - Removing or rewriting comments, arguments or functions that are related to displaced headers. - Remove "always true" parameter from `MonitorExitStub`. - Re-type/name metadata in `BasicLock`. Tier1-5 passes okay on supported platforms. All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu. ------------- Commit messages: - Merge branch 'master' into 8365191_lockingmode_cleanup - 8365191: Cleanup after removing LockingMode related code Changes: https://git.openjdk.org/jdk/pull/27448/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27448&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365191 Stats: 168 lines in 34 files changed: 2 ins; 43 del; 123 mod Patch: https://git.openjdk.org/jdk/pull/27448.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27448/head:pull/27448 PR: https://git.openjdk.org/jdk/pull/27448 From iwalulya at openjdk.org Tue Sep 23 12:45:27 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 23 Sep 2025 12:45:27 GMT Subject: RFR: 8352069: Renamings after JEP 522: G1 GC: Improve Throughput by Reducing Synchronization In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 11:45:08 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that implements some deferred cleanups from JEP 522. > > Just some renaming for all platform-specific files. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27450#pullrequestreview-3257822204 From tschatzl at openjdk.org Tue Sep 23 12:47:11 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 23 Sep 2025 12:47:11 GMT Subject: RFR: 8368367: Test jdk/jfr/event/gc/detailed/TestGCHeapMemoryUsageEvent.java fails jdk.GCHeapMemoryUsage "expected 0 > 0" Message-ID: Hi all, please review this change to the TestGCHeapMemoryUsageEvent test that checks whether these kind of events are posted and contain some sensibles values. In this failure, the `used` metric for the first of two events that is checked was zero. This is because G1, the default collector, updates the `used` value only at certain synchronization points to avoid inconsistencies in other cases. One of these synchronization points is region refill. With the 30gb heap in the test environment, region size is larger than what is allocated during startup, so no region refill/synchronization point has been reached yet, and `used` turns out to be `0`. This change fixes this by checking the last event instead of the first, it must have happened after that `system.gc()` call in the test, and `used` ought to be larger than zero because of allocations during VM startup. An alternative could be limiting the test's heap size to something small, that would also help, but I thought this might need additional explanations. Testing: local runs with G1 heap region size >= 16M or so do not fail any more. Thanks, Thomas ------------- Commit messages: - 8368367 Changes: https://git.openjdk.org/jdk/pull/27451/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27451&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368367 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27451.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27451/head:pull/27451 PR: https://git.openjdk.org/jdk/pull/27451 From stuefe at openjdk.org Tue Sep 23 12:55:28 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 23 Sep 2025 12:55:28 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v2] In-Reply-To: References: Message-ID: On Sat, 20 Sep 2025 07:52:58 GMT, Thomas Stuefe wrote: >> On Linux, ASAN only shows some internal thread designation on reports, e.g. `T49`, which is useless. >> >> This patch adds the ability to see the real internal JVM thread names or user-supplied Java thread names in ASAN. This makes it possible to correlate ASAN reports with hs-err file reports (if ASAN is run with `halt_on_error=0` to give us a chance to get an hs-err file) or with a thread dump done beforehand. >> >> Note that it can only show up to 15 characters, though. Therefore, the patch tries to be smart about names that end in digits: such numbers are preserved such that the truncation happens in the middle of the name, e.g.: >> >> `"MyAllocationWorkerThread#4411"` -> `"MyAllocat..4411"` >> >> This latter improvement now also applies to thread names in gdb, since they are subject to the same limitation. >> >> ----- >> >> Some examples from ASAN report: >> >> Before: >> >> WRITE of size 8 at 0x7b749d2d9190 thread T49 >> >> >> Now: >> >> WRITE of size 8 at 0x7bfc2f0d8380 thread T49 (MyThread#0) >> >> >> >> ==593899==ERROR: AddressSanitizer: attempting free .. in thread T76 (MyAllocati..29) > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > windows build error @dholmes-ora I may have found the answer to why `pthread_setname_np` won't work. We call `pthread_setname_np` assuming that it causes libpthread to call prctl(PR_SET_NAME,...), which would set the thread name in the kernel task structure. We further assume that name would percolate through to all interested parties, like gdb and ASAN. But it reproducibly does not work for ASAN, tested on Fedora with glibc 2.42 and on Debian 12 stable. I also often see JVM ASAN reports from unknown Linux versions that never show a Thread name. ### glibc glibc seems to do everything correctly: https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=nptl/pthread_setname.c;hb=42aba9189557280ad367c35908cbdfe26f5aeeb1 specifically, in the Linux version of `pthread_setname_np`, it calls eventually: int __pthread_setname_np (pthread_t th, const char *name) { ... if (pd == THREAD_SELF) return __prctl (PR_SET_NAME, name) ? errno : 0; ... Okay, so if `pthread_setname_np` in glibc 2.42 seems to do everything right, why does ASAN not display the name?. ### ASAN (in GCC) #### prctl ASAN intercepts `prctl(SET_NAME)`: it does the real `prctl` first, then calls `COMMON_INTERCEPTOR_SET_THREAD_NAME`: https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc;hb=HEAD INTERCEPTOR(int, prctl, int option, unsigned long arg2, unsigned long arg3, unsigned long arg4, unsigned long arg5) { ... int res = REAL(prctl)(option, arg2, arg3, arg4, arg5); if (option == PR_SET_NAME) { char buff[16]; internal_strncpy(buff, (char *)arg2, 15); buff[15] = 0; COMMON_INTERCEPTOR_SET_THREAD_NAME(ctx, buff); } else if (res == 0 && option == PR_GET_NAME) { `COMMON_INTERCEPTOR_SET_THREAD_NAME` is defined as `SetThreadName` in ASAN here: https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libsanitizer/asan/asan_interceptors.h;hb=HEAD #define COMMON_INTERCEPTOR_SET_THREAD_NAME(ctx, name) SetThreadName(name) Which will register the thread name with the central ASAN thread registry: void SetThreadName(const char *name) { ... asanThreadRegistry().SetThreadName(t->tid(), name); } And now the thread name is known to ASAN. #### pthread_setname_np ASAN also intercepts `pthread_setname_np`. It calls the interceptor first, then goes on calling the real `pthread_setname_np`: INTERCEPTOR(int, pthread_setname_np, uptr thread, const char *name) { void *ctx; COMMON_INTERCEPTOR_ENTER(ctx, pthread_setname_np, thread, name); COMMON_INTERCEPTOR_READ_STRING(ctx, name, 0); COMMON_INTERCEPTOR_SET_PTHREAD_NAME(ctx, thread, name); return REAL(pthread_setname_np)(thread, name); } `COMMON_INTERCEPTOR_SET_PTHREAD_NAME`, however, is a noop: #define COMMON_INTERCEPTOR_SET_PTHREAD_NAME(ctx, thread, name) \ do { \ } while (false) #### ASAN thread registry But where does ASAN in gcc get the thread name from, then? Looking at the thread registry code in ASAN, I expected to find a call to something like `prctl(PR_GET_NAME)` or `pthread_getname_np` for ASAN to query the underlying OS thread name. But I did not find anything. The internal thread structure (class `ThreadContextBase`) carries the user-defined thread name. When we call `pthread_setname_np`, the real glibc version is called correctly, which does `prctl(PR_SET_NAME)`, correctly. However, the name in the ASAN thread registry does not obtain its string from `prctl(PR_GET_NAME)`, the proc file system, or anywhere else. It only gets the name from intercepting `prctl(PR_SET_NAME)`. And intercepting `prctl(PR_SET_NAME)` only works **for an ASAN-instrumented binary**. So, if we call `prctl(PR_SET_NAME)` from within the hotspot, the ASAN interception kicks in and we modify the ASAN thread registry name alongside the kernel task structure name. All good. If we just call glibc `pthread_setname_np`, the glibc does call `prctl(PR_SET_NAME)` too, but ASAN does not intercept that call since glibc is not ASAN-instrumented. And it is also never read from the kernel task structure. It seems that the only way to set the ASAN thread name is to call `prctl` directly from the hotspot. --- As an interesting side note, the `ThreadSanitizer` does it differently: here the interceptor for `COMMON_INTERCEPTOR_SET_PTHREAD_NAME` is not empty but also hooks into the thread registry: https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libsanitizer/tsan/tsan_interceptors_posix.cpp;hb=HEAD #define COMMON_INTERCEPTOR_SET_PTHREAD_NAME(ctx, thread, name) \ if (pthread_equal(pthread_self(), reinterpret_cast(thread))) \ COMMON_INTERCEPTOR_SET_THREAD_NAME(ctx, name); \ else \ __tsan::ctx->thread_registry.SetThreadNameByUserId(thread, name) Might be worth fixing that in ASAN, but I'd rather have a libjvm version that works now and for all versions for ASAN, even if this gets fixed in the future. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27395#issuecomment-3323890898 From syan at openjdk.org Tue Sep 23 13:00:43 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 23 Sep 2025 13:00:43 GMT Subject: RFR: 8368367: Test jdk/jfr/event/gc/detailed/TestGCHeapMemoryUsageEvent.java fails jdk.GCHeapMemoryUsage "expected 0 > 0" In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 12:39:03 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to the TestGCHeapMemoryUsageEvent test that checks whether these kind of events are posted and contain some sensibles values. > > In this failure, the `used` metric for the first of two events that is checked was zero. This is because G1, the default collector, updates the `used` value only at certain synchronization points to avoid inconsistencies in other cases. One of these synchronization points is region refill. With the 30gb heap in the test environment, region size is larger than what is allocated during startup, so no region refill/synchronization point has been reached yet, and `used` turns out to be `0`. > > This change fixes this by checking the last event instead of the first, it must have happened after that `system.gc()` call in the test, and `used` ought to be larger than zero because of allocations during VM startup. > > An alternative could be limiting the test's heap size to something small, that would also help, but I thought this might need additional explanations. > > Testing: local runs with G1 heap region size >= 16M or so do not fail any more. > > Thanks, > Thomas test/jdk/jdk/jfr/event/gc/detailed/TestGCHeapMemoryUsageEvent.java line 50: > 48: > 49: List events = Events.fromRecording(recording); > 50: System.out.println(events); Should we update the copyright year ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27451#discussion_r2372244845 From fbredberg at openjdk.org Tue Sep 23 13:16:30 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Tue, 23 Sep 2025 13:16:30 GMT Subject: RFR: 8365191: Cleanup after removing LockingMode related code In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 09:29:57 GMT, Fredrik Bredberg wrote: > This is a general cleanup after removing `LockingMode` related code. > It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261). > It includes: > - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking. > - Removing or rewriting comments, arguments or functions that are related to displaced headers. > - Remove "always true" parameter from `MonitorExitStub`. > - Re-type/name metadata in `BasicLock`. > > Tier1-5 passes okay on supported platforms. > > All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu. @bulasevich, @TheRealMDoerr, @RealFYang, @offamitkumar I've run rudimentary tests using QEMU, but it would be nice if you guys (or any of your friends) could take it for a spin on real hardware. Thanks in advance. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27448#issuecomment-3323970915 From jbechberger at openjdk.org Tue Sep 23 13:39:13 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Tue, 23 Sep 2025 13:39:13 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing [v8] In-Reply-To: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> Message-ID: > This change hopefully fixes the test failures by making the test cases more resilient. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Fix disabling out-of-stack walking and time box handling ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27293/files - new: https://git.openjdk.org/jdk/pull/27293/files/7c4697b2..9a6f8b3b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27293&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27293&range=06-07 Stats: 44 lines in 4 files changed: 29 ins; 5 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/27293.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27293/head:pull/27293 PR: https://git.openjdk.org/jdk/pull/27293 From stuefe at openjdk.org Tue Sep 23 13:42:18 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 23 Sep 2025 13:42:18 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v3] In-Reply-To: References: Message-ID: > On Linux, ASAN only shows some internal thread designation on reports, e.g. `T49`, which is useless. > > This patch adds the ability to see the real internal JVM thread names or user-supplied Java thread names in ASAN. This makes it possible to correlate ASAN reports with hs-err file reports (if ASAN is run with `halt_on_error=0` to give us a chance to get an hs-err file) or with a thread dump done beforehand. > > Note that it can only show up to 15 characters, though. Therefore, the patch tries to be smart about names that end in digits: such numbers are preserved such that the truncation happens in the middle of the name, e.g.: > > `"MyAllocationWorkerThread#4411"` -> `"MyAllocat..4411"` > > This latter improvement now also applies to thread names in gdb, since they are subject to the same limitation. > > For a detailed analysis of why the old version, using libpthread's `pthread_setname_np`, is not sufficient for thread names in ASAN, please see the issue description. > > ----- > > Some examples from ASAN report: > > Before: > > WRITE of size 8 at 0x7b749d2d9190 thread T49 > > > Now: > > WRITE of size 8 at 0x7bfc2f0d8380 thread T49 (MyThread#0) > > > > ==593899==ERROR: AddressSanitizer: attempting free .. in thread T76 (MyAllocati..29) Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: simplify truncation function ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27395/files - new: https://git.openjdk.org/jdk/pull/27395/files/68244fc0..a7a657fb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27395&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27395&range=01-02 Stats: 68 lines in 4 files changed: 1 ins; 50 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/27395.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27395/head:pull/27395 PR: https://git.openjdk.org/jdk/pull/27395 From stuefe at openjdk.org Tue Sep 23 13:42:20 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 23 Sep 2025 13:42:20 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v2] In-Reply-To: References: Message-ID: On Sat, 20 Sep 2025 07:52:58 GMT, Thomas Stuefe wrote: >> On Linux, ASAN only shows some internal thread designation on reports, e.g. `T49`, which is useless. >> >> This patch adds the ability to see the real internal JVM thread names or user-supplied Java thread names in ASAN. This makes it possible to correlate ASAN reports with hs-err file reports (if ASAN is run with `halt_on_error=0` to give us a chance to get an hs-err file) or with a thread dump done beforehand. >> >> Note that it can only show up to 15 characters, though. Therefore, the patch tries to be smart about names that end in digits: such numbers are preserved such that the truncation happens in the middle of the name, e.g.: >> >> `"MyAllocationWorkerThread#4411"` -> `"MyAllocat..4411"` >> >> This latter improvement now also applies to thread names in gdb, since they are subject to the same limitation. >> >> For a detailed analysis of why the old version, using libpthread's `pthread_setname_np`, is not sufficient for thread names in ASAN, please see the issue description. >> >> ----- >> >> Some examples from ASAN report: >> >> Before: >> >> WRITE of size 8 at 0x7b749d2d9190 thread T49 >> >> >> Now: >> >> WRITE of size 8 at 0x7bfc2f0d8380 thread T49 (MyThread#0) >> >> >> >> ==593899==ERROR: AddressSanitizer: attempting free .. in thread T76 (MyAllocati..29) > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > windows build error @dholmes-ora I simplified the truncation function a bit as requested. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27395#issuecomment-3324050243 From kvn at openjdk.org Tue Sep 23 13:47:26 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 23 Sep 2025 13:47:26 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v11] In-Reply-To: References: Message-ID: <0IoLphlvsBS-Kr7-NbUG0pNMjTe3B8kJ7VsDypm9xHw=.2105c0b4-60c5-4eaa-98a2-bedbbbaae995@github.com> On Tue, 23 Sep 2025 03:24:28 GMT, Ioi Lam wrote: >> This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. >> >> - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. >> - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. >> - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: > > - @vnkozlov review comments > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - @ashu-mehra comment - AOTLinkedClassBulkLoader::link_or_init_javabase_classes() should also call exit_on_exception() > - Fixed 32-bit builds > - Removed JVMCI-specific checks that are no longer necessary with class preloading -- all CP entries discoverable by JVMCI will always point to already-loaded classes > - Simplify implementation after JDK-8367366: Do not support -XX:+AOTClassLinking for dynamic CDS archive > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - Merge branch 'master' into 8350550-preload-aot-classes-during-vm-bootstrap > - @ashu-mehra comment: removed AOTLinkedClassBulkLoader::is_pending_aot_linked_class > - @ashu-mehra review comments > - ... and 21 more: https://git.openjdk.org/jdk/compare/61c5245b...bd08a0b5 Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26375#pullrequestreview-3258111898 From mbaesken at openjdk.org Tue Sep 23 13:49:36 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 23 Sep 2025 13:49:36 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps [v2] In-Reply-To: <-WkhOYIVIwW6mihulRE5GDoJAXFnZhhpeitDypIFEwU=.b6890075-7165-4b8d-9f62-91dcb861352c@github.com> References: <-WkhOYIVIwW6mihulRE5GDoJAXFnZhhpeitDypIFEwU=.b6890075-7165-4b8d-9f62-91dcb861352c@github.com> Message-ID: On Tue, 23 Sep 2025 10:43:11 GMT, Thomas Stuefe wrote: >> When we run with ASAN enabled and ASAN catches an error, it reports, then stops the JVM. hs-err files and crash dumps at that point would be incredibly useful, though. The ASAN error report itself is seldom enlightening since it only contains native stacks. >> >> This patch makes it possible to get hs-err files and subsequent crash dumps by using the error callback functionality of ASAN. It registers a callback which gets called when ASAN catches an error. We then - carefully - print out the ASAN report to stderr (as ASAN itself would have done) and proceeed to end the JVM with a `fatal()`, which gives us an hs-err file, a callstack at that point including Java frames, and - if enabled - core dumps. >> >> Tested on Fedora 42 and Debian 12, both manually and by running the new companion jtreg test. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Update address.cpp Is there some XX flag to enable the new behavior ? It would be quite horrible for us to always get a hserr+core when running into an ASAN issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27446#issuecomment-3324096947 From mbaesken at openjdk.org Tue Sep 23 13:54:16 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 23 Sep 2025 13:54:16 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v3] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 13:42:18 GMT, Thomas Stuefe wrote: >> On Linux, ASAN only shows some internal thread designation on reports, e.g. `T49`, which is useless. >> >> This patch adds the ability to see the real internal JVM thread names or user-supplied Java thread names in ASAN. This makes it possible to correlate ASAN reports with hs-err file reports (if ASAN is run with `halt_on_error=0` to give us a chance to get an hs-err file) or with a thread dump done beforehand. >> >> Note that it can only show up to 15 characters, though. Therefore, the patch tries to be smart about names that end in digits: such numbers are preserved such that the truncation happens in the middle of the name, e.g.: >> >> `"MyAllocationWorkerThread#4411"` -> `"MyAllocat..4411"` >> >> This latter improvement now also applies to thread names in gdb, since they are subject to the same limitation. >> >> For a detailed analysis of why the old version, using libpthread's `pthread_setname_np`, is not sufficient for thread names in ASAN, please see the issue description. >> >> ----- >> >> Some examples from ASAN report: >> >> Before: >> >> WRITE of size 8 at 0x7b749d2d9190 thread T49 >> >> >> Now: >> >> WRITE of size 8 at 0x7bfc2f0d8380 thread T49 (MyThread#0) >> >> >> >> ==593899==ERROR: AddressSanitizer: attempting free .. in thread T76 (MyAllocati..29) > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > simplify truncation function src/hotspot/os/linux/os_linux.cpp line 4869: > 4867: int rc = prctl(PR_SET_NAME, buf); > 4868: //assert(rc == 0, "prctl(PR_SET_NAME) failed"); > 4869: //int rc; Do you want to remove the uncommented coding ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27395#discussion_r2372415379 From stuefe at openjdk.org Tue Sep 23 13:55:22 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 23 Sep 2025 13:55:22 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps [v2] In-Reply-To: References: <-WkhOYIVIwW6mihulRE5GDoJAXFnZhhpeitDypIFEwU=.b6890075-7165-4b8d-9f62-91dcb861352c@github.com> Message-ID: On Tue, 23 Sep 2025 13:46:37 GMT, Matthias Baesken wrote: > Is there some XX flag to enable the new behavior ? It would be quite horrible for us to always get a hserr+core when running into an ASAN issue. Interesting. No, no flag, but I can easily add one. But why would you not want to have a hs-err file? Core file generation depends, as usual, on CreateCoreDumpOnCrash and the ulimit, of course. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27446#issuecomment-3324119293 From kvn at openjdk.org Tue Sep 23 13:57:37 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 23 Sep 2025 13:57:37 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry [v4] In-Reply-To: References: Message-ID: <5g6V92p5_ALJ5jcjwKsLTVhyhyKJye2oRXpqxHPZn0c=.47d79714-069a-4147-b5aa-3f833806fa8d@github.com> On Mon, 22 Sep 2025 19:55:09 GMT, Ashutosh Mehra wrote: >> This PR removes the need to store entry point addresses in AdapterHandlerEntry by storing a direct pointer to AdapterBlob instead. Entry point addresses can be computed on the fly from the entry point offsets stored in AdapterBlob. > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Address adinn's review comments > > Signed-off-by: Ashutosh Mehra Please build and test Zero VM to make sure new code works with it. ------------- PR Review: https://git.openjdk.org/jdk/pull/27101#pullrequestreview-3258153337 From mdoerr at openjdk.org Tue Sep 23 13:59:43 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 23 Sep 2025 13:59:43 GMT Subject: RFR: 8365191: Cleanup after removing LockingMode related code In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 09:29:57 GMT, Fredrik Bredberg wrote: > This is a general cleanup after removing `LockingMode` related code. > It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261). > It includes: > - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking. > - Removing or rewriting comments, arguments or functions that are related to displaced headers. > - Remove "always true" parameter from `MonitorExitStub`. > - Re-type/name metadata in `BasicLock`. > > Tier1-5 passes okay on supported platforms. > > All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu. PPC64 and hotspot/share/c1 changes LGTM. Thanks for cleaning it up! ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27448#pullrequestreview-3258165227 From vlivanov at openjdk.org Tue Sep 23 14:03:09 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 23 Sep 2025 14:03:09 GMT Subject: RFR: 8367611: Enable vblendvp[sd] on Future ECore [v3] In-Reply-To: References: <_Jk5fv1iO9ZPZyOtUAXeUez481RibKJR4FsUT_BnKm8=.2f68f9ee-9ce2-4dbb-be8b-1b9f910ba0e0@github.com> Message-ID: On Fri, 19 Sep 2025 21:57:30 GMT, Mohamed Issa wrote: >> The upcoming ECore platforms will benefit from using `vblendvps` and `vblendvpd` instructions when the destination register is the same as the source register. This change takes that situation into account. >> >> The JTREG test shown below was used to verify correctness against the [OpenJDK v26-b15](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B15) baseline build. This test frequently calls vblendvps() and vblendvpd() in the macro assembler. On Darkmont and non-Darkmont cores, the right code paths are followed when checking with asserts. >> >> 1. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` > > Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: > > Combine boolean flags to avoid ambiguity The patch itself looks fine, but the way instruction emulation is implemented (as introduced by JDK-8320347) doesn't fit the design well. It does look appealing to abstract away the choice, but it becomes confusing when there's a need to reason about exact code shape. Another consequence is code duplication where both x86.ad and `MacroAssembler::vblendvp[sd]` provide their own emulated versions. I suggest to reshape it and extract emulated variant into separate methods leaving `Assembler::vblendvp[sd]` as is. Then, for convenience, `C2_MacroAssembler` can provide new methods which do CPU dispatching or just do dispatching explicitly at call sites in `c2_MacroAssembler_x86.cpp`. Also, it's better to move CPU sensing logic to `VM_Version`, so the checks and code emission logic can be unified across all use sites (in `c2_MacroAssembler_x86.cpp` and `x86.ad`). I'm fine with addressing it either as part of this PR or as a follow-up enhancement. ------------- PR Review: https://git.openjdk.org/jdk/pull/27354#pullrequestreview-3258183895 From stuefe at openjdk.org Tue Sep 23 14:10:47 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 23 Sep 2025 14:10:47 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v4] In-Reply-To: References: Message-ID: > On Linux, ASAN only shows some internal thread designation on reports, e.g. `T49`, which is useless. > > This patch adds the ability to see the real internal JVM thread names or user-supplied Java thread names in ASAN. This makes it possible to correlate ASAN reports with hs-err file reports (if ASAN is run with `halt_on_error=0` to give us a chance to get an hs-err file) or with a thread dump done beforehand. > > Note that it can only show up to 15 characters, though. Therefore, the patch tries to be smart about names that end in digits: such numbers are preserved such that the truncation happens in the middle of the name, e.g.: > > `"MyAllocationWorkerThread#4411"` -> `"MyAllocat..4411"` > > This latter improvement now also applies to thread names in gdb, since they are subject to the same limitation. > > For a detailed analysis of why the old version, using libpthread's `pthread_setname_np`, is not sufficient for thread names in ASAN, please see the issue description. > > ----- > > Some examples from ASAN report: > > Before: > > WRITE of size 8 at 0x7b749d2d9190 thread T49 > > > Now: > > WRITE of size 8 at 0x7bfc2f0d8380 thread T49 (MyThread#0) > > > > ==593899==ERROR: AddressSanitizer: attempting free .. in thread T76 (MyAllocati..29) Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: review feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27395/files - new: https://git.openjdk.org/jdk/pull/27395/files/a7a657fb..62ab1b15 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27395&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27395&range=02-03 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27395.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27395/head:pull/27395 PR: https://git.openjdk.org/jdk/pull/27395 From stuefe at openjdk.org Tue Sep 23 14:10:49 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 23 Sep 2025 14:10:49 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v3] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 13:50:50 GMT, Matthias Baesken wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> simplify truncation function > > src/hotspot/os/linux/os_linux.cpp line 4869: > >> 4867: int rc = prctl(PR_SET_NAME, buf); >> 4868: //assert(rc == 0, "prctl(PR_SET_NAME) failed"); >> 4869: //int rc; > > Do you want to remove the uncommented coding ? Thanks, fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27395#discussion_r2372462240 From stuefe at openjdk.org Tue Sep 23 14:19:12 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 23 Sep 2025 14:19:12 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v4] In-Reply-To: References: Message-ID: <0T8X1fFfkruqIsyjaOLzx-qJ9mU1K2A597V5860mYv4=.a5579f04-db48-4d2e-b5d5-6de917bf17ee@github.com> On Tue, 23 Sep 2025 14:10:47 GMT, Thomas Stuefe wrote: >> On Linux, ASAN only shows some internal thread designation on reports, e.g. `T49`, which is useless. >> >> This patch adds the ability to see the real internal JVM thread names or user-supplied Java thread names in ASAN. This makes it possible to correlate ASAN reports with hs-err file reports (if ASAN is run with `halt_on_error=0` to give us a chance to get an hs-err file) or with a thread dump done beforehand. >> >> Note that it can only show up to 15 characters, though. Therefore, the patch tries to be smart about names that end in digits: such numbers are preserved such that the truncation happens in the middle of the name, e.g.: >> >> `"MyAllocationWorkerThread#4411"` -> `"MyAllocat..4411"` >> >> This latter improvement now also applies to thread names in gdb, since they are subject to the same limitation. >> >> For a detailed analysis of why the old version, using libpthread's `pthread_setname_np`, is not sufficient for thread names in ASAN, please see the issue description. >> >> ----- >> >> Some examples from ASAN report: >> >> Before: >> >> WRITE of size 8 at 0x7b749d2d9190 thread T49 >> >> >> Now: >> >> WRITE of size 8 at 0x7bfc2f0d8380 thread T49 (MyThread#0) >> >> >> >> ==593899==ERROR: AddressSanitizer: attempting free .. in thread T76 (MyAllocati..29) > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > review feedback As a nice side effect of this patch, we now get more useful thread names in gdb, too. Before: 21 Thread 0x7bfbc43736c0 (LWP 323467) "C2 CompilerThre" __syscall_cancel_arch () at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56 22 Thread 0x7bfbc42736c0 (LWP 323468) "C1 CompilerThre" __syscall_cancel_arch () at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56 25 Thread 0x7bfbad1c06c0 (LWP 323471) "C1 CompilerThre" __syscall_cancel_arch () at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56 26 Thread 0x7bfbac5b76c0 (LWP 323472) "C1 CompilerThre" __syscall_cancel_arch () at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56 now 24 Thread 0x7fffa38fe6c0 (LWP 245948) "C1 Com..hread1" __syscall_cancel_arch () at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56 25 Thread 0x7fffa37fe6c0 (LWP 245949) "C1 Com..hread2" __syscall_cancel_arch () at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56 26 Thread 0x7fffa36fe6c0 (LWP 245950) "C1 Com..hread3" __syscall_cancel_arch () at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56 27 Thread 0x7fffa35fe6c0 (LWP 245952) "C1 Com..hread4" __syscall_cancel_arch () at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27395#issuecomment-3324216980 From aph at openjdk.org Tue Sep 23 14:29:15 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 23 Sep 2025 14:29:15 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v8] In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: > In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. > > Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. > > This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. > > The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. > > We mark all sites that we know will write to code memory with > `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. > > We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. > > It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. > > One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ... Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: More ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26562/files - new: https://git.openjdk.org/jdk/pull/26562/files/febe873d..c25fbefa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=06-07 Stats: 31 lines in 3 files changed: 20 ins; 2 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/26562.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26562/head:pull/26562 PR: https://git.openjdk.org/jdk/pull/26562 From aph at openjdk.org Tue Sep 23 14:29:17 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 23 Sep 2025 14:29:17 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v2] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Tue, 12 Aug 2025 09:55:06 GMT, Andrew Haley wrote: >> src/hotspot/share/code/codeBlob.cpp line 397: >> >>> 395: >>> 396: BufferBlob* BufferBlob::create(const char* name, uint buffer_size) { >>> 397: MACOS_AARCH64_ONLY(os::thread_wx_enable_write()); >> >> I'm not sure why write has to be enabled here when it is not needed in any of the other create methods. The new operation below will call CodeCache::allocate (just as happens with with, say, VtableBlob::create). So, why is that not enough? > >> I'm not sure why write has to be enabled here when it is not needed in any of the other create methods. The new operation below will call CodeCache::allocate (just as happens with with, say, VtableBlob::create). So, why is that not enough? > > I have no idea, I've never tried! I'll give that a spin. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2372510482 From aph at openjdk.org Tue Sep 23 14:29:18 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 23 Sep 2025 14:29:18 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v2] In-Reply-To: <5d1VwviKHZ3PsV6ih-Sp4huqZS9aML3V5tg7fFPvMas=.9e1d8370-5d37-4e12-bf42-b5238dfcd84f@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <-r2oKH0efYlwqmo8l7tEqdU7wP--nUZWPWuKd42RkkM=.22841f3a-3ecc-44de-bea6-bfeb6895020d@github.com> <4paL_6pij2g1Wt30YKY8140rtQVuilhjNBdOz_xjYPs=.0c0a36fe-e05d-4401-b6ba-53f0c5601d10@github.com> <5d1VwviKHZ3PsV6ih-Sp4huqZS9aML3V5tg7fFPvMas=.9e1d8370-5d37-4e12-bf42-b5238dfcd84f@github.com> Message-ID: <45KiSEcFJjv3pBMi0MMZeb8mmbKyWA0tCQ0TwDQ5tWA=.30d83b9b-4e2f-4939-8bb4-482e7b94a089@github.com> On Wed, 13 Aug 2025 22:02:20 GMT, Dean Long wrote: >> I don't believe the order is going to matter (tell me if I am wrong) but I think it would be better to order them consistently, not just because I am a 'typical computer programmer' but because someone might be puzzled as to whether the re-ordering is significant (ok, yes, I guess that 'someone' would be a 'typical computer programmer' or maybe just me). I suggested both after because the async thread transition has a bail out and we might as well bail early . . . > > I like having the mode change after the thread state change. In my experiements, I tried to assert that we only change thread state when we are in Exec mode, but ended up relaxing that for Compiler and GC threads. All done, I think. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2372519150 From stuefe at openjdk.org Tue Sep 23 14:39:53 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 23 Sep 2025 14:39:53 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps [v2] In-Reply-To: References: <-WkhOYIVIwW6mihulRE5GDoJAXFnZhhpeitDypIFEwU=.b6890075-7165-4b8d-9f62-91dcb861352c@github.com> Message-ID: On Tue, 23 Sep 2025 13:46:37 GMT, Matthias Baesken wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Update address.cpp > > Is there some XX flag to enable the new behavior ? > It would be quite horrible for us to always get a hserr+core when running into an ASAN issue. @MBaesken I am fine with adding some sort of option, but we need to figure out what the default behavior would be. It would be sad to disable this by default. I see developers using the ASAN build regularly, and typically they don't know which switches exist. Or, they have no possibility to even set switches, since the command line cannot be modified. Therefore, I'd like to understand better what the problem is. hs-err files are quite small, at least in comparison to typical cores. We can disable core files by default, while hs-err files would still be generated. Would that be a compromise? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27446#issuecomment-3324307811 From tschatzl at openjdk.org Tue Sep 23 14:41:18 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 23 Sep 2025 14:41:18 GMT Subject: RFR: 8368367: Test jdk/jfr/event/gc/detailed/TestGCHeapMemoryUsageEvent.java fails jdk.GCHeapMemoryUsage "expected 0 > 0" [v2] In-Reply-To: References: Message-ID: <2E4HThSyBO6onGz4gXIEekO6Xi-LbLfnsPH5jiVBrgU=.813dfd55-7cb4-4fc2-86f6-f4b9bb6c168a@github.com> > Hi all, > > please review this change to the TestGCHeapMemoryUsageEvent test that checks whether these kind of events are posted and contain some sensibles values. > > In this failure, the `used` metric for the first of two events that is checked was zero. This is because G1, the default collector, updates the `used` value only at certain synchronization points to avoid inconsistencies in other cases. One of these synchronization points is region refill. With the 30gb heap in the test environment, region size is larger than what is allocated during startup, so no region refill/synchronization point has been reached yet, and `used` turns out to be `0`. > > This change fixes this by checking the last event instead of the first, it must have happened after that `system.gc()` call in the test, and `used` ought to be larger than zero because of allocations during VM startup. > > An alternative could be limiting the test's heap size to something small, that would also help, but I thought this might need additional explanations. > > Testing: local runs with G1 heap region size >= 16M or so do not fail any more. > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * fix copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27451/files - new: https://git.openjdk.org/jdk/pull/27451/files/067570a1..611551fd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27451&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27451&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27451.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27451/head:pull/27451 PR: https://git.openjdk.org/jdk/pull/27451 From vlivanov at openjdk.org Tue Sep 23 14:42:19 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 23 Sep 2025 14:42:19 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final In-Reply-To: <_p9u9mX5mBTeHuKdLY3uATLLs-hrHENJleIpMN2mMko=.6a686db2-314c-4b76-8876-d94558fbbd41@github.com> References: <_p9u9mX5mBTeHuKdLY3uATLLs-hrHENJleIpMN2mMko=.6a686db2-314c-4b76-8876-d94558fbbd41@github.com> Message-ID: <25ixE0_d_fp6zlqECkYMelk1PNpwgKAAmBNruu8xabc=.ea63f0ae-667a-4ca9-89de-1c3cd29a3219@github.com> On Tue, 23 Sep 2025 05:34:00 GMT, David Holmes wrote: > Otherwise how can these fields be considered as "trusted finals"?? FTR `System.in` et al are not considered as trusted finals. There's a special logic in `ciField::initialize_from()` to disable corresponding optimizations, so the fields aren't treated as constants. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2372557412 From iklam at openjdk.org Tue Sep 23 14:43:45 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 23 Sep 2025 14:43:45 GMT Subject: RFR: 8350550: Preload classes from AOT cache during VM bootstrap [v5] In-Reply-To: References: Message-ID: On Fri, 22 Aug 2025 19:18:41 GMT, Dan Heidinga wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @DanHeidinga comments -- added comments and asserts about the handling of enums > > My concerns have been addressed. Thanks Ioi Thanks @DanHeidinga @ashu-mehra @vnkozlov for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/26375#issuecomment-3324325748 From iklam at openjdk.org Tue Sep 23 14:46:17 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 23 Sep 2025 14:46:17 GMT Subject: Integrated: 8350550: Preload classes from AOT cache during VM bootstrap In-Reply-To: References: Message-ID: <0g4ainvBjH046UiFMkElHNhUgLhBTEhVih6KTHLTgmA=.37cb0c1d-8239-4b7c-a150-6bdb272df63c@github.com> On Thu, 17 Jul 2025 22:38:48 GMT, Ioi Lam wrote: > This PR loads the classes for the boot/platform/app loaders with `AOTLinkedClassBulkLoader::preload_classes()`. This happens at the very beginning of `vmClasses::resolve_all()`, before any Java code is executed. > > - We essentially iterate over all the classes inside the `AOTLinkedClassTable` and adds them into the system dictionary using the new method `SystemDictionary::preload_class()`. > - `SystemDictionary::preload_class(..., k)` is lightweight because it's called in a single thread after all super types of `k` have been loaded. So most of the complicated work (such as place holders, circularity detection, etc) in `SystemDictionary::resolve_or_null(..., k)` can be skipped. We also don't need to call into `ClassLoader::load_class()` as the boot/platform/app loaders are well-behaved. > - In the assembly phase, we record the mirror, package, protection domain, code source, etc, of these classes. So there's no need to programmatically create them in the production run. See `HeapShared::copy_java_mirror()` and also changes in ClassLoader.java and SecureClassLoader.java. This pull request has now been integrated. Changeset: fd30ae98 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/fd30ae988bc512b5d2a5a3fd1bc1ed351af974c7 Stats: 941 lines in 43 files changed: 534 ins; 236 del; 171 mod 8350550: Preload classes from AOT cache during VM bootstrap Reviewed-by: kvn, heidinga, asmehra ------------- PR: https://git.openjdk.org/jdk/pull/26375 From liach at openjdk.org Tue Sep 23 14:59:53 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Sep 2025 14:59:53 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v4] In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 16:04:08 GMT, Chen Liang wrote: >> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value). >> >> This is a necessary prerequisite for https://bugs.openjdk.org/browse/JDK-8233268, which proposes enhanced null messages to `Objects::requireNonNull`. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Update NPE per roger review Can anyone come and review this little enhancement again? I think I have addressed the review comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26600#issuecomment-3324389047 From asmehra at openjdk.org Tue Sep 23 15:03:23 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 23 Sep 2025 15:03:23 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry [v4] In-Reply-To: References: Message-ID: <2UylqHUZAgA-izpoDL1mO8qvxhSTGX3CLmFtEL-PEBc=.6fd0d223-8eac-4c39-9a00-c975aa288b26@github.com> On Mon, 22 Sep 2025 19:55:09 GMT, Ashutosh Mehra wrote: >> This PR removes the need to store entry point addresses in AdapterHandlerEntry by storing a direct pointer to AdapterBlob instead. Entry point addresses can be computed on the fly from the entry point offsets stored in AdapterBlob. > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Address adinn's review comments > > Signed-off-by: Ashutosh Mehra The last commit broke Zero VM again. It expects that entry point getter methods in AdapterHandleEntry won't be called for Zero VM, but in `Method::link_method` there is a call to `adapter()->get_c2i_entry();`. I think I will update the getters to remove `ShouldNotReachHere` and just return nullptr. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27101#issuecomment-3324403089 From bmaillard at openjdk.org Tue Sep 23 15:06:51 2025 From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard) Date: Tue, 23 Sep 2025 15:06:51 GMT Subject: RFR: 8360389: Support printing from C2 compiled code [v11] In-Reply-To: References: Message-ID: > This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types. > > ## Usage > > Suppose we have this piece of Java code, that simply computes an arithmetic operation, and > that we compile `square` with C2. > > class Square { > static int square(int a) { > return a * a; > } > > public static void main(String[] args) { > square(9); > } > } > > > We would like to inspect the node that contains the value returned in this method. > We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect. > > ```c++ > void Compile::return_values(JVMState* jvms) { > GraphKit kit(jvms); > Node* ret = new ReturnNode(TypeFunc::Parms, > kit.control(), > kit.i_o(), > kit.reset_memory(), > kit.frameptr(), > kit.returnadr()); > // Add zero or 1 return values > int ret_size = tf()->range()->cnt() - TypeFunc::Parms; > > > Node* return_value; > if (ret_size > 0) { > kit.inc_sp(-ret_size); // pop the return value(s) > kit.sync_jvms(); > return_value = kit.argument(0); > ret->add_req(return_value); > > // <-------------------- Simply insert this > C->make_debug_print("return: ", initial_gvn(), return_value); > } > > // bind it to root > root()->add_req(ret); > record_for_igvn(ret); > initial_gvn()->transform(ret); > } > > > We can then call run our code with `-XX:CompileCommand="compileonly,Square::square` > and we get the following output: > > > return: > int 81 > > > This case is of course trivial, but more useful examples are shown later. > > ## Implementation > > The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed. > > The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the `CallLeafNode` constructor. > > The first argument to the runtime printing method is the printing message, a static string encoded as a `... Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision: Remove implicit null check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26475/files - new: https://git.openjdk.org/jdk/pull/26475/files/6215d510..6fd07ada Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26475&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26475&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26475.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26475/head:pull/26475 PR: https://git.openjdk.org/jdk/pull/26475 From mbaesken at openjdk.org Tue Sep 23 15:16:25 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 23 Sep 2025 15:16:25 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps [v2] In-Reply-To: References: <-WkhOYIVIwW6mihulRE5GDoJAXFnZhhpeitDypIFEwU=.b6890075-7165-4b8d-9f62-91dcb861352c@github.com> Message-ID: On Tue, 23 Sep 2025 14:36:37 GMT, Thomas Stuefe wrote: > Therefore, I'd like to understand better what the problem is. hs-err files are quite small, at least in comparison to typical cores. We can disable core files by default, while hs-err files would still be generated. Would that be a compromise? That sounds reasonable ; currently we have still lots of asan reports/issues so having (many) cores would be very bad for us. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27446#issuecomment-3324455269 From jbechberger at openjdk.org Tue Sep 23 15:02:51 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Tue, 23 Sep 2025 15:02:51 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing [v9] In-Reply-To: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> Message-ID: > This change hopefully fixes the test failures by making the test cases more resilient. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Fix build issue ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27293/files - new: https://git.openjdk.org/jdk/pull/27293/files/9a6f8b3b..afd9815f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27293&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27293&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27293.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27293/head:pull/27293 PR: https://git.openjdk.org/jdk/pull/27293 From mbaesken at openjdk.org Tue Sep 23 15:30:18 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 23 Sep 2025 15:30:18 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v4] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 14:10:47 GMT, Thomas Stuefe wrote: >> On Linux, ASAN only shows some internal thread designation on reports, e.g. `T49`, which is useless. >> >> This patch adds the ability to see the real internal JVM thread names or user-supplied Java thread names in ASAN. This makes it possible to correlate ASAN reports with hs-err file reports (if ASAN is run with `halt_on_error=0` to give us a chance to get an hs-err file) or with a thread dump done beforehand. >> >> Note that it can only show up to 15 characters, though. Therefore, the patch tries to be smart about names that end in digits: such numbers are preserved such that the truncation happens in the middle of the name, e.g.: >> >> `"MyAllocationWorkerThread#4411"` -> `"MyAllocat..4411"` >> >> This latter improvement now also applies to thread names in gdb, since they are subject to the same limitation. >> >> For a detailed analysis of why the old version, using libpthread's `pthread_setname_np`, is not sufficient for thread names in ASAN, please see the issue description. >> >> ----- >> >> Some examples from ASAN report: >> >> Before: >> >> WRITE of size 8 at 0x7b749d2d9190 thread T49 >> >> >> Now: >> >> WRITE of size 8 at 0x7bfc2f0d8380 thread T49 (MyThread#0) >> >> >> >> ==593899==ERROR: AddressSanitizer: attempting free .. in thread T76 (MyAllocati..29) > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > review feedback src/hotspot/os/linux/os_linux.cpp line 4868: > 4866: // set name in kernel > 4867: int rc = prctl(PR_SET_NAME, buf); > 4868: assert(rc == 0, "prctl(PR_SET_NAME) failed"); shouldn't we check also the return code rc in release builds and not only assert ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27395#discussion_r2372716181 From iwalulya at openjdk.org Tue Sep 23 15:34:39 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Tue, 23 Sep 2025 15:34:39 GMT Subject: RFR: 8368367: Test jdk/jfr/event/gc/detailed/TestGCHeapMemoryUsageEvent.java fails jdk.GCHeapMemoryUsage "expected 0 > 0" [v2] In-Reply-To: <2E4HThSyBO6onGz4gXIEekO6Xi-LbLfnsPH5jiVBrgU=.813dfd55-7cb4-4fc2-86f6-f4b9bb6c168a@github.com> References: <2E4HThSyBO6onGz4gXIEekO6Xi-LbLfnsPH5jiVBrgU=.813dfd55-7cb4-4fc2-86f6-f4b9bb6c168a@github.com> Message-ID: On Tue, 23 Sep 2025 14:41:18 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to the TestGCHeapMemoryUsageEvent test that checks whether these kind of events are posted and contain some sensibles values. >> >> In this failure, the `used` metric for the first of two events that is checked was zero. This is because G1, the default collector, updates the `used` value only at certain synchronization points to avoid inconsistencies in other cases. One of these synchronization points is region refill. With the 30gb heap in the test environment, region size is larger than what is allocated during startup, so no region refill/synchronization point has been reached yet, and `used` turns out to be `0`. >> >> This change fixes this by checking the last event instead of the first, it must have happened after that `system.gc()` call in the test, and `used` ought to be larger than zero because of allocations during VM startup. >> >> An alternative could be limiting the test's heap size to something small, that would also help, but I thought this might need additional explanations. >> >> Testing: local runs with G1 heap region size >= 16M or so do not fail any more. >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * fix copyright year Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27451#pullrequestreview-3258591606 From alanb at openjdk.org Tue Sep 23 15:53:37 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 23 Sep 2025 15:53:37 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final In-Reply-To: <_p9u9mX5mBTeHuKdLY3uATLLs-hrHENJleIpMN2mMko=.6a686db2-314c-4b76-8876-d94558fbbd41@github.com> References: <_p9u9mX5mBTeHuKdLY3uATLLs-hrHENJleIpMN2mMko=.6a686db2-314c-4b76-8876-d94558fbbd41@github.com> Message-ID: On Tue, 23 Sep 2025 05:09:24 GMT, David Holmes wrote: >> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500). >> >> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP. >> >> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX). >> >> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package. >> >> Testing: tier1-6 > > src/hotspot/share/prims/jni.cpp line 1873: > >> 1871: if (log_is_enabled(Debug, jni)) { >> 1872: fieldDescriptor fd; >> 1873: bool found = InstanceKlass::cast(klass)->find_field_from_offset(offset, true, &fd); > > If you are assuming/expecting an `InstanceKlass` then that should be the type of the parameter. (The existing code needs a cleanup in this area too but that is outside the scope of this PR.) Okay, but it will mean a cast in the jni_SetXXField callers, I don't think we avoid that before more changes to the existing code. > src/hotspot/share/prims/jniCheck.cpp line 1224: > >> 1222: WRAPPER_GetField(jdouble, Double, T_DOUBLE) >> 1223: >> 1224: static void checkCanSetInstanceField(JavaThread* thr, jfieldID fid, jobject obj) { > > There is a lot of duplication here with logic already performed in `checkInstanceFieldID` - can you not just pass an extra argument `is_set` to that and include the new checks there? And similarly for the static case. Given that checkInstanceFieldID and checkStaticFieldID already have a list of checks then adding it to these functions, rather than new functions, would be better, I'll do that. > test/jdk/java/lang/reflect/Field/mutateFinals/jni/JNIAttachMutatorTest.java line 29: > >> 27: * @summary Test native thread attaching to the VM with JNI AttachCurrentThread and directly >> 28: * invoking Field.set to set a final field >> 29: * @requires (os.family == "linux" | os.family == "mac") > > This test should work for any non-Windows platform using pthreads. We can make it work on Windows too but means `#ifdef WIN32` and CreateThread in the test, easy to do, and means the `@requires` can do away. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2372772061 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2372771913 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2372773863 From alanb at openjdk.org Tue Sep 23 15:53:42 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 23 Sep 2025 15:53:42 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 13:53:28 GMT, Chen Liang wrote: >> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500). >> >> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP. >> >> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX). >> >> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package. >> >> Testing: tier1-6 > > src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 3449: > >> 3447: } >> 3448: // check if write access to final field allowed >> 3449: if (!field.isStatic() && isAccessible && allowedModes != TRUSTED) { > > I don't think we need this allowedModes special permission - I see no scenario in which the core libraries implementation needs to perform such a reflective operation. Thanks for pointing that out. It used to be required due to re-implementation of core reflection but you are right that it shouldn't be there now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2372776072 From alanb at openjdk.org Tue Sep 23 15:53:40 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 23 Sep 2025 15:53:40 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 18:56:26 GMT, Vladimir Ivanov wrote: >> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500). >> >> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP. >> >> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX). >> >> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package. >> >> Testing: tier1-6 > > src/hotspot/share/runtime/fieldDescriptor.cpp line 49: > >> 47: } >> 48: >> 49: bool fieldDescriptor::is_mutable_static_final() const { > > Please, migrate `ciField::initialize_from()` from ad-hoc checks to `fieldDescriptor::is_mutable_static_final()`. > > > diff --git a/src/hotspot/share/ci/ciField.cpp b/src/hotspot/share/ci/ciField.cpp > index cbe0cadbc93..dffc387612d 100644 > --- a/src/hotspot/share/ci/ciField.cpp > +++ b/src/hotspot/share/ci/ciField.cpp > @@ -267,17 +267,7 @@ void ciField::initialize_from(fieldDescriptor* fd) { > // not be constant is when the field is a *special* static & final field > // whose value may change. The three examples are java.lang.System.in, > // java.lang.System.out, and java.lang.System.err. > - assert(vmClasses::System_klass() != nullptr, "Check once per vm"); > - if (k == vmClasses::System_klass()) { > - // Check offsets for case 2: System.in, System.out, or System.err > - if (_offset == java_lang_System::in_offset() || > - _offset == java_lang_System::out_offset() || > - _offset == java_lang_System::err_offset()) { > - _is_constant = false; > - return; > - } > - } > - _is_constant = true; > + _is_constant = !fd->is_mutable_static_final(); > } else { > // An instance field can be constant if it's a final static field or if > // it's a final non-static field of a trusted class (classes in Thanks, that does improve ciField::initialize_from. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2372777742 From ayang at openjdk.org Tue Sep 23 16:43:52 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 23 Sep 2025 16:43:52 GMT Subject: RFR: 8368367: Test jdk/jfr/event/gc/detailed/TestGCHeapMemoryUsageEvent.java fails jdk.GCHeapMemoryUsage "expected 0 > 0" [v2] In-Reply-To: <2E4HThSyBO6onGz4gXIEekO6Xi-LbLfnsPH5jiVBrgU=.813dfd55-7cb4-4fc2-86f6-f4b9bb6c168a@github.com> References: <2E4HThSyBO6onGz4gXIEekO6Xi-LbLfnsPH5jiVBrgU=.813dfd55-7cb4-4fc2-86f6-f4b9bb6c168a@github.com> Message-ID: On Tue, 23 Sep 2025 14:41:18 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to the TestGCHeapMemoryUsageEvent test that checks whether these kind of events are posted and contain some sensibles values. >> >> In this failure, the `used` metric for the first of two events that is checked was zero. This is because G1, the default collector, updates the `used` value only at certain synchronization points to avoid inconsistencies in other cases. One of these synchronization points is region refill. With the 30gb heap in the test environment, region size is larger than what is allocated during startup, so no region refill/synchronization point has been reached yet, and `used` turns out to be `0`. >> >> This change fixes this by checking the last event instead of the first, it must have happened after that `system.gc()` call in the test, and `used` ought to be larger than zero because of allocations during VM startup. >> >> An alternative could be limiting the test's heap size to something small, that would also help, but I thought this might need additional explanations. >> >> Testing: local runs with G1 heap region size >= 16M or so do not fail any more. >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * fix copyright year Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27451#pullrequestreview-3258843567 From ayang at openjdk.org Tue Sep 23 16:45:04 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 23 Sep 2025 16:45:04 GMT Subject: RFR: 8352069: Renamings after JEP 522: G1 GC: Improve Throughput by Reducing Synchronization In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 11:45:08 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that implements some deferred cleanups from JEP 522. > > Just some renaming for all platform-specific files. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27450#pullrequestreview-3258845985 From ayang at openjdk.org Tue Sep 23 16:47:09 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 23 Sep 2025 16:47:09 GMT Subject: RFR: 8365191: Cleanup after removing LockingMode related code In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 09:29:57 GMT, Fredrik Bredberg wrote: > This is a general cleanup after removing `LockingMode` related code. > It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261). > It includes: > - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking. > - Removing or rewriting comments, arguments or functions that are related to displaced headers. > - Remove "always true" parameter from `MonitorExitStub`. > - Re-type/name metadata in `BasicLock`. > > Tier1-5 passes okay on supported platforms. > > All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu. Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27448#pullrequestreview-3258855405 From coleenp at openjdk.org Tue Sep 23 17:33:54 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 23 Sep 2025 17:33:54 GMT Subject: RFR: 8365191: Cleanup after removing LockingMode related code In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 09:29:57 GMT, Fredrik Bredberg wrote: > This is a general cleanup after removing `LockingMode` related code. > It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261). > It includes: > - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking. > - Removing or rewriting comments, arguments or functions that are related to displaced headers. > - Remove "always true" parameter from `MonitorExitStub`. > - Re-type/name metadata in `BasicLock`. > > Tier1-5 passes okay on supported platforms. > > All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu. This looks really good with a couple of minor comments. src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 171: > 169: nonstatic_field(Array, _data[0], Klass*) \ > 170: \ > 171: volatile_nonstatic_field(BasicLock, _monitor, ObjectMonitor*) \ I don't see any references to this in the JVMCI code either. I assume the compiler/jvmci tests all passed with this change without any change to jvmci code. Maybe @mur47x111 can confirm. src/hotspot/share/runtime/vmStructs.cpp line 685: > 683: volatile_nonstatic_field(ObjectMonitor, _owner, int64_t) \ > 684: volatile_nonstatic_field(ObjectMonitor, _next_om, ObjectMonitor*) \ > 685: volatile_nonstatic_field(BasicLock, _monitor, ObjectMonitor*) \ Since nothing now refers to this, you can delete it from vmStructs. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27448#pullrequestreview-3258983275 PR Review Comment: https://git.openjdk.org/jdk/pull/27448#discussion_r2373014053 PR Review Comment: https://git.openjdk.org/jdk/pull/27448#discussion_r2373006396 From mli at openjdk.org Tue Sep 23 17:35:57 2025 From: mli at openjdk.org (Hamlin Li) Date: Tue, 23 Sep 2025 17:35:57 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v5] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 09:22:39 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> >> Currently, the cpu features of riscv are stored in separate RVFeature subclasses. >> But to support the store/restore CPU features for aot in the future, we need to store the cpu features in a continuous memory. >> As the riscv extensions are introduced continuously, I think it's better to do it via an simple bitmap at the beginning. >> Currently, just suppose the non-extension features will not be stored in aot image, so I also split the extension and non-extenion features. When we implement the related aot feature in the short future, we can revisit the way of splitting the features. Currently, just change the storage way of cpu features, lay the foundation for future aot. >> >> Thanks > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > simplify names Hey @luhenry @RealFYang , do you have further comments I need to address? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27152#issuecomment-3324945208 From duke at openjdk.org Tue Sep 23 17:59:02 2025 From: duke at openjdk.org (Ruben) Date: Tue, 23 Sep 2025 17:59:02 GMT Subject: RFR: 8365153: AArch64: Set JVM flags for Neoverse N3 and V3 cores In-Reply-To: References: Message-ID: On Fri, 8 Aug 2025 14:50:13 GMT, Ruben wrote: > For Neoverse N1, N2, V1, and V2, the following JVM flags are set: > - UseSIMDForMemoryOps=true > - OnSpinWaitInst=isb > - OnSpinWaitInstCount=1 > - AlwaysMergeDMB=false > > Additionally, for Neoverse V1 and V2 only, these flags are set: > - UseCryptoPmullForCRC32=true > - CodeEntryAlignment=32 > > Set the same flags for Neoverse N3 and V3, respectively. @theRealAph, could you please take a look? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26701#issuecomment-3325011109 From alanb at openjdk.org Tue Sep 23 18:03:54 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 23 Sep 2025 18:03:54 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v2] In-Reply-To: References: Message-ID: > Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500). > > Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP. > > HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX). > > There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package. > > Testing: tier1-6 Alan Bateman has updated the pull request incrementally with two additional commits since the last revision: - Review feedback - Change ciField::initialize_from to use is_mutable_static_final, suggested by Vladimir Ivanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25115/files - new: https://git.openjdk.org/jdk/pull/25115/files/bfad2bbe..950aa9d7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25115&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25115&range=00-01 Stats: 113 lines in 8 files changed: 34 ins; 56 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/25115.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25115/head:pull/25115 PR: https://git.openjdk.org/jdk/pull/25115 From alanb at openjdk.org Tue Sep 23 18:03:55 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 23 Sep 2025 18:03:55 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v2] In-Reply-To: <25ixE0_d_fp6zlqECkYMelk1PNpwgKAAmBNruu8xabc=.ea63f0ae-667a-4ca9-89de-1c3cd29a3219@github.com> References: <_p9u9mX5mBTeHuKdLY3uATLLs-hrHENJleIpMN2mMko=.6a686db2-314c-4b76-8876-d94558fbbd41@github.com> <25ixE0_d_fp6zlqECkYMelk1PNpwgKAAmBNruu8xabc=.ea63f0ae-667a-4ca9-89de-1c3cd29a3219@github.com> Message-ID: On Tue, 23 Sep 2025 14:39:34 GMT, Vladimir Ivanov wrote: >> src/hotspot/share/runtime/fieldDescriptor.cpp line 53: >> >>> 51: // write protected fields (JLS 17.5.4) >>> 52: if (is_final() && is_static() && ik == vmClasses::System_klass() && >>> 53: (offset() == java_lang_System::in_offset() || offset() == java_lang_System::out_offset() || offset() == java_lang_System::err_offset())) { >> >> I thought the ability to mutate these fields was restricted to the native implementations of `setIn` et al. and was not allowed via regular reflection? Otherwise how can these fields be considered as "trusted finals"?? > >> Otherwise how can these fields be considered as "trusted finals"?? > > FTR `System.in` et al are not considered as trusted finals. There's a special logic in `ciField::initialize_from()` to disable corresponding optimizations, so the fields aren't treated as constants. > I thought the ability to mutate these fields was restricted to the native implementations of setIn et al. and was not allowed via regular reflection? Right, core reflection can't modify static finals. JLS 17.5.4 labels System.in/out/err as write-protected fields that can be modified by the setIn/setOut/setErr methods. Historical and unfortunate, and works because these methods were always in JNI. The existence of these methods means the VM can't trust these fields and so has to special case them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2373075650 From missa at openjdk.org Tue Sep 23 19:11:49 2025 From: missa at openjdk.org (Mohamed Issa) Date: Tue, 23 Sep 2025 19:11:49 GMT Subject: RFR: 8367611: Enable vblendvp[sd] on Future ECore [v3] In-Reply-To: References: <_Jk5fv1iO9ZPZyOtUAXeUez481RibKJR4FsUT_BnKm8=.2f68f9ee-9ce2-4dbb-be8b-1b9f910ba0e0@github.com> Message-ID: On Tue, 23 Sep 2025 14:00:51 GMT, Vladimir Ivanov wrote: > The patch itself looks fine, but the way instruction emulation is implemented (as introduced by JDK-8320347) doesn't fit the design well. It does look appealing to abstract away the choice, but it becomes confusing when there's a need to reason about exact code shape. Another consequence is code duplication where both x86.ad and `MacroAssembler::vblendvp[sd]` provide their own emulated versions. > > I suggest to reshape it and extract emulated variant into separate methods leaving `Assembler::vblendvp[sd]` as is. Then, for convenience, `C2_MacroAssembler` can provide new methods which do CPU dispatching or just do dispatching explicitly at call sites in `c2_MacroAssembler_x86.cpp`. Also, it's better to move CPU sensing logic to `VM_Version`, so the checks and code emission logic can be unified across all use sites (in `c2_MacroAssembler_x86.cpp` and `x86.ad`). > > I'm fine with addressing it either as part of this PR or as a follow-up enhancement. Thank you for the suggestion. I created [JDK-8368492](https://bugs.openjdk.org/browse/JDK-8368492) to track the enhancement. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27354#issuecomment-3325213645 From missa at openjdk.org Tue Sep 23 19:11:50 2025 From: missa at openjdk.org (Mohamed Issa) Date: Tue, 23 Sep 2025 19:11:50 GMT Subject: RFR: 8367611: Enable vblendvp[sd] on Future ECore [v3] In-Reply-To: References: <_Jk5fv1iO9ZPZyOtUAXeUez481RibKJR4FsUT_BnKm8=.2f68f9ee-9ce2-4dbb-be8b-1b9f910ba0e0@github.com> Message-ID: <10RF-SXtaEmCYwrS2YMXW-rWB8Iwz6HbNlQmNyWCfG8=.ed216967-9ade-44d9-8ece-db1ae9359a5e@github.com> On Tue, 23 Sep 2025 19:06:49 GMT, Mohamed Issa wrote: >> The patch itself looks fine, but the way instruction emulation is implemented (as introduced by JDK-8320347) doesn't fit the design well. It does look appealing to abstract away the choice, but it becomes confusing when there's a need to reason about exact code shape. Another consequence is code duplication where both x86.ad and `MacroAssembler::vblendvp[sd]` provide their own emulated versions. >> >> I suggest to reshape it and extract emulated variant into separate methods leaving `Assembler::vblendvp[sd]` as is. Then, for convenience, `C2_MacroAssembler` can provide new methods which do CPU dispatching or just do dispatching explicitly at call sites in `c2_MacroAssembler_x86.cpp`. Also, it's better to move CPU sensing logic to `VM_Version`, so the checks and code emission logic can be unified across all use sites (in `c2_MacroAssembler_x86.cpp` and `x86.ad`). >> >> I'm fine with addressing it either as part of this PR or as a follow-up enhancement. > >> The patch itself looks fine, but the way instruction emulation is implemented (as introduced by JDK-8320347) doesn't fit the design well. It does look appealing to abstract away the choice, but it becomes confusing when there's a need to reason about exact code shape. Another consequence is code duplication where both x86.ad and `MacroAssembler::vblendvp[sd]` provide their own emulated versions. >> >> I suggest to reshape it and extract emulated variant into separate methods leaving `Assembler::vblendvp[sd]` as is. Then, for convenience, `C2_MacroAssembler` can provide new methods which do CPU dispatching or just do dispatching explicitly at call sites in `c2_MacroAssembler_x86.cpp`. Also, it's better to move CPU sensing logic to `VM_Version`, so the checks and code emission logic can be unified across all use sites (in `c2_MacroAssembler_x86.cpp` and `x86.ad`). >> >> I'm fine with addressing it either as part of this PR or as a follow-up enhancement. > > Thank you for the suggestion. I created [JDK-8368492](https://bugs.openjdk.org/browse/JDK-8368492) to track the enhancement. > Hi @missa-prime , VBLENDVPS was always supported by AVX2 targets. We enabled its software emulation for performance reasons, as these needs microcode assistance on AVX2 targets. > image > > It seems your PR is lifting this limitation for Darkmont under a constraint on dst and src1 register equivalence? > > Please add appropriate comments in code and documentary reference to the relevant section of the Intel Architectural Set Extension Manual. Currently, there is no public documentation mentioning the (dst == src1) register optimization on Darkmont. Once it's available, I'll add comments and reference it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27354#issuecomment-3325219482 From duke at openjdk.org Tue Sep 23 19:16:05 2025 From: duke at openjdk.org (duke) Date: Tue, 23 Sep 2025 19:16:05 GMT Subject: RFR: 8367611: Enable vblendvp[sd] on Future ECore [v3] In-Reply-To: References: <_Jk5fv1iO9ZPZyOtUAXeUez481RibKJR4FsUT_BnKm8=.2f68f9ee-9ce2-4dbb-be8b-1b9f910ba0e0@github.com> Message-ID: On Fri, 19 Sep 2025 21:57:30 GMT, Mohamed Issa wrote: >> The upcoming ECore platforms will benefit from using `vblendvps` and `vblendvpd` instructions when the destination register is the same as the source register. This change takes that situation into account. >> >> The JTREG test shown below was used to verify correctness against the [OpenJDK v26-b15](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B15) baseline build. This test frequently calls vblendvps() and vblendvpd() in the macro assembler. On Darkmont and non-Darkmont cores, the right code paths are followed when checking with asserts. >> >> 1. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` > > Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: > > Combine boolean flags to avoid ambiguity @missa-prime Your change (at version 5e5c02750580530d64d9f87c7b240f4d30356914) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27354#issuecomment-3325231494 From missa at openjdk.org Tue Sep 23 20:23:51 2025 From: missa at openjdk.org (Mohamed Issa) Date: Tue, 23 Sep 2025 20:23:51 GMT Subject: Integrated: 8367611: Enable vblendvp[sd] on Future ECore In-Reply-To: <_Jk5fv1iO9ZPZyOtUAXeUez481RibKJR4FsUT_BnKm8=.2f68f9ee-9ce2-4dbb-be8b-1b9f910ba0e0@github.com> References: <_Jk5fv1iO9ZPZyOtUAXeUez481RibKJR4FsUT_BnKm8=.2f68f9ee-9ce2-4dbb-be8b-1b9f910ba0e0@github.com> Message-ID: On Wed, 17 Sep 2025 20:58:06 GMT, Mohamed Issa wrote: > The upcoming ECore platforms will benefit from using `vblendvps` and `vblendvpd` instructions when the destination register is the same as the source register. This change takes that situation into account. > > The JTREG test shown below was used to verify correctness against the [OpenJDK v26-b15](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B15) baseline build. This test frequently calls vblendvps() and vblendvpd() in the macro assembler. On Darkmont and non-Darkmont cores, the right code paths are followed when checking with asserts. > > 1. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` This pull request has now been integrated. Changeset: f68cba3d Author: Mohamed Issa Committer: Sandhya Viswanathan URL: https://git.openjdk.org/jdk/commit/f68cba3d2fe3554c3cf0c3edf60ab639d6b13a6f Stats: 10 lines in 3 files changed: 8 ins; 0 del; 2 mod 8367611: Enable vblendvp[sd] on Future ECore Reviewed-by: mhaessig, sviswanathan, vpaprotski ------------- PR: https://git.openjdk.org/jdk/pull/27354 From kvn at openjdk.org Tue Sep 23 20:42:09 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 23 Sep 2025 20:42:09 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry [v4] In-Reply-To: <2UylqHUZAgA-izpoDL1mO8qvxhSTGX3CLmFtEL-PEBc=.6fd0d223-8eac-4c39-9a00-c975aa288b26@github.com> References: <2UylqHUZAgA-izpoDL1mO8qvxhSTGX3CLmFtEL-PEBc=.6fd0d223-8eac-4c39-9a00-c975aa288b26@github.com> Message-ID: On Tue, 23 Sep 2025 15:00:42 GMT, Ashutosh Mehra wrote: > I think I will update the getters to remove `ShouldNotReachHere` and just return nullptr. Good! I don't like how they look now. Previous version was better. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27101#issuecomment-3325483611 From asmehra at openjdk.org Tue Sep 23 21:27:40 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 23 Sep 2025 21:27:40 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry [v5] In-Reply-To: References: Message-ID: > This PR removes the need to store entry point addresses in AdapterHandlerEntry by storing a direct pointer to AdapterBlob instead. Entry point addresses can be computed on the fly from the entry point offsets stored in AdapterBlob. Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: Remove incorrectly placed ShouldNotReachHere statements Signed-off-by: Ashutosh Mehra ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27101/files - new: https://git.openjdk.org/jdk/pull/27101/files/1c3d1744..3cfd33e6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27101&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27101&range=03-04 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27101.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27101/head:pull/27101 PR: https://git.openjdk.org/jdk/pull/27101 From iklam at openjdk.org Tue Sep 23 21:31:54 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 23 Sep 2025 21:31:54 GMT Subject: RFR: 8367387: Add @AOTInitialize annotation [v6] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 17:24:29 GMT, Ioi Lam wrote: >> This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. >> >> This PR annotates a single class, `jdk.internal.math.MathUtils` (also the object hierarchy root class, `Object.class`, which has no associated AOT initialization but is required for completeness). More classes will be added in future PRs. >> >> If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to >> - All of `K`'s super classes >> - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` >> >> Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). >> >> This annotation is awfully similar to `@AOTSafeClassInitializer`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @liach comment - fixed typo in logging Closing this PR as the preferred alternative is https://github.com/openjdk/jdk/pull/27402. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27024#issuecomment-3325617496 From vaivanov at openjdk.org Tue Sep 23 21:32:28 2025 From: vaivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 23 Sep 2025 21:32:28 GMT Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays [v6] In-Reply-To: References: Message-ID: <7gJczh6ri60WEbefTyHaTrV0V500CWi6VNQgKYa8I-Y=.e71307cc-87aa-4298-b5ba-bddff502dfcb@github.com> > On the SRF platform for runs with intrinsic scores for the ArrayFill test reports ~2x drop for several sizes due to a lot of the 'MEM_UOPS_RETIRED.SPLIT_STORES' events. The 'good' case for the ArraysFill.testCharFill with size=8195 reports numbers like > MEM_UOPS_RETIRED.SPLIT_LOADS | 22.6711 > MEM_UOPS_RETIRED.SPLIT_STORES | 4.0859 > while for 'bad' case these metrics are > MEM_UOPS_RETIRED.SPLIT_LOADS | 69.1785 > MEM_UOPS_RETIRED.SPLIT_STORES | 259200.3659 > > With alignment on the cache size no score drops due to split_stores but small reduction may be reported due to extra > SRF 6740E | Size | orig | pathed | pO/orig > -- | -- | -- | -- | -- > ArraysFill.testByteFill | 16 | 152031.2 | 157001.2 | 1.03 > ArraysFill.testByteFill | 31 | 125795.9 | 177399.2 | 1.41 > ArraysFill.testByteFill | 250 | 57961.69 | 120981.9 | 2.09 > ArraysFill.testByteFill | 266 | 44900.15 | 147893.8 | 3.29 > ArraysFill.testByteFill | 511 | 61908.17 | 129830.1 | 2.10 > ArraysFill.testByteFill | 2047 | 32255.51 | 41986.6 | 1.30 > ArraysFill.testByteFill | 2048 | 31928.97 | 42154.3 | 1.32 > ArraysFill.testByteFill | 8195 | 10690.15 | 11036.3 | 1.03 > ArraysFill.testIntFill | 16 | 145030.7 | 318796.9 | 2.20 > ArraysFill.testIntFill | 31 | 134138.4 | 212487 | 1.58 > ArraysFill.testIntFill | 250 | 74179.23 | 79522.66 | 1.07 > ArraysFill.testIntFill | 266 | 68112.72 | 60116.49 | 0.88 > ArraysFill.testIntFill | 511 | 39693.28 | 36225.09 | 0.91 > ArraysFill.testIntFill | 2047 | 11504.14 | 10616.91 | 0.92 > ArraysFill.testIntFill | 2048 | 11244.71 | 10969.14 | 0.98 > ArraysFill.testIntFill | 8195 | 2751.289 | 2692.216 | 0.98 > ArraysFill.testLongFill | 16 | 212532.5 | 212526 | 1.00 > ArraysFill.testLongFill | 31 | 137432.4 | 137283.3 | 1.00 > ArraysFill.testLongFill | 250 | 43185 | 43159.78 | 1.00 > ArraysFill.testLongFill | 266 | 42172.22 | 42170.5 | 1.00 > ArraysFill.testLongFill | 511 | 23370.15 | 23370.86 | 1.00 > ArraysFill.testLongFill | 2047 | 6123.008 | 6122.73 | 1.00 > ArraysFill.testLongFill | 2048 | 5793.722 | 5792.855 | 1.00 > ArraysFill.testLongFill | 8195 | 616.552 | 616.585 | 1.00 > ArraysFill.testShortFill | 16 | 152088.6 | 265646.1 | 1.75 > ArraysFill.testShortFill | 31 | 137369.8 | 185596.4 | 1.35 > ArraysFill.testShortFill | 250 | 58872.03 | 99621.15 | 1.69 > ArraysFill.testShortFill | 266 | 91085.31 | 93746.62 | 1.03 > ArraysFill.testShortFill | 511 | 65331.96 | 78003.83 | 1.19 > ArraysFill.testShortFill | 2047 | 21716.32 | 21216.81 | 0.98 > ArraysFill.testShortFill | 2048 | 21664.91 | 21328.72 | 0.98 > ArraysFill.testShortFill | 8195 | 5922.547 | ... Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26747/files - new: https://git.openjdk.org/jdk/pull/26747/files/13c0fef6..b20035dd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26747&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26747&range=04-05 Stats: 15 lines in 1 file changed: 9 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26747.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26747/head:pull/26747 PR: https://git.openjdk.org/jdk/pull/26747 From iklam at openjdk.org Tue Sep 23 21:31:55 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 23 Sep 2025 21:31:55 GMT Subject: Withdrawn: 8367387: Add @AOTInitialize annotation In-Reply-To: References: Message-ID: On Sun, 31 Aug 2025 20:30:58 GMT, Ioi Lam wrote: > This PR adds a new annotation, `@AOTInitialize` that forces a class to be (a) initialized in the AOT assembly phase, and (b) stored in the AOT cache in an already initialized state. This means that all the static fields in this class will be immediately available upon JVM bootstrap when the AOT cache is used in an application's production run. > > This PR annotates a single class, `jdk.internal.math.MathUtils` (also the object hierarchy root class, `Object.class`, which has no associated AOT initialization but is required for completeness). More classes will be added in future PRs. > > If a class `K` has the `@AOTInitialize` annotation, the same annotation must be also added to > - All of `K`'s super classes > - All of `K`'s super interfaces that require to be initialized when `K` is initialized (see JVMS 5.5. Initialization, step 7; also C++ function `InstanceKlass::interface_needs_clinit_execution_as_super()` > > Note, the check of the above requirement has been moved to `AOTClassInitializer::check_aot_annotations()`. The previous check in `ClassFileParser` was not executed because the class is loaded in the AOT training run, where `CDSConfig::is_initing_classes_at_dump_time()` returns `false` (this function returns `true` only in the AOT assembly phase). > > This annotation is awfully similar to `@AOTSafeClassInitializer`, and I am not sure if we need both. Please see the javadoc in `@AOTInitialize` to see the difference between the two annotations. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27024 From vaivanov at openjdk.org Tue Sep 23 21:34:35 2025 From: vaivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 23 Sep 2025 21:34:35 GMT Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays [v5] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 16:19:33 GMT, Vladimir Ivanov wrote: >> On the SRF platform for runs with intrinsic scores for the ArrayFill test reports ~2x drop for several sizes due to a lot of the 'MEM_UOPS_RETIRED.SPLIT_STORES' events. The 'good' case for the ArraysFill.testCharFill with size=8195 reports numbers like >> MEM_UOPS_RETIRED.SPLIT_LOADS | 22.6711 >> MEM_UOPS_RETIRED.SPLIT_STORES | 4.0859 >> while for 'bad' case these metrics are >> MEM_UOPS_RETIRED.SPLIT_LOADS | 69.1785 >> MEM_UOPS_RETIRED.SPLIT_STORES | 259200.3659 >> >> With alignment on the cache size no score drops due to split_stores but small reduction may be reported due to extra >> SRF 6740E | Size | orig | pathed | pO/orig >> -- | -- | -- | -- | -- >> ArraysFill.testByteFill | 16 | 152031.2 | 157001.2 | 1.03 >> ArraysFill.testByteFill | 31 | 125795.9 | 177399.2 | 1.41 >> ArraysFill.testByteFill | 250 | 57961.69 | 120981.9 | 2.09 >> ArraysFill.testByteFill | 266 | 44900.15 | 147893.8 | 3.29 >> ArraysFill.testByteFill | 511 | 61908.17 | 129830.1 | 2.10 >> ArraysFill.testByteFill | 2047 | 32255.51 | 41986.6 | 1.30 >> ArraysFill.testByteFill | 2048 | 31928.97 | 42154.3 | 1.32 >> ArraysFill.testByteFill | 8195 | 10690.15 | 11036.3 | 1.03 >> ArraysFill.testIntFill | 16 | 145030.7 | 318796.9 | 2.20 >> ArraysFill.testIntFill | 31 | 134138.4 | 212487 | 1.58 >> ArraysFill.testIntFill | 250 | 74179.23 | 79522.66 | 1.07 >> ArraysFill.testIntFill | 266 | 68112.72 | 60116.49 | 0.88 >> ArraysFill.testIntFill | 511 | 39693.28 | 36225.09 | 0.91 >> ArraysFill.testIntFill | 2047 | 11504.14 | 10616.91 | 0.92 >> ArraysFill.testIntFill | 2048 | 11244.71 | 10969.14 | 0.98 >> ArraysFill.testIntFill | 8195 | 2751.289 | 2692.216 | 0.98 >> ArraysFill.testLongFill | 16 | 212532.5 | 212526 | 1.00 >> ArraysFill.testLongFill | 31 | 137432.4 | 137283.3 | 1.00 >> ArraysFill.testLongFill | 250 | 43185 | 43159.78 | 1.00 >> ArraysFill.testLongFill | 266 | 42172.22 | 42170.5 | 1.00 >> ArraysFill.testLongFill | 511 | 23370.15 | 23370.86 | 1.00 >> ArraysFill.testLongFill | 2047 | 6123.008 | 6122.73 | 1.00 >> ArraysFill.testLongFill | 2048 | 5793.722 | 5792.855 | 1.00 >> ArraysFill.testLongFill | 8195 | 616.552 | 616.585 | 1.00 >> ArraysFill.testShortFill | 16 | 152088.6 | 265646.1 | 1.75 >> ArraysFill.testShortFill | 31 | 137369.8 | 185596.4 | 1.35 >> ArraysFill.testShortFill | 250 | 58872.03 | 99621.15 | 1.69 >> ArraysFill.testShortFill | 266 | 91085.31 | 93746.62 | 1.03 >> ArraysFill.testShortFill | 511 | 65331.96 | 78003.83 | 1.19 >> ArraysFill.testShortFill | 2047 | 21716.32 | 21216.81 | 0.98 >> ArraysFill.testShortFill... > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays Update patch to add copy by 4 bytes for small arrays. Current data for the SRF looks as: Xeon 6740E | size | jdk_def | patched | p/def -- | -- | -- | -- | -- ArraysFill.testByteFill | 16 | 152077.563 | 181775.55 | 1.20 ArraysFill.testByteFill | 31 | 125702.057 | 219355.70 | 1.75 ArraysFill.testByteFill | 250 | 57965.263 | 131939.32 | 2.28 ArraysFill.testByteFill | 266 | 44901.157 | 158565.86 | 3.53 ArraysFill.testByteFill | 511 | 61918.237 | 113853.31 | 1.84 ArraysFill.testByteFill | 2047 | 32222.184 | 41441.08 | 1.29 ArraysFill.testByteFill | 2048 | 31930.607 | 41683.49 | 1.31 ArraysFill.testByteFill | 8195 | 10690.434 | 11023.39 | 1.03 ArraysFill.testIntFill | 16 | 144979.804 | 289845.67 | 2.00 ArraysFill.testIntFill | 31 | 133495.302 | 199261.82 | 1.49 ArraysFill.testIntFill | 250 | 74178.893 | 72469.33 | 0.98 ArraysFill.testIntFill | 266 | 68009.933 | 77855.45 | 1.14 ArraysFill.testIntFill | 511 | 39688.805 | 45370.25 | 1.14 ArraysFill.testIntFill | 2047 | 11504.203 | 11288.38 | 0.98 ArraysFill.testIntFill | 2048 | 11245.331 | 11449.64 | 1.02 ArraysFill.testIntFill | 8195 | 2692.649 | 2651.02 | 0.98 ArraysFill.testLongFill | 16 | 212541.769 | 212517.35 | 1.00 ArraysFill.testLongFill | 31 | 137729.599 | 137682.36 | 1.00 ArraysFill.testLongFill | 250 | 43162.979 | 43163.37 | 1.00 ArraysFill.testLongFill | 266 | 42173.88 | 42137.63 | 1.00 ArraysFill.testLongFill | 511 | 23364.859 | 23368.62 | 1.00 ArraysFill.testLongFill | 2047 | 6122.745 | 6122.54 | 1.00 ArraysFill.testLongFill | 2048 | 5792.552 | 5794.55 | 1.00 ArraysFill.testLongFill | 8195 | 616.62 | 615.90 | 1.00 ArraysFill.testShortFill | 16 | 152176.336 | 354173.53 | 2.33 ArraysFill.testShortFill | 31 | 137527.651 | 199237.86 | 1.45 ArraysFill.testShortFill | 250 | 58930.645 | 93461.06 | 1.59 ArraysFill.testShortFill | 266 | 91088.72 | 122607.58 | 1.35 ArraysFill.testShortFill | 511 | 65332.79 | 71739.00 | 1.10 ArraysFill.testShortFill | 2047 | 21713.296 | 22552.57 | 1.04 ArraysFill.testShortFill | 2048 | 21667.468 | 22625.03 | 1.04 ArraysFill.testShortFill | 8195 | 5922.318 | 5885.62 | 0.99 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26747#issuecomment-3325621511 From dlong at openjdk.org Tue Sep 23 21:48:40 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 23 Sep 2025 21:48:40 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps [v2] In-Reply-To: <-WkhOYIVIwW6mihulRE5GDoJAXFnZhhpeitDypIFEwU=.b6890075-7165-4b8d-9f62-91dcb861352c@github.com> References: <-WkhOYIVIwW6mihulRE5GDoJAXFnZhhpeitDypIFEwU=.b6890075-7165-4b8d-9f62-91dcb861352c@github.com> Message-ID: On Tue, 23 Sep 2025 10:43:11 GMT, Thomas Stuefe wrote: >> When we run with ASAN enabled and ASAN catches an error, it reports, then stops the JVM. hs-err files and crash dumps at that point would be incredibly useful, though. The ASAN error report itself is seldom enlightening since it only contains native stacks. >> >> This patch makes it possible to get hs-err files and subsequent crash dumps by using the error callback functionality of ASAN. It registers a callback which gets called when ASAN catches an error. We then - carefully - print out the ASAN report to stderr (as ASAN itself would have done) and proceeed to end the JVM with a `fatal()`, which gives us an hs-err file, a callstack at that point including Java frames, and - if enabled - core dumps. >> >> Tested on Fedora 42 and Debian 12, both manually and by running the new companion jtreg test. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Update address.cpp I haven't tried it yet, but what happens if we cause ASAN to abort by setting the flag in the environment: `export ASAN_OPTIONS=abort_on_error=1` Do we get a useful stack trace in the hs_err file? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27446#issuecomment-3325651663 From dholmes at openjdk.org Tue Sep 23 22:04:33 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 23 Sep 2025 22:04:33 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v2] In-Reply-To: References: <_p9u9mX5mBTeHuKdLY3uATLLs-hrHENJleIpMN2mMko=.6a686db2-314c-4b76-8876-d94558fbbd41@github.com> Message-ID: <1huJ8uSVLMHhpaP-BUKKzNB9Av9tt7_8_9w4bUbyCEg=.295494ec-dc9f-4b19-b2c7-99aaea14fc25@github.com> On Tue, 23 Sep 2025 15:48:43 GMT, Alan Bateman wrote: >> src/hotspot/share/prims/jni.cpp line 1873: >> >>> 1871: if (log_is_enabled(Debug, jni)) { >>> 1872: fieldDescriptor fd; >>> 1873: bool found = InstanceKlass::cast(klass)->find_field_from_offset(offset, true, &fd); >> >> If you are assuming/expecting an `InstanceKlass` then that should be the type of the parameter. (The existing code needs a cleanup in this area too but that is outside the scope of this PR.) > > Okay, but it will mean a cast in the jni_SetXXField callers, I don't think we avoid that before more changes to the existing code. Yes there has to be a cast somewhere - but only instance classes can have fields so this is a top-level thing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2373549329 From dholmes at openjdk.org Tue Sep 23 22:04:35 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 23 Sep 2025 22:04:35 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v2] In-Reply-To: <25ixE0_d_fp6zlqECkYMelk1PNpwgKAAmBNruu8xabc=.ea63f0ae-667a-4ca9-89de-1c3cd29a3219@github.com> References: <_p9u9mX5mBTeHuKdLY3uATLLs-hrHENJleIpMN2mMko=.6a686db2-314c-4b76-8876-d94558fbbd41@github.com> <25ixE0_d_fp6zlqECkYMelk1PNpwgKAAmBNruu8xabc=.ea63f0ae-667a-4ca9-89de-1c3cd29a3219@github.com> Message-ID: On Tue, 23 Sep 2025 14:39:34 GMT, Vladimir Ivanov wrote: >> src/hotspot/share/runtime/fieldDescriptor.cpp line 53: >> >>> 51: // write protected fields (JLS 17.5.4) >>> 52: if (is_final() && is_static() && ik == vmClasses::System_klass() && >>> 53: (offset() == java_lang_System::in_offset() || offset() == java_lang_System::out_offset() || offset() == java_lang_System::err_offset())) { >> >> I thought the ability to mutate these fields was restricted to the native implementations of `setIn` et al. and was not allowed via regular reflection? Otherwise how can these fields be considered as "trusted finals"?? > >> Otherwise how can these fields be considered as "trusted finals"?? > > FTR `System.in` et al are not considered as trusted finals. There's a special logic in `ciField::initialize_from()` to disable corresponding optimizations, so the fields aren't treated as constants. @iwanowww they are not special-cased here: bool fieldDescriptor::is_trusted_final() const { InstanceKlass* ik = field_holder(); return is_final() && (is_static() || ik->is_hidden() || ik->is_record()); } and so would be reported as "trusted finals". @AlanBateman my point is, if these can only be changed via JNI code through the setX native methods, then why do we have to special case them in this code. ?? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2373552612 From iklam at openjdk.org Tue Sep 23 22:10:57 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 23 Sep 2025 22:10:57 GMT Subject: RFR: 8368174: Proactive initialization of @AOTSafeClassInitializer classes [v2] In-Reply-To: <6-YD1r_VNTgkNLBn7M11IdwnKHKWuFV3VMxwyF1Wsao=.18e5aa0f-6fee-4df1-a2e3-54c84a14133f@github.com> References: <6-YD1r_VNTgkNLBn7M11IdwnKHKWuFV3VMxwyF1Wsao=.18e5aa0f-6fee-4df1-a2e3-54c84a14133f@github.com> Message-ID: On Mon, 22 Sep 2025 09:18:22 GMT, Andrew Dinn wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Exclude new test from hotspot_aot_classlinking and hotspot_appcds_dynamic test groups >> - @adinn and @liach comments >> - Merge branch 'master' into 8368174-proactive-init-aot-safe-class-initializer >> - updated javadoc for AOTSafeClassInitializer.java >> - Fix >> - imported > > src/hotspot/share/cds/aotClassInitializer.cpp line 294: > >> 292: }); >> 293: } else { >> 294: // @AOTRuntimeSetup only meaningful in @AOTClassInitializer > > Suggestion: > > // @AOTRuntimeSetup only meaningful in @AOTSafeClassInitializer Fixed. > src/hotspot/share/cds/aotMetaspace.cpp line 815: > >> 813: FinalImageRecipes::apply_recipes(CHECK); >> 814: >> 815: // Because the AOT assembly phase does not run the exact code as in the > > Suggestion: > > // Because the AOT assembly phase does not run the exact same code as in the Fixed. > src/java.base/share/classes/jdk/internal/vm/annotation/AOTSafeClassInitializer.java line 45: > >> 43: /// _X_ can still be triggered by normal execution of Java code in the assembly phase. >> 44: /// This is usually the result of performing AOT optimizations for the >> 45: /// `java.lang.invoke` package. > > Suggestion: > > /// At present this is usually the result of performing AOT optimizations for > /// the `java.lang.invoke` package but the set of classes which may be > /// pre-initialized via this annotation is not restricted to just that case. Under this this bullet point we are talking about classes that are initialized by other reasons, and not "via this annotation". I changed the comment to the following to make it clear that the "At present ..." part is about the second scenario: /// 1. If _X_ was initialized during the AOT training run, the JVM will proactively /// initialize _X_ in the assembly phase. /// 2. If _X_ was not initialized during the AOT training run, the initialization of /// _X_ can still be triggered by normal execution of Java code in the assembly /// phase. At present this is usually the result of performing AOT optimizations for /// the `java.lang.invoke` package but it may include other cases as well. What do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27402#discussion_r2373558649 PR Review Comment: https://git.openjdk.org/jdk/pull/27402#discussion_r2373558523 PR Review Comment: https://git.openjdk.org/jdk/pull/27402#discussion_r2373558380 From iklam at openjdk.org Tue Sep 23 22:10:53 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 23 Sep 2025 22:10:53 GMT Subject: RFR: 8368174: Proactive initialization of @AOTSafeClassInitializer classes [v2] In-Reply-To: References: Message-ID: > This is an alternative to https://github.com/openjdk/jdk/pull/27024. Thanks to @ashu-mehra for the suggestion. > > ### Background: > > The AOT Assembly Phase is in essence a small Java program that executes a limited set of Java bytecodes. This program bootstraps the module system, loads classes, and performs certain ahead-of-time optimizations such as resolving `invokedynamic` call sites. > > As a side effect of Java program execution, a small set of Java classes are initialized in the Assembly Phase. > > Since [JDK-8360163](https://bugs.openjdk.org/browse/JDK-8360163), if a class `X` is annotated with `@AOTSafeClassInitializer` *and* is initialized in the Assembly Phase, then `X` will be stored in the AOT cache in the "initialized" state. When the AOT cache is used in the Production Run, `X::` will not be executed, and the static variables of `X` will be available upon JVM bootstrap. > > ### Problem: > > The Assembly Phase doesn't touch many classes that may benefit from `@AOTSafeClassInitializer`. For example, `jdk.internal.math.MathUtils::` creates a few large tables. Caching `MathUtils` in the "initialized" state will improve start-up time. However, since no bytecodes executed by the Assembly Phase use `MathUtils`. it will not be initialized. > > ### Fix: > > If a class `X` has the `@AOTSafeClassInitializer` annotation *and* was initialized in the AOT Training Run, the JVM will proactively initialize `X` in the Assembly Phase. This will ensure that `X` will be cached in the "initialized" state. > > As a proof of concept, `@AOTSafeClassInitializer` is added to `MathUtils`. `@AOTSafeClassInitializer` will be added to more classes in future RFEs. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Exclude new test from hotspot_aot_classlinking and hotspot_appcds_dynamic test groups - @adinn and @liach comments - Merge branch 'master' into 8368174-proactive-init-aot-safe-class-initializer - updated javadoc for AOTSafeClassInitializer.java - Fix - imported ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27402/files - new: https://git.openjdk.org/jdk/pull/27402/files/1fa2b1ec..774fe0ee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27402&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27402&range=00-01 Stats: 123813 lines in 925 files changed: 112515 ins; 7470 del; 3828 mod Patch: https://git.openjdk.org/jdk/pull/27402.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27402/head:pull/27402 PR: https://git.openjdk.org/jdk/pull/27402 From iklam at openjdk.org Tue Sep 23 22:10:59 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 23 Sep 2025 22:10:59 GMT Subject: RFR: 8368174: Proactive initialization of @AOTSafeClassInitializer classes [v2] In-Reply-To: <1ZQQzDNnT-fjd_9RUXuI4HYnCgOz16m1Xmqoc1wPXRE=.4f7435f9-51cc-4639-add5-fdc449c98015@github.com> References: <1ZQQzDNnT-fjd_9RUXuI4HYnCgOz16m1Xmqoc1wPXRE=.4f7435f9-51cc-4639-add5-fdc449c98015@github.com> Message-ID: <6ZauzYehFop9nv77mtycmb0NZJId8hF42cTo6LRzwZU=.e236fa6a-a522-4ca0-83c4-cd2c1b9fcfd6@github.com> On Mon, 22 Sep 2025 23:37:26 GMT, Chen Liang wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Exclude new test from hotspot_aot_classlinking and hotspot_appcds_dynamic test groups >> - @adinn and @liach comments >> - Merge branch 'master' into 8368174-proactive-init-aot-safe-class-initializer >> - updated javadoc for AOTSafeClassInitializer.java >> - Fix >> - imported > > src/java.base/share/classes/java/lang/Object.java line 1: > >> 1: /* > > Redundant change Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27402#discussion_r2373558204 From dholmes at openjdk.org Tue Sep 23 22:12:15 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 23 Sep 2025 22:12:15 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v2] In-Reply-To: References: <_p9u9mX5mBTeHuKdLY3uATLLs-hrHENJleIpMN2mMko=.6a686db2-314c-4b76-8876-d94558fbbd41@github.com> <25ixE0_d_fp6zlqECkYMelk1PNpwgKAAmBNruu8xabc=.ea63f0ae-667a-4ca9-89de-1c3cd29a3219@github.com> Message-ID: <50_AihuicwyZ9PPDWN7rPk-wJZ3EJp0WwbVLVJIv478=.bd09c212-cb4f-452b-95cd-c178104e2098@github.com> On Tue, 23 Sep 2025 17:58:13 GMT, Alan Bateman wrote: >>> Otherwise how can these fields be considered as "trusted finals"?? >> >> FTR `System.in` et al are not considered as trusted finals. There's a special logic in `ciField::initialize_from()` to disable corresponding optimizations, so the fields aren't treated as constants. > >> I thought the ability to mutate these fields was restricted to the native implementations of setIn et al. and was not allowed via regular reflection? > > Right, core reflection can't modify static finals. JLS 17.5.4 labels System.in/out/err as write-protected fields that can be modified by the setIn/setOut/setErr methods. Historical and unfortunate, and works because these methods were always in JNI. The existence of these methods means the VM can't trust these fields and so has to special case them. @AlanBateman never mind I see now this check feeds up to the JNI code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2373563504 From duke at openjdk.org Tue Sep 23 22:12:17 2025 From: duke at openjdk.org (Ruben) Date: Tue, 23 Sep 2025 22:12:17 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v4] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Fri, 12 Sep 2025 16:36:56 GMT, Ruben wrote: >> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. >> >> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. > > Ruben has updated the pull request incrementally with two additional commits since the last revision: > > - Offset the deoptimization handler entry point > > Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722 > - Revert "Ensure stub code is not adjacent to a call" I'm planning to update the PR soon. The issue on s390 is likely due to the deoptimization blob still adjusting the return address value, which isn't needed anymore. On PPC64, the issue is probably due to the C1-generated deoptimization handler stub code wasn't adjusted. It seems that a call might be at the very end of the main code section, for example, due to an uncommon trap call sequence. Those aren't supposed to return. However, the issue might not reveal itself where post-call NOP sequences are implemented: there would always be the sequence emitted after the call instruction. Where the post-call NOP sequences are implemented, they're emitted as long as "continuations" are enabled. Disabling continuations appears to be an experimental option. Would it be valid to assume that the configurations with disabled continuations have to be supported? As far as I understand, the post-call NOP sequences aren't implemented for s390 and for AArch32. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3325702198 From dholmes at openjdk.org Tue Sep 23 22:46:12 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 23 Sep 2025 22:46:12 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v4] In-Reply-To: References: Message-ID: On Tue, 5 Aug 2025 16:04:08 GMT, Chen Liang wrote: >> Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value). >> >> This is a necessary prerequisite for https://bugs.openjdk.org/browse/JDK-8233268, which proposes enhanced null messages to `Objects::requireNonNull`. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Update NPE per roger review src/hotspot/share/interpreter/bytecodeUtils.cpp line 205: > 203: // A slot is found > 204: FOUND > 205: }; So you define an ENUM to capture the negative cases but then you can use any int >= 0 and pretend it is a member of the enum. ?? Is that typical C++ enum usage? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2373618080 From dholmes at openjdk.org Tue Sep 23 22:54:04 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 23 Sep 2025 22:54:04 GMT Subject: RFR: 8365191: Cleanup after removing LockingMode related code In-Reply-To: References: Message-ID: <4qcEZYuk3_U4nvbEh5EBhAtdJvJxjvvUwWiTlgaTaKk=.91630c2c-57c7-47e9-b4d9-55ea80b0a3f3@github.com> On Tue, 23 Sep 2025 09:29:57 GMT, Fredrik Bredberg wrote: > This is a general cleanup after removing `LockingMode` related code. > It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261). > It includes: > - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking. > - Removing or rewriting comments, arguments or functions that are related to displaced headers. > - Remove "always true" parameter from `MonitorExitStub`. > - Re-type/name metadata in `BasicLock`. > > Tier1-5 passes okay on supported platforms. > > All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu. LGTM2 ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27448#pullrequestreview-3259822820 From liach at openjdk.org Tue Sep 23 23:17:17 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Sep 2025 23:17:17 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v4] In-Reply-To: References: Message-ID: <0oXmVu02mX_lRIUGFSCAoG_u3xXWtZh4Rx0oPfUrWy4=.454eb8c7-038c-4843-bfba-8dced19327d5@github.com> On Tue, 23 Sep 2025 22:43:53 GMT, David Holmes wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Update NPE per roger review > > src/hotspot/share/interpreter/bytecodeUtils.cpp line 205: > >> 203: // A slot is found >> 204: FOUND >> 205: }; > > So you define an ENUM to capture the negative cases but then you can use any int >= 0 and pretend it is a member of the enum. ?? Is that typical C++ enum usage? This was from @jdksjolen's suggestion. I emulated how valhalla's LayoutKind is declared. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26600#discussion_r2373654413 From sspitsyn at openjdk.org Tue Sep 23 23:20:45 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 23 Sep 2025 23:20:45 GMT Subject: RFR: 8368159: Significant performance overhead when started with jdwp agent and unattached debugger [v2] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 21:14:06 GMT, Chris Plummer wrote: >> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1622: >> >>> 1620: >>> 1621: static void invalidate_jvmti_stack(JavaThread* thread) { >>> 1622: if (JvmtiExport::can_post_frame_pop() || thread->is_interp_only_mode()) { >> >> Can you please explain why this change is required? Doesn't 'invalidate_cur_stack_depth' make sense only when interp_only mode is enabled for the threads only? >> It is invalidated once thread switched to interp only. > > It seems odd to me that a method called `invalidate_jvmti_stack()` sometimes doesn't invalidate the stack. Even before this change it was not invalidating unless it was in interp_only mode, which also seems odd. If the cached value is not used for compiled frames, why bother with the interp_only check? > Can you please explain why this change is required? Doesn't 'invalidate_cur_stack_depth' make sense only when interp_only mode is enabled for the threads only? This is a right question to ask, thanks. I agree this confusing. The issue is with the pure continuations which are executed not in a context of a virtual thread. Without this check the following test is stably failed: test/hotspot/jtreg/serviceability/jvmti/vthread/ContStackDepthTest I'm currently kind of puzzled on how to make this check better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27403#discussion_r2373659467 From sspitsyn at openjdk.org Tue Sep 23 23:24:20 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 23 Sep 2025 23:24:20 GMT Subject: RFR: 8368159: Significant performance overhead when started with jdwp agent and unattached debugger [v2] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 23:18:19 GMT, Serguei Spitsyn wrote: >> It seems odd to me that a method called `invalidate_jvmti_stack()` sometimes doesn't invalidate the stack. Even before this change it was not invalidating unless it was in interp_only mode, which also seems odd. If the cached value is not used for compiled frames, why bother with the interp_only check? > >> Can you please explain why this change is required? Doesn't 'invalidate_cur_stack_depth' make sense only when interp_only mode is enabled for the threads only? > > This is a right question to ask, thanks. I agree this confusing. The issue is with the pure continuations which are executed not in a context of a virtual thread. Without this check the following test is stably failed: > > test/hotspot/jtreg/serviceability/jvmti/vthread/ContStackDepthTest > > I'm currently kind of puzzled on how to make this check better. > It seems odd to me that a method called invalidate_jvmti_stack() sometimes doesn't invalidate the stack. Even before this change it was not invalidating unless it was in interp_only mode, which also seems odd. If the cached value is not used for compiled frames, why bother with the interp_only check? I can rename this function to `cond_ invalidate_jvmti_stack()` if you want. The `interp_only` check is needed for optimization to avoid a performance overhead of current stack depth invalidation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27403#discussion_r2373663413 From sspitsyn at openjdk.org Tue Sep 23 23:27:58 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 23 Sep 2025 23:27:58 GMT Subject: RFR: 8368159: Significant performance overhead when started with jdwp agent and unattached debugger [v2] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 23:21:30 GMT, Serguei Spitsyn wrote: >>> Can you please explain why this change is required? Doesn't 'invalidate_cur_stack_depth' make sense only when interp_only mode is enabled for the threads only? >> >> This is a right question to ask, thanks. I agree this confusing. The issue is with the pure continuations which are executed not in a context of a virtual thread. Without this check the following test is stably failed: >> >> test/hotspot/jtreg/serviceability/jvmti/vthread/ContStackDepthTest >> >> I'm currently kind of puzzled on how to make this check better. > >> It seems odd to me that a method called invalidate_jvmti_stack() sometimes doesn't invalidate the stack. Even before this change it was not invalidating unless it was in interp_only mode, which also seems odd. If the cached value is not used for compiled frames, why bother with the interp_only check? > > I can rename this function to `cond_ invalidate_jvmti_stack()` if you want. The `interp_only` check is needed for optimization to avoid a performance overhead of current stack depth invalidation. I was thinking a lot on how to get rid of this current stack depth recalculation mechanism used in `interp_only` mode but have not come with a good approach yet. We have a constant trouble from this mechanism needed for debugger optimization purposes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27403#discussion_r2373667768 From dholmes at openjdk.org Wed Sep 24 01:18:11 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 24 Sep 2025 01:18:11 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v4] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 15:28:02 GMT, Matthias Baesken wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> review feedback > > src/hotspot/os/linux/os_linux.cpp line 4868: > >> 4866: // set name in kernel >> 4867: int rc = prctl(PR_SET_NAME, buf); >> 4868: assert(rc == 0, "prctl(PR_SET_NAME) failed"); > > shouldn't we check also the return code rc in release builds and not only assert ? I don't think so. If this "fails" what could we do? This should not be presented as a failure to the end user. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27395#discussion_r2373809809 From iveresov at openjdk.org Wed Sep 24 01:26:18 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Wed, 24 Sep 2025 01:26:18 GMT Subject: RFR: 8366948: AOT cache creation crashes when iterating training data Message-ID: I forgot a lock around `CTD::_ci_records`. It also has to respect the snapshotting protocol. Testing is good. ------------- Commit messages: - Need a lock around _ci_records access. Respect snapshot flag. Changes: https://git.openjdk.org/jdk/pull/27461/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27461&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366948 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27461/head:pull/27461 PR: https://git.openjdk.org/jdk/pull/27461 From dholmes at openjdk.org Wed Sep 24 01:38:18 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 24 Sep 2025 01:38:18 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v4] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 14:10:47 GMT, Thomas Stuefe wrote: >> On Linux, ASAN only shows some internal thread designation on reports, e.g. `T49`, which is useless. >> >> This patch adds the ability to see the real internal JVM thread names or user-supplied Java thread names in ASAN. This makes it possible to correlate ASAN reports with hs-err file reports (if ASAN is run with `halt_on_error=0` to give us a chance to get an hs-err file) or with a thread dump done beforehand. >> >> Note that it can only show up to 15 characters, though. Therefore, the patch tries to be smart about names that end in digits: such numbers are preserved such that the truncation happens in the middle of the name, e.g.: >> >> `"MyAllocationWorkerThread#4411"` -> `"MyAllocat..4411"` >> >> This latter improvement now also applies to thread names in gdb, since they are subject to the same limitation. >> >> For a detailed analysis of why the old version, using libpthread's `pthread_setname_np`, is not sufficient for thread names in ASAN, please see the issue description. >> >> ----- >> >> Some examples from ASAN report: >> >> Before: >> >> WRITE of size 8 at 0x7b749d2d9190 thread T49 >> >> >> Now: >> >> WRITE of size 8 at 0x7bfc2f0d8380 thread T49 (MyThread#0) >> >> >> >> ==593899==ERROR: AddressSanitizer: attempting free .. in thread T76 (MyAllocati..29) > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > review feedback src/hotspot/os/linux/os_linux.cpp line 4863: > 4861: // for thread names is to be both longer than 15 chars and have a trailing number > 4862: // ("DispatcherWorkerThread21", "C2 CompilerThread#54" etc), we truncate "smartly" > 4863: // by attempting to preserve the trailing number in the name if there is one This "smart" aspect is no longer present right? If the name ends in a number the number will be presented (or at least a few digits) simply because it comes at the end. There will always be cases where the truncation method results in a "worse" name than an alternate truncation method would - hence why I do not think it is worth over engineering this. For example if the name is `ForkJoinPool-5-worker-21` you will lose important information no matter what. src/hotspot/os/linux/os_linux.cpp line 4871: > 4869: if (Linux::_pthread_setname_np) { > 4870: // set name in pthread lib > 4871: rc = Linux::_pthread_setname_np(pthread_self(), buf); This seems redundant given we have to do the `prctl` directly ourselves. src/hotspot/share/utilities/stringUtils.cpp line 153: > 151: const int l = checked_cast(strlen(s)); > 152: // Impose some reasonable length below which we just truncate dumbly (4 chars each for head/tail) > 153: constexpr int smart_truncation_threshold = dots + (4 * 2); I'm really not understanding the "smart-threshold" here; nor does this seem worthy of being a utility function. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27395#discussion_r2373831676 PR Review Comment: https://git.openjdk.org/jdk/pull/27395#discussion_r2373815285 PR Review Comment: https://git.openjdk.org/jdk/pull/27395#discussion_r2373825991 From syan at openjdk.org Wed Sep 24 01:58:04 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 24 Sep 2025 01:58:04 GMT Subject: RFR: 8368367: Test jdk/jfr/event/gc/detailed/TestGCHeapMemoryUsageEvent.java fails jdk.GCHeapMemoryUsage "expected 0 > 0" [v2] In-Reply-To: <2E4HThSyBO6onGz4gXIEekO6Xi-LbLfnsPH5jiVBrgU=.813dfd55-7cb4-4fc2-86f6-f4b9bb6c168a@github.com> References: <2E4HThSyBO6onGz4gXIEekO6Xi-LbLfnsPH5jiVBrgU=.813dfd55-7cb4-4fc2-86f6-f4b9bb6c168a@github.com> Message-ID: On Tue, 23 Sep 2025 14:41:18 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to the TestGCHeapMemoryUsageEvent test that checks whether these kind of events are posted and contain some sensibles values. >> >> In this failure, the `used` metric for the first of two events that is checked was zero. This is because G1, the default collector, updates the `used` value only at certain synchronization points to avoid inconsistencies in other cases. One of these synchronization points is region refill. With the 30gb heap in the test environment, region size is larger than what is allocated during startup, so no region refill/synchronization point has been reached yet, and `used` turns out to be `0`. >> >> This change fixes this by checking the last event instead of the first, it must have happened after that `system.gc()` call in the test, and `used` ought to be larger than zero because of allocations during VM startup. >> >> An alternative could be limiting the test's heap size to something small, that would also help, but I thought this might need additional explanations. >> >> Testing: local runs with G1 heap region size >= 16M or so do not fail any more. >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * fix copyright year This fix works for me ------------- Marked as reviewed by syan (Committer). PR Review: https://git.openjdk.org/jdk/pull/27451#pullrequestreview-3260340468 From dholmes at openjdk.org Wed Sep 24 02:09:45 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 24 Sep 2025 02:09:45 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps [v2] In-Reply-To: <-WkhOYIVIwW6mihulRE5GDoJAXFnZhhpeitDypIFEwU=.b6890075-7165-4b8d-9f62-91dcb861352c@github.com> References: <-WkhOYIVIwW6mihulRE5GDoJAXFnZhhpeitDypIFEwU=.b6890075-7165-4b8d-9f62-91dcb861352c@github.com> Message-ID: On Tue, 23 Sep 2025 10:43:11 GMT, Thomas Stuefe wrote: >> When we run with ASAN enabled and ASAN catches an error, it reports, then stops the JVM. hs-err files and crash dumps at that point would be incredibly useful, though. The ASAN error report itself is seldom enlightening since it only contains native stacks. >> >> This patch makes it possible to get hs-err files and subsequent crash dumps by using the error callback functionality of ASAN. It registers a callback which gets called when ASAN catches an error. We then - carefully - print out the ASAN report to stderr (as ASAN itself would have done) and proceeed to end the JVM with a `fatal()`, which gives us an hs-err file, a callstack at that point including Java frames, and - if enabled - core dumps. >> >> Tested on Fedora 42 and Debian 12, both manually and by running the new companion jtreg test. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Update address.cpp Seems reasonable to me but I am not an ASAN user so ... ------------- PR Review: https://git.openjdk.org/jdk/pull/27446#pullrequestreview-3260354072 From iklam at openjdk.org Wed Sep 24 02:21:07 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 24 Sep 2025 02:21:07 GMT Subject: RFR: 8366948: AOT cache creation crashes when iterating training data In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 01:18:54 GMT, Igor Veresov wrote: > I forgot a lock around `CTD::_ci_records`. It also has to respect the snapshotting protocol. Testing is good. src/hotspot/share/oops/trainingData.hpp line 606: > 604: TrainingDataLocker l; > 605: if (l.can_add()) { > 606: _data.append_if_missing(Record(result, ArgumentsType(args...))); This calls `DepList::append_if_missing()`. Should we add an `TrainingDataLocker::assert_locked()` in that function? I see many functions in this header file have this assert. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27461#discussion_r2373874663 From fyang at openjdk.org Wed Sep 24 02:22:57 2025 From: fyang at openjdk.org (Fei Yang) Date: Wed, 24 Sep 2025 02:22:57 GMT Subject: RFR: 8365191: Cleanup after removing LockingMode related code In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 09:29:57 GMT, Fredrik Bredberg wrote: > This is a general cleanup after removing `LockingMode` related code. > It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261). > It includes: > - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking. > - Removing or rewriting comments, arguments or functions that are related to displaced headers. > - Remove "always true" parameter from `MonitorExitStub`. > - Re-type/name metadata in `BasicLock`. > > Tier1-5 passes okay on supported platforms. > > All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu. @fbredber : Thanks for the ping. Tier1 test passes on linux-riscv64 platform. The RISC-V part of the change seems fine modulo one minor nit. src/hotspot/cpu/riscv/c1_MacroAssembler_riscv.hpp line 71: > 69: // basic_lock: must be x10 & must point to the basic lock, contents destroyed > 70: // temp : temporary register, must not be scratch register t0 or t1 > 71: void unlock_object(Register swap, Register obj, Register lock, Register temp, Label& slow_case); You might want to rename the third param `lock` to `basic_lock`. void unlock_object(Register swap, Register obj, Register basic_lock, Register temp, Label& slow_case); ------------- Marked as reviewed by fyang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27448#pullrequestreview-3260355920 PR Review Comment: https://git.openjdk.org/jdk/pull/27448#discussion_r2373865694 From asmehra at openjdk.org Wed Sep 24 02:35:05 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 24 Sep 2025 02:35:05 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry [v5] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 21:27:40 GMT, Ashutosh Mehra wrote: >> This PR removes the need to store entry point addresses in AdapterHandlerEntry by storing a direct pointer to AdapterBlob instead. Entry point addresses can be computed on the fly from the entry point offsets stored in AdapterBlob. > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Remove incorrectly placed ShouldNotReachHere statements > > Signed-off-by: Ashutosh Mehra I have updated the changes to remove `ShouldNotReachHere()` from the entry point getter methods in `AdapterHandlerEntry`. With that I am able to build ZeroVM and `java -version` works fine too. I started `hotspot_runtime_no_cds` tests with ZeroVM but it wass taking forever to complete on my system. And there were already some failures. Do we know if the jtreg tests pass with ZeroVM? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27101#issuecomment-3326218322 From fyang at openjdk.org Wed Sep 24 02:40:19 2025 From: fyang at openjdk.org (Fei Yang) Date: Wed, 24 Sep 2025 02:40:19 GMT Subject: RFR: 8368366: RISC-V: AlignVector is mistakenly set to AvoidUnalignedAccesses In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 10:39:51 GMT, Robbin Ehn wrote: > Yes, thanks, I think you are on the right track. Thanks for confirming that. > But an additional thing: if user sets "-XX:-UseUnalignedAccesses" I think that should be enought to stop all of them all. Also I'm doubt ful of the usefulness of Avoid flag. I don't see any case where I would have Avoid = false but also UseUnAl= false. Right now I always use Avoid = !UseUnal. And I use it the same way as you do. `AvoidUnalignedAccesses` is derived from the aarch64 counterpart. I guess maybe it's time to let it go. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27445#issuecomment-3326225572 From fyang at openjdk.org Wed Sep 24 03:20:18 2025 From: fyang at openjdk.org (Fei Yang) Date: Wed, 24 Sep 2025 03:20:18 GMT Subject: RFR: 8368366: RISC-V: AlignVector is mistakenly set to AvoidUnalignedAccesses In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 07:21:47 GMT, Fei Yang wrote: > Hi, please consider this small change fixing setting of `AlignVector` flag on RISC-V. > > According to the latest RISC-V linux hardware probing syscall [1], the performance of misaligned memory accesses > has been divided into two cases: `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` and `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` > for scalar and vector respectively. And `RISCV_HWPROBE_KEY_CPUPERF_0` is now deprecated and it returns similar values > to `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`. > > Previously, we use `RISCV_HWPROBE_KEY_CPUPERF_0` to detect support for misaligned memory accesses and reflect the result > on these VM flags: `AvoidUnalignedAccesses`, `UseUnalignedAccesses` and `AlignVector`. But it doesn't seem correct to update > `AlignVector` according to this value. And this is causing issues on RISC-V hardwares which have fast misaligned accesses only > for the scalar case. I witnessed SIGBUG error on these hardwares when doing vector misaligned accesses. > > So we should align AlignVector with `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` instead. This patch just reverts the previous > setting of AlignVector and just let it have the default value which is true. I will try to add detection in a separate PR > for `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` and update `AlignVector` accordingly. > > [1] https://docs.kernel.org/arch/riscv/hwprobe.html FYI: My local `hotspot_vector_1 hotspot_vector_2 jdk_vector jdk_vector_sanity compiler/vectorization compiler/vectorapi` test result with fastdebug build is clean. And I used qemu-system running kernel 6.14. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27445#issuecomment-3326288843 From jbhateja at openjdk.org Wed Sep 24 03:35:03 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 24 Sep 2025 03:35:03 GMT Subject: RFR: 8367611: Enable vblendvp[sd] on Future ECore [v3] In-Reply-To: <10RF-SXtaEmCYwrS2YMXW-rWB8Iwz6HbNlQmNyWCfG8=.ed216967-9ade-44d9-8ece-db1ae9359a5e@github.com> References: <_Jk5fv1iO9ZPZyOtUAXeUez481RibKJR4FsUT_BnKm8=.2f68f9ee-9ce2-4dbb-be8b-1b9f910ba0e0@github.com> <10RF-SXtaEmCYwrS2YMXW-rWB8Iwz6HbNlQmNyWCfG8=.ed216967-9ade-44d9-8ece-db1ae9359a5e@github.com> Message-ID: On Tue, 23 Sep 2025 19:08:53 GMT, Mohamed Issa wrote: > > Hi @missa-prime , VBLENDVPS was always supported by AVX2 targets. We enabled its software emulation for performance reasons, as these needs microcode assistance on AVX2 targets. > > image > > It seems your PR is lifting this limitation for Darkmont under a constraint on dst and src1 register equivalence? > > Please add appropriate comments in code and documentary reference to the relevant section of the Intel Architectural Set Extension Manual. > > Currently, there is no public documentation mentioning the (dst == src1) register optimization on Darkmont. Once it's available, I'll add comments and reference it. Thanks @missa-prime , this is another use case apart from NDD demotion where [register biasing](https://github.com/openjdk/jdk/pull/26283) may be useful to trigger this micro-architectural optimization. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27354#issuecomment-3326322929 From kvn at openjdk.org Wed Sep 24 03:59:15 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 24 Sep 2025 03:59:15 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry [v5] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 21:27:40 GMT, Ashutosh Mehra wrote: >> This PR removes the need to store entry point addresses in AdapterHandlerEntry by storing a direct pointer to AdapterBlob instead. Entry point addresses can be computed on the fly from the entry point offsets stored in AdapterBlob. > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Remove incorrectly placed ShouldNotReachHere statements > > Signed-off-by: Ashutosh Mehra Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27101#pullrequestreview-3260747846 From kvn at openjdk.org Wed Sep 24 03:59:17 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 24 Sep 2025 03:59:17 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry [v5] In-Reply-To: References: Message-ID: <-MMKctCSqA3H4m8zYwDb4cy13XpUrCDuItOmC8KKHY8=.5b3c3e98-5d6e-4169-b92b-24be9a63f3ba@github.com> On Wed, 24 Sep 2025 02:32:29 GMT, Ashutosh Mehra wrote: >> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove incorrectly placed ShouldNotReachHere statements >> >> Signed-off-by: Ashutosh Mehra > > I have updated the changes to remove `ShouldNotReachHere()` from the entry point getter methods in `AdapterHandlerEntry`. With that I am able to build ZeroVM and `java -version` works fine too. > I started `hotspot_runtime_no_cds` tests with ZeroVM but it wass taking forever to complete on my system. And there were already some failures. Do we know if the jtreg tests pass with ZeroVM? @ashu-mehra don't worry Zero Vm passing jtreg testing. We only need to pass the build. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27101#issuecomment-3326364071 From cjplummer at openjdk.org Wed Sep 24 05:04:14 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 24 Sep 2025 05:04:14 GMT Subject: RFR: 8368159: Significant performance overhead when started with jdwp agent and unattached debugger [v2] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 23:25:19 GMT, Serguei Spitsyn wrote: >>> It seems odd to me that a method called invalidate_jvmti_stack() sometimes doesn't invalidate the stack. Even before this change it was not invalidating unless it was in interp_only mode, which also seems odd. If the cached value is not used for compiled frames, why bother with the interp_only check? >> >> I can rename this function to `cond_ invalidate_jvmti_stack()` if you want. The `interp_only` check is needed for optimization to avoid a performance overhead of current stack depth invalidation. > > I was thinking a lot on how to get rid of this current stack depth recalculation mechanism used in `interp_only` mode but have not come with a good approach yet. We have a constant trouble from this mechanism needed for debugger optimization purposes. > The interp_only check is needed for optimization to avoid a performance overhead of current stack depth invalidation. But if we are not in interp_only mode isn't it already invalidated? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27403#discussion_r2374345062 From stuefe at openjdk.org Wed Sep 24 05:31:14 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 24 Sep 2025 05:31:14 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v4] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 01:14:59 GMT, David Holmes wrote: >> src/hotspot/os/linux/os_linux.cpp line 4868: >> >>> 4866: // set name in kernel >>> 4867: int rc = prctl(PR_SET_NAME, buf); >>> 4868: assert(rc == 0, "prctl(PR_SET_NAME) failed"); >> >> shouldn't we check also the return code rc in release builds and not only assert ? > > I don't think so. If this "fails" what could we do? This should not be presented as a failure to the end user. The assert on pthread_setname was there for ages and never fired. The asserts are there to tell us, in our test landscapes, whether this ever fails. If it does, we can look for the reasons and possibly remove the assert. In release builds the error should be ignored, since the user cannot do anything about it and the consequences don't matter that much. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27395#discussion_r2374448251 From kbarrett at openjdk.org Wed Sep 24 05:39:37 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 24 Sep 2025 05:39:37 GMT Subject: RFR: 8367013: Add Atomic to package/replace idiom of volatile var plus AtomicAccess:: operations Message-ID: Please review this change that adds the type `Atomic`, to use as the type of a variable that is accessed (including writes) concurrently by multiple threads. This is intended to replace (most) uses of the current HotSpot idiom of declaring a variable `volatile` and accessing that variable using functions from the AtomicAccess class. https://github.com/openjdk/jdk/blame/528f93f8cb9f1fb9c19f31ab80c8a546f47beed2/doc/hotspot-style.md#L138-L147 Testing: mach5 tier1-6, GHA sanity tests ------------- Commit messages: - work around clang private access bug - update FreeListAllocator - update nonblockingQueue - update LockFreeStack - convert StringDedupTable - convert SingleWriterSynchronizer - test_atomic - Atomic - add DependentAlwaysFalse Changes: https://git.openjdk.org/jdk/pull/27462/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27462&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367013 Stats: 1451 lines in 13 files changed: 1313 ins; 0 del; 138 mod Patch: https://git.openjdk.org/jdk/pull/27462.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27462/head:pull/27462 PR: https://git.openjdk.org/jdk/pull/27462 From kbarrett at openjdk.org Wed Sep 24 05:39:37 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 24 Sep 2025 05:39:37 GMT Subject: RFR: 8367013: Add Atomic to package/replace idiom of volatile var plus AtomicAccess:: operations In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 05:32:38 GMT, Kim Barrett wrote: > Please review this change that adds the type `Atomic`, to use as the type > of a variable that is accessed (including writes) concurrently by multiple > threads. This is intended to replace (most) uses of the current HotSpot idiom > of declaring a variable `volatile` and accessing that variable using functions > from the AtomicAccess class. > https://github.com/openjdk/jdk/blame/528f93f8cb9f1fb9c19f31ab80c8a546f47beed2/doc/hotspot-style.md#L138-L147 > > Testing: mach5 tier1-6, GHA sanity tests The implementation of `Atomic` leans heavily on `AtomicAccess`. But note that some of the `Atomic` function names differ from the corresponding `AtomicAccess` function names. Without the `AtomicAccess::` prefix, the names from that class are in some cases subtle and easy to overlook, which is not a benefit when dealing with the complexities of lock-free code. This PR includes gtests for the new type. These gtests only test functional behavior, not concurrent access behavior. This PR also includes conversions for a few uses. This provides examples of what the new code will look like. It also provides some additional testing for this change. The plan is that other uses of the `volatile` + `AtomicAccess` idiom will be converted incrementally. It is expected that there will be some remaining direct uses of `AtomicAccess`, in places where conversion to `Atomic` isn't appropriate. An example is the `BitMap::par_xxx` suite of functions. This PR contains a sequence of commits, each covering different aspects of the change. It might help to focus on particular commits when reviewing. The HotSpot Style Guide needs to be updated for JDK-8367014 and for this change. That will be done in a followup. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27462#issuecomment-3326608037 From stuefe at openjdk.org Wed Sep 24 05:40:16 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 24 Sep 2025 05:40:16 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v4] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 01:20:14 GMT, David Holmes wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> review feedback > > src/hotspot/os/linux/os_linux.cpp line 4871: > >> 4869: if (Linux::_pthread_setname_np) { >> 4870: // set name in pthread lib >> 4871: rc = Linux::_pthread_setname_np(pthread_self(), buf); > > This seems redundant given we have to do the `prctl` directly ourselves. `pthread_setname_np` does more than `prctl`, though. It also populates the task name entry in /proc. See `ls /proc//task/comm | xargs cat` . We could do this ourselves, too, admittedly. That could get rid of the dlsym for the _pthread_setname, but goes a bit beyond the scope of this PR. And if glibc ever adds anything to `pthread_setname_np`, we will miss out. What do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27395#discussion_r2374464443 From stuefe at openjdk.org Wed Sep 24 05:48:16 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 24 Sep 2025 05:48:16 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v4] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 01:34:50 GMT, David Holmes wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> review feedback > > src/hotspot/os/linux/os_linux.cpp line 4863: > >> 4861: // for thread names is to be both longer than 15 chars and have a trailing number >> 4862: // ("DispatcherWorkerThread21", "C2 CompilerThread#54" etc), we truncate "smartly" >> 4863: // by attempting to preserve the trailing number in the name if there is one > > This "smart" aspect is no longer present right? If the name ends in a number the number will be presented (or at least a few digits) simply because it comes at the end. > > There will always be cases where the truncation method results in a "worse" name than an alternate truncation method would - hence why I do not think it is worth over engineering this. For example if the name is `ForkJoinPool-5-worker-21` you will lose important information no matter what. This series of ASAN issues came from a real customer case we are working on, and in that one having the trailing number preserved was really useful. And certainly, something like "C2 Com..hread4" is more useful than "C2 CompilerThre"? > src/hotspot/share/utilities/stringUtils.cpp line 153: > >> 151: const int l = checked_cast(strlen(s)); >> 152: // Impose some reasonable length below which we just truncate dumbly (4 chars each for head/tail) >> 153: constexpr int smart_truncation_threshold = dots + (4 * 2); > > I'm really not understanding the "smart-threshold" here; nor does this seem worthy of being a utility function. The smart-threshold is just a threshold to switch to plain truncation. E.g. if the output buffer were just four characters, the resulting name would be "C..3". I disagree about making this a utility function. A function like this makes sense in a number of cases. It certainly is preferable to dumb truncation without any indication one truncated. Arguably, with longer output buffers something like "...(truncate)..." in the middle would be even more helpful. And having it a separate function allows me to test the function in gtest. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27395#discussion_r2374478129 PR Review Comment: https://git.openjdk.org/jdk/pull/27395#discussion_r2374473914 From amitkumar at openjdk.org Wed Sep 24 06:22:16 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 24 Sep 2025 06:22:16 GMT Subject: RFR: 8365191: Cleanup after removing LockingMode related code In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 09:29:57 GMT, Fredrik Bredberg wrote: > This is a general cleanup after removing `LockingMode` related code. > It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261). > It includes: > - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking. > - Removing or rewriting comments, arguments or functions that are related to displaced headers. > - Remove "always true" parameter from `MonitorExitStub`. > - Re-type/name metadata in `BasicLock`. > > Tier1-5 passes okay on supported platforms. > > All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu. s390x Part looks good. tier1 tests with fastdebug and release vm seems stable as well. ------------- Marked as reviewed by amitkumar (Committer). PR Review: https://git.openjdk.org/jdk/pull/27448#pullrequestreview-3261185513 From aboldtch at openjdk.org Wed Sep 24 06:31:26 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 24 Sep 2025 06:31:26 GMT Subject: RFR: 8367972: ZGC: Reduce ZBarrierSet includes In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 09:49:03 GMT, Axel Boldt-Christmas wrote: > [JDK-8365053](https://bugs.openjdk.org/browse/JDK-8365053) made a fact which is already well known to ZGC developers clear. We pull in large parts of the ZGC implementation through the access API, via `zbarrierset.inline.hpp`. > > ZGC developers are well aware as touching most `.hpp` or `inline.hpp` files in `gc/z` requires rebuilding most of hotspot in incremental builds. > > I propose we create a boundary between the barrier set and the implementation. The main reason being making incremental builds less painful. > > I experimented with this last year, at the time I saw no real difference in full build times, nor any performance regressions from not inlining the barrier implementation into the access API. > > Will reevaluate the performance implications. > > I ran the `bin/update_pch.sh` script, but with the default `MIN_MS` I saw the same list both before and after this change: > ```c++ > #include "gc/g1/g1BarrierSet.inline.hpp" > #include "gc/shenandoah/shenandoahHeap.inline.hpp" > #include "memory/iterator.inline.hpp" > #include "oops/access.hpp" > #include "oops/access.inline.hpp" > #include "oops/oop.inline.hpp" > #include "utilities/globalDefinitions.hpp" > > However when running with `MIN_MS` reduced by an order of magnitude `#include "gc/z/zBarrier.inline.hpp"` was included without this patch, and was excluded after with this patch. > > Also cross-compiled ppc64le, s390x and riscv64 (fast debug). Could not find any missing includes, have not built all configurations. > > For some reason windows slow debug failed to build because `test/hotspot/gtest/runtime/test_os_windows.cpp` was missing `os_windows.hpp`, did not investigate further, but included `runtime/os.inline.hpp` in the test as it includes all OS and OS CPU specific declarations and inline definitions. > > * Testing > * Tier 1 + ZGC tier 1-5 on Oracle supported platforms Thanks for the reviews. Initial performance testing showed nothing interesting. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27386#issuecomment-3326728377 From aboldtch at openjdk.org Wed Sep 24 06:31:27 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 24 Sep 2025 06:31:27 GMT Subject: Integrated: 8367972: ZGC: Reduce ZBarrierSet includes In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 09:49:03 GMT, Axel Boldt-Christmas wrote: > [JDK-8365053](https://bugs.openjdk.org/browse/JDK-8365053) made a fact which is already well known to ZGC developers clear. We pull in large parts of the ZGC implementation through the access API, via `zbarrierset.inline.hpp`. > > ZGC developers are well aware as touching most `.hpp` or `inline.hpp` files in `gc/z` requires rebuilding most of hotspot in incremental builds. > > I propose we create a boundary between the barrier set and the implementation. The main reason being making incremental builds less painful. > > I experimented with this last year, at the time I saw no real difference in full build times, nor any performance regressions from not inlining the barrier implementation into the access API. > > Will reevaluate the performance implications. > > I ran the `bin/update_pch.sh` script, but with the default `MIN_MS` I saw the same list both before and after this change: > ```c++ > #include "gc/g1/g1BarrierSet.inline.hpp" > #include "gc/shenandoah/shenandoahHeap.inline.hpp" > #include "memory/iterator.inline.hpp" > #include "oops/access.hpp" > #include "oops/access.inline.hpp" > #include "oops/oop.inline.hpp" > #include "utilities/globalDefinitions.hpp" > > However when running with `MIN_MS` reduced by an order of magnitude `#include "gc/z/zBarrier.inline.hpp"` was included without this patch, and was excluded after with this patch. > > Also cross-compiled ppc64le, s390x and riscv64 (fast debug). Could not find any missing includes, have not built all configurations. > > For some reason windows slow debug failed to build because `test/hotspot/gtest/runtime/test_os_windows.cpp` was missing `os_windows.hpp`, did not investigate further, but included `runtime/os.inline.hpp` in the test as it includes all OS and OS CPU specific declarations and inline definitions. > > * Testing > * Tier 1 + ZGC tier 1-5 on Oracle supported platforms This pull request has now been integrated. Changeset: 30368668 Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/303686684c23db465ccfb6a9b4861a673bfa5f4b Stats: 187 lines in 10 files changed: 114 ins; 50 del; 23 mod 8367972: ZGC: Reduce ZBarrierSet includes Reviewed-by: stefank, eosterlund ------------- PR: https://git.openjdk.org/jdk/pull/27386 From dholmes at openjdk.org Wed Sep 24 06:53:18 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 24 Sep 2025 06:53:18 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v4] In-Reply-To: References: Message-ID: <_F71G07Usq_ZOM_h_zRIinqdztuAZOOqy5jf_vX1qkY=.79c87d91-914e-4f2f-85d6-9b7f0aec4345@github.com> On Wed, 24 Sep 2025 05:45:42 GMT, Thomas Stuefe wrote: >> src/hotspot/os/linux/os_linux.cpp line 4863: >> >>> 4861: // for thread names is to be both longer than 15 chars and have a trailing number >>> 4862: // ("DispatcherWorkerThread21", "C2 CompilerThread#54" etc), we truncate "smartly" >>> 4863: // by attempting to preserve the trailing number in the name if there is one >> >> This "smart" aspect is no longer present right? If the name ends in a number the number will be presented (or at least a few digits) simply because it comes at the end. >> >> There will always be cases where the truncation method results in a "worse" name than an alternate truncation method would - hence why I do not think it is worth over engineering this. For example if the name is `ForkJoinPool-5-worker-21` you will lose important information no matter what. > > This series of ASAN issues came from a real customer case we are working on, and in that one having the trailing number preserved was really useful. And certainly, something like "C2 Com..hread4" is more useful than "C2 CompilerThre"? But in terms of the comment, you are not actually doing anything special if there happens to be a number at the end of the name. >> src/hotspot/os/linux/os_linux.cpp line 4871: >> >>> 4869: if (Linux::_pthread_setname_np) { >>> 4870: // set name in pthread lib >>> 4871: rc = Linux::_pthread_setname_np(pthread_self(), buf); >> >> This seems redundant given we have to do the `prctl` directly ourselves. > > `pthread_setname_np` does more than `prctl`, though. It also populates the task name entry in /proc. See `ls /proc//task/comm | xargs cat` . > > We could do this ourselves, too, admittedly. That could get rid of the dlsym for the _pthread_setname, but goes a bit beyond the scope of this PR. And if glibc ever adds anything to `pthread_setname_np`, we will miss out. What do you think? We only ever call setname on the current thread so we never reach the part that would populate /proc: if (pd == THREAD_SELF) return __prctl (PR_SET_NAME, name) ? errno : 0; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27395#discussion_r2374627069 PR Review Comment: https://git.openjdk.org/jdk/pull/27395#discussion_r2374632340 From dholmes at openjdk.org Wed Sep 24 06:56:16 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 24 Sep 2025 06:56:16 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v4] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 05:43:09 GMT, Thomas Stuefe wrote: >> src/hotspot/share/utilities/stringUtils.cpp line 153: >> >>> 151: const int l = checked_cast(strlen(s)); >>> 152: // Impose some reasonable length below which we just truncate dumbly (4 chars each for head/tail) >>> 153: constexpr int smart_truncation_threshold = dots + (4 * 2); >> >> I'm really not understanding the "smart-threshold" here; nor does this seem worthy of being a utility function. > > The smart-threshold is just a threshold to switch to plain truncation. E.g. if the output buffer were just four characters, the resulting name would be "C..3". > > I disagree about making this a utility function. A function like this makes sense in a number of cases. It certainly is preferable to dumb truncation without any indication one truncated. Arguably, with longer output buffers something like "...(truncate)..." in the middle would be even more helpful. > > And having it a separate function allows me to test the function in gtest. Sorry I'm still not grokking this 4 chars aspect. For whatever buffer size, if the length of the name < buffer_len we write it as-is. Otherwise we chop out the middle and replace with .. such that it fits in the buffer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27395#discussion_r2374639723 From mbaesken at openjdk.org Wed Sep 24 07:43:14 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 24 Sep 2025 07:43:14 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v4] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 05:28:53 GMT, Thomas Stuefe wrote: >> I don't think so. If this "fails" what could we do? This should not be presented as a failure to the end user. > > The assert on pthread_setname was there for ages and never fired. The asserts are there to tell us, in our test landscapes, whether this ever fails. If it does, we can look for the reasons and possibly remove the assert. > > In release builds the error should be ignored, since the user cannot do anything about it and the consequences don't matter that much. okay fine then let's just do the assert if there is not much we could do otherwise in product builds. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27395#discussion_r2374785295 From mbaesken at openjdk.org Wed Sep 24 07:43:15 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 24 Sep 2025 07:43:15 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v4] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 06:53:24 GMT, David Holmes wrote: >> The smart-threshold is just a threshold to switch to plain truncation. E.g. if the output buffer were just four characters, the resulting name would be "C..3". >> >> I disagree about making this a utility function. A function like this makes sense in a number of cases. It certainly is preferable to dumb truncation without any indication one truncated. Arguably, with longer output buffers something like "...(truncate)..." in the middle would be even more helpful. >> >> And having it a separate function allows me to test the function in gtest. > > Sorry I'm still not grokking this 4 chars aspect. For whatever buffer size, if the length of the name < buffer_len we write it as-is. Otherwise we chop out the middle and replace with .. such that it fits in the buffer. > I'm really not understanding the "smart-threshold" here; nor does this seem worthy of being a utility function. I think it is a good string utility function; at least it is not only related only to the ASAN support but could be used for other things. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27395#discussion_r2374781681 From mdoerr at openjdk.org Wed Sep 24 07:58:26 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 24 Sep 2025 07:58:26 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v4] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Fri, 12 Sep 2025 16:36:56 GMT, Ruben wrote: >> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. >> >> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. > > Ruben has updated the pull request incrementally with two additional commits since the last revision: > > - Offset the deoptimization handler entry point > > Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722 > - Revert "Ensure stub code is not adjacent to a call" Thanks for pointing me to the uncommon trap sequence. Right, the post_call NOPs make the previous implementation (unmodified deop handlers) reliable on all platforms except arm32 and s390 which don't have them, yet. So, an easier fix would be to implement them for the CallRuntimeDirect nodes for these 2 platforms and adding comments to all platforms explaining that they are strictly needed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3327079541 From aph at openjdk.org Wed Sep 24 08:19:59 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 24 Sep 2025 08:19:59 GMT Subject: RFR: 8367013: Add Atomic to package/replace idiom of volatile var plus AtomicAccess:: operations In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 05:32:38 GMT, Kim Barrett wrote: > Please review this change that adds the type `Atomic`, to use as the type > of a variable that is accessed (including writes) concurrently by multiple > threads. This is intended to replace (most) uses of the current HotSpot idiom > of declaring a variable `volatile` and accessing that variable using functions > from the AtomicAccess class. > https://github.com/openjdk/jdk/blame/528f93f8cb9f1fb9c19f31ab80c8a546f47beed2/doc/hotspot-style.md#L138-L147 > > Testing: mach5 tier1-6, GHA sanity tests src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp line 424: > 422: StringDedup::Table::CleanupState* StringDedup::Table::_cleanup_state = nullptr; > 423: bool StringDedup::Table::_need_bucket_shrinking = false; > 424: Atomic StringDedup::Table::_dead_count{}; Suggestion: Atomic StringDedup::Table::_dead_count; This is not a function, is it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27462#discussion_r2374909050 From aph at openjdk.org Wed Sep 24 08:39:57 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 24 Sep 2025 08:39:57 GMT Subject: RFR: 8368303: AlwaysAtomicAccesses is excessively strict In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 12:04:47 GMT, Albert Mingkun Yang wrote: > I get the feeling that this "optimization" (using plain store/move for smaller types) should be done at a lower level/later stage, i.e. in respective backend. That's not possible because this behaviour is being done in shared code, and cannot be overridden by the back ends. The logic in this PR is sound, I believe: if accesses on this target are multi-copy atomic, then all accesses of a word size or less are single-copy atomic. How could it not be so? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27432#issuecomment-3327226522 From mdoerr at openjdk.org Wed Sep 24 08:47:10 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 24 Sep 2025 08:47:10 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v4] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Fri, 12 Sep 2025 16:36:56 GMT, Ruben wrote: >> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. >> >> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. > > Ruben has updated the pull request incrementally with two additional commits since the last revision: > > - Offset the deoptimization handler entry point > > Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722 > - Revert "Ensure stub code is not adjacent to a call" Oh, right, it is still possible to switch VMContinuations off. I guess we want to keep this option for debugging purposes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3327250323 From mli at openjdk.org Wed Sep 24 09:01:51 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 24 Sep 2025 09:01:51 GMT Subject: RFR: 8368366: RISC-V: AlignVector is mistakenly set to AvoidUnalignedAccesses In-Reply-To: References: Message-ID: <1MCDY97dkzexkoVtCy4hektxTRwsmYoGi_2qiHCxH-g=.5c583ce9-5556-450e-8c63-cdae50895eb1@github.com> On Tue, 23 Sep 2025 07:21:47 GMT, Fei Yang wrote: > Hi, please consider this small change fixing setting of `AlignVector` flag on RISC-V. > > According to the latest RISC-V linux hardware probing syscall [1], the performance of misaligned memory accesses > has been divided into two cases: `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` and `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` > for scalar and vector respectively. And `RISCV_HWPROBE_KEY_CPUPERF_0` is now deprecated and it returns similar values > to `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`. > > Previously, we use `RISCV_HWPROBE_KEY_CPUPERF_0` to detect support for misaligned memory accesses and reflect the result > on these VM flags: `AvoidUnalignedAccesses`, `UseUnalignedAccesses` and `AlignVector`. But it doesn't seem correct to update > `AlignVector` according to this value. And this is causing issues on RISC-V hardwares which have fast misaligned accesses only > for the scalar case. I witnessed SIGBUG error on these hardwares when doing vector misaligned accesses. > > So we should align AlignVector with `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` instead. This patch just reverts the previous > setting of AlignVector and just let it have the default value which is true. I will try to add detection in a separate PR > for `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` and update `AlignVector` accordingly. > > [1] https://docs.kernel.org/arch/riscv/hwprobe.html Looks good. Thanks. ------------- Marked as reviewed by mli (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27445#pullrequestreview-3261901107 From ayang at openjdk.org Wed Sep 24 09:03:56 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 24 Sep 2025 09:03:56 GMT Subject: RFR: 8368303: AlwaysAtomicAccesses is excessively strict In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 08:37:28 GMT, Andrew Haley wrote: > That's not possible because this behaviour is being done in shared code, and cannot be overridden by the back ends. In `c1_LIRGenerator_x86.cpp`: void LIRGenerator::volatile_field_store(LIR_Opr value, LIR_Address* address, CodeEmitInfo* info) { if (address->type() == T_LONG) { ... } else { __ store(value, address, info); } } I thought the `else` branch is implementing the "optimization" -- using plain store/move for smaller types. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27432#issuecomment-3327312085 From stuefe at openjdk.org Wed Sep 24 09:07:02 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 24 Sep 2025 09:07:02 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v4] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 07:39:46 GMT, Matthias Baesken wrote: >> Sorry I'm still not grokking this 4 chars aspect. For whatever buffer size, if the length of the name < buffer_len we write it as-is. Otherwise we chop out the middle and replace with .. such that it fits in the buffer. > >> I'm really not understanding the "smart-threshold" here; nor does this seem worthy of being a utility function. > > I think it is a good string utility function; at least it is not only related only to the ASAN support but could be used for other things. > Sorry I'm still not grokking this 4 chars aspect. For whatever buffer size, if the length of the name < buffer_len we write it as-is. Otherwise we chop out the middle and replace with .. such that it fits in the buffer. Okay, I can remove that part. The output buffer has to have at least the length of the two dots then. Passing in a buffer of 2 would result in "..". Or possible "C." The more I think about this, the more absurd this detail becomes. Thing is, the output buffer size is usually set statically and under the control of the hotspot developer (it will be usually the size of a char buffer). So we could probably just assert a minimum output buffer size. Yes, I like this more. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27395#discussion_r2375106716 From mdoerr at openjdk.org Wed Sep 24 09:16:35 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 24 Sep 2025 09:16:35 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v4] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Fri, 12 Sep 2025 16:36:56 GMT, Ruben wrote: >> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. >> >> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. > > Ruben has updated the pull request incrementally with two additional commits since the last revision: > > - Offset the deoptimization handler entry point > > Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722 > - Revert "Ensure stub code is not adjacent to a call" Right, it works after adapting C1 deopt handler (see below). So, you convinced me that your new solution is better. Please don't add Copyright headers everywhere. Arm has contributed less than 1% of ppc.ad. I don't think that justifies a Copyright for the whole file. We don't want everyone's Copyright in every file. Thanks a lot for debugging the issue! diff --git a/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp b/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp index 3ca75305eca..fe735c8831b 100644 --- a/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp +++ b/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp @@ -263,13 +263,17 @@ int LIR_Assembler::emit_deopt_handler() { return -1; } - int offset = code_offset(); + Label start; + + __ bind(start); __ bl64_patchable(SharedRuntime::deopt_blob()->unpack(), relocInfo::runtime_call_type); + int entry_point = __ offset(); + __ b(start); - guarantee(code_offset() - offset <= deopt_handler_size(), "overflow"); + guarantee(code_offset() - entry_point <= deopt_handler_size(), "overflow"); __ end_a_stub(); - return offset; + return entry_point; } diff --git a/src/hotspot/cpu/ppc/ppc.ad b/src/hotspot/cpu/ppc/ppc.ad index 1f6819c4bf6..9473dd3d57b 100644 --- a/src/hotspot/cpu/ppc/ppc.ad +++ b/src/hotspot/cpu/ppc/ppc.ad @@ -1,7 +1,6 @@ // // Copyright (c) 2011, 2025, Oracle and/or its affiliates. All rights reserved. // Copyright (c) 2012, 2025 SAP SE. All rights reserved. -// Copyright 2025 Arm Limited and/or its affiliates. // DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. // // This code is free software; you can redistribute it and/or modify it diff --git a/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp b/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp index ced1b38541b..3d037540766 100644 --- a/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp +++ b/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp @@ -2965,7 +2965,6 @@ void SharedRuntime::generate_deopt_blob() { // The return_pc has been stored in the frame of the deoptee and // will replace the address of the deopt_handler in the call // to Deoptimization::fetch_unroll_info below. - const int return_pc_adjustment_no_exception = -MacroAssembler::bl64_patchable_size; // Push the "unpack frame" // Save everything in sight. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3327362075 From mli at openjdk.org Wed Sep 24 10:51:50 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 24 Sep 2025 10:51:50 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v6] In-Reply-To: References: Message-ID: > Hi, > Can you help to review this patch? > > Currently, the cpu features of riscv are stored in separate RVFeature subclasses. > But to support the store/restore CPU features for aot in the future, we need to store the cpu features in a continuous memory. > As the riscv extensions are introduced continuously, I think it's better to do it via an simple bitmap at the beginning. > Currently, just suppose the non-extension features will not be stored in aot image, so I also split the extension and non-extenion features. When we implement the related aot feature in the short future, we can revisit the way of splitting the features. Currently, just change the storage way of cpu features, lay the foundation for future aot. > > Thanks Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: refine ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27152/files - new: https://git.openjdk.org/jdk/pull/27152/files/eac955a1..414f1463 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27152&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27152&range=04-05 Stats: 10 lines in 1 file changed: 1 ins; 4 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27152.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27152/head:pull/27152 PR: https://git.openjdk.org/jdk/pull/27152 From mli at openjdk.org Wed Sep 24 10:51:52 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 24 Sep 2025 10:51:52 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v4] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 07:12:25 GMT, Fei Yang wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> fix typo > > src/hotspot/cpu/riscv/vm_version_riscv.hpp line 305: > >> 303: >> 304: static uint64_t bit_mask(RVFeatureIndex feature) { >> 305: return (1ULL << (feature & features_bitmap_element_mask())); > > The two functions `features_bitmap_element_mask` and `bit_mask` look very confusing to me. Is it better to factor out `features_bitmap_element_mask` and rename this `bit_mask` into something like `features_bitmap_element_bit_mask`? I misunderstood this, thought it's the similar suggestion as the below one. Will make it more readable here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2375356196 From mli at openjdk.org Wed Sep 24 10:55:58 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 24 Sep 2025 10:55:58 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v5] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 11:19:01 GMT, Hamlin Li wrote: >> src/hotspot/cpu/riscv/vm_version_riscv.hpp line 275: >> >>> 273: public: >>> 274: enum RVFeatureIndex { >>> 275: #define DECLARE_RV_FEATURE_ENUM(NAME, PRETTY, LINUX_BIT, CPU_FEATURE_INDEX, FSTRING, FLAGF) CPU_##NAME=(CPU_FEATURE_INDEX), >> >> Instead of explicitly setting the feature index, can't we use the implicit numbering of the enum and remove the `cpu feature index` from `RV_EXT_FEATURE_FLAGS` entirely? The only other use I can see of `CPU_FEATURE_INDEX` is at https://github.com/openjdk/jdk/pull/27152/files#diff-7b173d6e5834de13749c8333192fef5a874628a67b90a5d8d06235d507542ac4R39 and I wonder if we can't use the enum `CPU_#NAME` there directy. > > Yes, it'll be good if we can just remove the explicit numbering of the enum, but seems there is no good way to pass in the enum value to the constructor of `NAME##RVExtFeatureValue` in `DEF_RV_EXT_FEATURE`. We could do it with an static member of RVExtFeatureValue, increment it in RVExtFeatureValue constructor, but seems it's not straight and clear. > So my preference is to keep the explicit enum value in `RV_EXT_FEATURE_FLAGS`. > How do you think about it? We also need this feature index when construct a `NAME##RVExtFeatureValue` instance in vm_version_riscv.cpp ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2375373809 From yzheng at openjdk.org Wed Sep 24 11:16:52 2025 From: yzheng at openjdk.org (Yudi Zheng) Date: Wed, 24 Sep 2025 11:16:52 GMT Subject: RFR: 8365191: Cleanup after removing LockingMode related code In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 17:30:05 GMT, Coleen Phillimore wrote: >> This is a general cleanup after removing `LockingMode` related code. >> It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261). >> It includes: >> - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking. >> - Removing or rewriting comments, arguments or functions that are related to displaced headers. >> - Remove "always true" parameter from `MonitorExitStub`. >> - Re-type/name metadata in `BasicLock`. >> >> Tier1-5 passes okay on supported platforms. >> >> All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu. > > src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 171: > >> 169: nonstatic_field(Array, _data[0], Klass*) \ >> 170: \ >> 171: volatile_nonstatic_field(BasicLock, _monitor, ObjectMonitor*) \ > > I don't see any references to this in the JVMCI code either. I assume the compiler/jvmci tests all passed with this change without any change to jvmci code. Maybe @mur47x111 can confirm. Correct, I dont think JVMCI tests will be affected. We only use this field (offset) in the actual monitorenter implementation to write ObjectMonitor cache. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27448#discussion_r2375418781 From amitkumar at openjdk.org Wed Sep 24 11:17:04 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 24 Sep 2025 11:17:04 GMT Subject: RFR: 8368518: [s390x] test failure with failed: wrong size of mach node Message-ID: Fixes the test failures. Tested tier1 with release and fastdebug vm. Moves one comment related to INTPRESSURE, a leftover from previous change. ------------- Commit messages: - test fix Changes: https://git.openjdk.org/jdk/pull/27465/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27465&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368518 Stats: 6 lines in 3 files changed: 1 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27465.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27465/head:pull/27465 PR: https://git.openjdk.org/jdk/pull/27465 From fyang at openjdk.org Wed Sep 24 11:34:08 2025 From: fyang at openjdk.org (Fei Yang) Date: Wed, 24 Sep 2025 11:34:08 GMT Subject: RFR: 8368366: RISC-V: AlignVector is mistakenly set to AvoidUnalignedAccesses In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 07:21:47 GMT, Fei Yang wrote: > Hi, please consider this small change fixing setting of `AlignVector` flag on RISC-V. > > According to the latest RISC-V linux hardware probing syscall [1], the performance of misaligned memory accesses > has been divided into two cases: `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` and `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` > for scalar and vector respectively. And `RISCV_HWPROBE_KEY_CPUPERF_0` is now deprecated and it returns similar values > to `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`. > > Previously, we use `RISCV_HWPROBE_KEY_CPUPERF_0` to detect support for misaligned memory accesses and reflect the result > on these VM flags: `AvoidUnalignedAccesses`, `UseUnalignedAccesses` and `AlignVector`. But it doesn't seem correct to update > `AlignVector` according to this value. And this is causing issues on RISC-V hardwares which have fast misaligned accesses only > for the scalar case. I witnessed SIGBUG error on these hardwares when doing vector misaligned accesses. > > So we should align AlignVector with `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` instead. This patch just reverts the previous > setting of AlignVector and just let it have the default value which is true. I will try to add detection in a separate PR > for `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` and update `AlignVector` accordingly. > > [1] https://docs.kernel.org/arch/riscv/hwprobe.html Thanks all for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27445#issuecomment-3327956706 From fyang at openjdk.org Wed Sep 24 11:34:09 2025 From: fyang at openjdk.org (Fei Yang) Date: Wed, 24 Sep 2025 11:34:09 GMT Subject: Integrated: 8368366: RISC-V: AlignVector is mistakenly set to AvoidUnalignedAccesses In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 07:21:47 GMT, Fei Yang wrote: > Hi, please consider this small change fixing setting of `AlignVector` flag on RISC-V. > > According to the latest RISC-V linux hardware probing syscall [1], the performance of misaligned memory accesses > has been divided into two cases: `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` and `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` > for scalar and vector respectively. And `RISCV_HWPROBE_KEY_CPUPERF_0` is now deprecated and it returns similar values > to `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`. > > Previously, we use `RISCV_HWPROBE_KEY_CPUPERF_0` to detect support for misaligned memory accesses and reflect the result > on these VM flags: `AvoidUnalignedAccesses`, `UseUnalignedAccesses` and `AlignVector`. But it doesn't seem correct to update > `AlignVector` according to this value. And this is causing issues on RISC-V hardwares which have fast misaligned accesses only > for the scalar case. I witnessed SIGBUG error on these hardwares when doing vector misaligned accesses. > > So we should align AlignVector with `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` instead. This patch just reverts the previous > setting of AlignVector and just let it have the default value which is true. I will try to add detection in a separate PR > for `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` and update `AlignVector` accordingly. > > [1] https://docs.kernel.org/arch/riscv/hwprobe.html This pull request has now been integrated. Changeset: 2313f8e4 Author: Fei Yang URL: https://git.openjdk.org/jdk/commit/2313f8e4ebe5b6d7542fa8a33fd08673cc0caf10 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod 8368366: RISC-V: AlignVector is mistakenly set to AvoidUnalignedAccesses Reviewed-by: fjiang, rehn, mli ------------- PR: https://git.openjdk.org/jdk/pull/27445 From fyang at openjdk.org Wed Sep 24 11:35:01 2025 From: fyang at openjdk.org (Fei Yang) Date: Wed, 24 Sep 2025 11:35:01 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v5] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 17:33:30 GMT, Hamlin Li wrote: > Hey @luhenry @RealFYang , do you have further comments I need to address? Hi, Thanks for the update. I'll take another look. Sorry for the late reply. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27152#issuecomment-3327966216 From mdoerr at openjdk.org Wed Sep 24 11:37:57 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 24 Sep 2025 11:37:57 GMT Subject: RFR: 8368518: [s390x] test failure with failed: wrong size of mach node In-Reply-To: References: Message-ID: <46pmm8D33j20h_gx6H3FbNsw_PV-OqF7HBHThNFVYWQ=.f4329e92-1a55-4e2a-b4b4-ed2f8b5f10dd@github.com> On Wed, 24 Sep 2025 11:11:12 GMT, Amit Kumar wrote: > Fixes the test failures. Tested tier1 with release and fastdebug vm. > > Moves one comment related to INTPRESSURE, a leftover from previous change. LGTM. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27465#pullrequestreview-3262466165 From fbredberg at openjdk.org Wed Sep 24 11:47:49 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 24 Sep 2025 11:47:49 GMT Subject: RFR: 8365191: Cleanup after removing LockingMode related code In-Reply-To: References: Message-ID: <0xLQ9GAdAiDIXkO9rqULMOLK4oLe1_9nGwNKhxK-_7M=.57a07007-60e5-4d63-9bae-2b9442272a91@github.com> On Tue, 23 Sep 2025 17:26:36 GMT, Coleen Phillimore wrote: >> This is a general cleanup after removing `LockingMode` related code. >> It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261). >> It includes: >> - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking. >> - Removing or rewriting comments, arguments or functions that are related to displaced headers. >> - Remove "always true" parameter from `MonitorExitStub`. >> - Re-type/name metadata in `BasicLock`. >> >> Tier1-5 passes okay on supported platforms. >> >> All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu. > > src/hotspot/share/runtime/vmStructs.cpp line 685: > >> 683: volatile_nonstatic_field(ObjectMonitor, _owner, int64_t) \ >> 684: volatile_nonstatic_field(ObjectMonitor, _next_om, ObjectMonitor*) \ >> 685: volatile_nonstatic_field(BasicLock, _monitor, ObjectMonitor*) \ > > Since nothing now refers to this, you can delete it from vmStructs. According to @mur47x111, they still need this line for their fast locking implementation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27448#discussion_r2375512919 From rehn at openjdk.org Wed Sep 24 11:59:18 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 24 Sep 2025 11:59:18 GMT Subject: RFR: 8367692: RISC-V: Align post call nop Message-ID: Hi please, consider. As ziccif require instructions to natural aligned to be atomic the 4 byte post call nop must be aligned. But I don't want to add a c.nop(2b) to align the nop(4b) which means the jal(r) must also be algined. As we have no utility to aligned the end of an instruction sequence the call it self is aligned and uses only 4 byte instructions. Only in the case where we could use an two c-instruction we may loose space. Thanks, Robbin ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/27467/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27467&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367692 Stats: 137 lines in 7 files changed: 76 ins; 28 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/27467.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27467/head:pull/27467 PR: https://git.openjdk.org/jdk/pull/27467 From mhaessig at openjdk.org Wed Sep 24 12:00:20 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Wed, 24 Sep 2025 12:00:20 GMT Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3] In-Reply-To: <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com> References: <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com> Message-ID: On Tue, 2 Sep 2025 20:52:32 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 three additional commits since the last revision: > > - revert whitespace change > - undo debug changes > - cleanup Thank you again for this extensive cleanup. I did another, more thorough, pass and have a few questions and suggestions. src/hotspot/cpu/arm/arm_32.ad line 436: > 434: bool far = (_method == nullptr) ? maybe_far_call(this) : !cache_reachable(); > 435: return (far ? 3 : 1) * NativeInstruction::instruction_size; > 436: } Why do we still need the `instruction_size` offset? Are all static java calls now method handles? src/hotspot/cpu/arm/frame_arm.cpp line 365: > 363: DEBUG_ONLY(verify_deopt_original_pc(sender_nm, _unextended_sp)); > 364: } > 365: } All of this could be `NOT_PRODUCT` and the method `const` if I did not miss any side effects. src/hotspot/cpu/arm/frame_arm.hpp line 1: > 1: /* Please update the copyright year. src/hotspot/cpu/arm/register_arm.hpp line 1: > 1: /* Please update the copyright year. src/hotspot/share/code/debugInfoRec.hpp line 1: > 1: /* Please update the copyright year. src/hotspot/share/code/nmethod.inline.hpp line 1: > 1: /* Please update the copyright year. src/hotspot/share/code/pcDesc.hpp line 1: > 1: /* Please update the copyright year. src/hotspot/share/jvmci/jvmciCodeInstaller.hpp line 1: > 1: /* Please update the copyright year. src/hotspot/share/opto/matcher.hpp line 1: > 1: /* Please update the copyright year. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/PCDesc.java line 1: > 1: /* Please update the copyright year. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64Frame.java line 1: > 1: /* Please update the copyright year. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/riscv64/RISCV64Frame.java line 1: > 1: /* Please update the copyright year. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java line 1: > 1: /* Please update the copyright year. ------------- Changes requested by mhaessig (Committer). PR Review: https://git.openjdk.org/jdk/pull/27059#pullrequestreview-3262358336 PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375411757 PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375419504 PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375518959 PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375519168 PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375519398 PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375523797 PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375524042 PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375524330 PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375524675 PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375525018 PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375525797 PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375526227 PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2375527000 From fbredberg at openjdk.org Wed Sep 24 12:01:41 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 24 Sep 2025 12:01:41 GMT Subject: RFR: 8365191: Cleanup after removing LockingMode related code [v2] In-Reply-To: References: Message-ID: > This is a general cleanup after removing `LockingMode` related code. > It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261). > It includes: > - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking. > - Removing or rewriting comments, arguments or functions that are related to displaced headers. > - Remove "always true" parameter from `MonitorExitStub`. > - Re-type/name metadata in `BasicLock`. > > Tier1-5 passes okay on supported platforms. > > All other platforms (arm, ppc, riscv and s390) 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/27448/files - new: https://git.openjdk.org/jdk/pull/27448/files/b5d57851..85457638 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27448&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27448&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27448.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27448/head:pull/27448 PR: https://git.openjdk.org/jdk/pull/27448 From fbredberg at openjdk.org Wed Sep 24 12:01:43 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 24 Sep 2025 12:01:43 GMT Subject: RFR: 8365191: Cleanup after removing LockingMode related code [v2] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 02:09:02 GMT, Fei Yang wrote: >> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: >> >> Update after review > > src/hotspot/cpu/riscv/c1_MacroAssembler_riscv.hpp line 71: > >> 69: // basic_lock: must be x10 & must point to the basic lock, contents destroyed >> 70: // temp : temporary register, must not be scratch register t0 or t1 >> 71: void unlock_object(Register swap, Register obj, Register lock, Register temp, Label& slow_case); > > You might want to rename the third param `lock` to `basic_lock`. > > > void unlock_object(Register swap, Register obj, Register basic_lock, Register temp, Label& slow_case); Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27448#discussion_r2375539612 From fbredberg at openjdk.org Wed Sep 24 12:01:46 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 24 Sep 2025 12:01:46 GMT Subject: RFR: 8365191: Cleanup after removing LockingMode related code [v2] In-Reply-To: References: Message-ID: <8fpIz-2CpbqESb-a1kb_o8io13ZPzLgyWF1acLUn-A0=.b4a88a33-c938-40c9-aab2-cae6a28b0a45@github.com> On Wed, 24 Sep 2025 11:13:42 GMT, Yudi Zheng wrote: >> src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 171: >> >>> 169: nonstatic_field(Array, _data[0], Klass*) \ >>> 170: \ >>> 171: volatile_nonstatic_field(BasicLock, _monitor, ObjectMonitor*) \ >> >> I don't see any references to this in the JVMCI code either. I assume the compiler/jvmci tests all passed with this change without any change to jvmci code. Maybe @mur47x111 can confirm. > > Correct, I dont think JVMCI tests will be affected. We only use this field (offset) in the actual monitorenter implementation to write ObjectMonitor cache. > edit: Sorry I missed the `delete it from vmStructs` context. We need this line for our fast locking implementation Removed line 171 from `vmStructs_jvmci.cpp`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27448#discussion_r2375544175 From luhenry at openjdk.org Wed Sep 24 12:17:35 2025 From: luhenry at openjdk.org (Ludovic Henry) Date: Wed, 24 Sep 2025 12:17:35 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v6] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 10:51:50 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> >> Currently, the cpu features of riscv are stored in separate RVFeature subclasses. >> But to support the store/restore CPU features for aot in the future, we need to store the cpu features in a continuous memory. >> As the riscv extensions are introduced continuously, I think it's better to do it via an simple bitmap at the beginning. >> Currently, just suppose the non-extension features will not be stored in aot image, so I also split the extension and non-extenion features. When we implement the related aot feature in the short future, we can revisit the way of splitting the features. Currently, just change the storage way of cpu features, lay the foundation for future aot. >> >> Thanks > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > refine src/hotspot/cpu/riscv/vm_version_riscv.cpp line 39: > 37: > 38: #define DEF_RV_EXT_FEATURE(NAME, PRETTY, LINUX_BIT, CPU_FEATURE_INDEX, FSTRING, FLAGF) \ > 39: VM_Version::NAME##RVExtFeatureValue VM_Version::NAME(#PRETTY, LINUX_BIT, CPU_FEATURE_INDEX, FSTRING); Why do you need to pass the parameters to this constructor, when you are also using `RV_EXT_FEATURE_FLAGS` to generate the body of the constructor at https://github.com/openjdk/jdk/pull/27152/files#diff-d8b70800fb68e0478dd0936c7f4a08b1bb59ce7a276ad1140355933c246372caR242-R243. Can't we simply have the following here: #define DEF_RV_EXT_FEATURE(NAME, PRETTY, LINUX_BIT, CPU_FEATURE_INDEX, FSTRING, FLAGF) \ VM_Version::NAME##RVExtFeatureValue VM_Version::NAME( RV_EXT_FEATURE_FLAGS(DEF_RV_EXT_FEATURE) #undef DEF_RV_EXT_FEATURE With the constructor defined as: #define DECLARE_RV_EXT_FEATURE(NAME, PRETTY, LINUX_BIT, CPU_FEATURE_INDEX, FSTRING, FLAGF) \ struct NAME##RVExtFeatureValue : public RVExtFeatureValue { \ NAME##RVExtFeatureValue() : \ RVExtFeatureValue(#PRETTY, LINUX_BIT, CPU_FEATURE_INDEX, FSTRING) {} \ FLAGF; \ }; \ static NAME##RVExtFeatureValue NAME; \ RV_EXT_FEATURE_FLAGS(DECLARE_RV_EXT_FEATURE) src/hotspot/cpu/riscv/vm_version_riscv.cpp line 44: > 42: > 43: #define DEF_RV_NON_EXT_FEATURE(NAME, PRETTY, LINUX_BIT, FSTRING, FLAGF) \ > 44: VM_Version::NAME##RVNonExtFeatureValue VM_Version::NAME(#PRETTY, LINUX_BIT, FSTRING); Same as https://github.com/openjdk/jdk/pull/27152/files#r2375581724, can't we have the following: #define DEF_RV_NON_EXT_FEATURE(NAME, PRETTY, LINUX_BIT, FSTRING, FLAGF) \ VM_Version::NAME##RVNonExtFeatureValue VM_Version::NAME(); RV_NON_EXT_FEATURE_FLAGS(DEF_RV_NON_EXT_FEATURE) #undef DEF_RV_NON_EXT_FEATURE With the constructor defined as: #define DECLARE_RV_NON_EXT_FEATURE(NAME, PRETTY, LINUX_BIT, FSTRING, FLAGF) \ struct NAME##RVNonExtFeatureValue : public RVNonExtFeatureValue { \ NAME##RVNonExtFeatureValue() : \ RVNonExtFeatureValue(#PRETTY, LINUX_BIT, FSTRING) {} \ FLAGF; \ }; \ static NAME##RVNonExtFeatureValue NAME; \ RV_NON_EXT_FEATURE_FLAGS(DECLARE_RV_NON_EXT_FEATURE) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2375581724 PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2375586058 From luhenry at openjdk.org Wed Sep 24 12:20:37 2025 From: luhenry at openjdk.org (Ludovic Henry) Date: Wed, 24 Sep 2025 12:20:37 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v5] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 10:53:34 GMT, Hamlin Li wrote: >> Yes, it'll be good if we can just remove the explicit numbering of the enum, but seems there is no good way to pass in the enum value to the constructor of `NAME##RVExtFeatureValue` in `DEF_RV_EXT_FEATURE`. We could do it with an static member of RVExtFeatureValue, increment it in RVExtFeatureValue constructor, but seems it's not straight and clear. >> So my preference is to keep the explicit enum value in `RV_EXT_FEATURE_FLAGS`. >> How do you think about it? > > We also need this feature index when construct a `NAME##RVExtFeatureValue` instance in vm_version_riscv.cpp Can't we define the constructor as (including the comment at https://github.com/openjdk/jdk/pull/27152/files#r2375581724): #define DECLARE_RV_EXT_FEATURE(NAME, PRETTY, LINUX_BIT, CPU_FEATURE_INDEX, FSTRING, FLAGF) \ struct NAME##RVExtFeatureValue : public RVExtFeatureValue { \ NAME##RVExtFeatureValue() : \ RVExtFeatureValue(#PRETTY, LINUX_BIT, CPU_#NAME, FSTRING) {} \ FLAGF; \ }; \ static NAME##RVExtFeatureValue NAME; (note the use of `CPU_#NAME` in place of `CPU_FEATURE_INDEX`) That way you use the enum's implicit value, and you don't need to have an explicit `CPU_FEATURE_INDEX`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2375592908 From coleenp at openjdk.org Wed Sep 24 12:50:50 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 24 Sep 2025 12:50:50 GMT Subject: RFR: 8365191: Cleanup after removing LockingMode related code [v2] In-Reply-To: <0xLQ9GAdAiDIXkO9rqULMOLK4oLe1_9nGwNKhxK-_7M=.57a07007-60e5-4d63-9bae-2b9442272a91@github.com> References: <0xLQ9GAdAiDIXkO9rqULMOLK4oLe1_9nGwNKhxK-_7M=.57a07007-60e5-4d63-9bae-2b9442272a91@github.com> Message-ID: On Wed, 24 Sep 2025 11:44:58 GMT, Fredrik Bredberg wrote: >> src/hotspot/share/runtime/vmStructs.cpp line 685: >> >>> 683: volatile_nonstatic_field(ObjectMonitor, _owner, int64_t) \ >>> 684: volatile_nonstatic_field(ObjectMonitor, _next_om, ObjectMonitor*) \ >>> 685: volatile_nonstatic_field(BasicLock, _monitor, ObjectMonitor*) \ >> >> Since nothing now refers to this, you can delete it from vmStructs. > > According to @mur47x111, they still need this line for their fast locking implementation. Oh you were supposed to leave the field in vmStructs_jvmci.cpp and remove it from this one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27448#discussion_r2375681060 From coleenp at openjdk.org Wed Sep 24 12:54:16 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 24 Sep 2025 12:54:16 GMT Subject: RFR: 8367989: Remove InstanceKlass::allocate_objArray and ArrayKlass::allocate_arrayArray [v3] In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 13:18:09 GMT, Coleen Phillimore wrote: >> This change removes InstanceKlass::allocate_objArray and has its caller call ObjArrayKlass::allocate_instance directly from oopFactory, like the other array allocations do. See CR for more information why we should have this change. I also removed element_klass_addr() and moved element_klass_offset() to be in a more logical place near element_klass() functions. This upstreams a tiny valhalla diff. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Use virtual function rather than if statement, still need one cast though. Thanks for reviewing Stefan and Fred. Testing was clean. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27372#issuecomment-3328268778 From coleenp at openjdk.org Wed Sep 24 12:54:18 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 24 Sep 2025 12:54:18 GMT Subject: Integrated: 8367989: Remove InstanceKlass::allocate_objArray and ArrayKlass::allocate_arrayArray In-Reply-To: References: Message-ID: On Thu, 18 Sep 2025 18:27:14 GMT, Coleen Phillimore wrote: > This change removes InstanceKlass::allocate_objArray and has its caller call ObjArrayKlass::allocate_instance directly from oopFactory, like the other array allocations do. See CR for more information why we should have this change. I also removed element_klass_addr() and moved element_klass_offset() to be in a more logical place near element_klass() functions. This upstreams a tiny valhalla diff. > Tested with tier1-4. This pull request has now been integrated. Changeset: e8adc1f8 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/e8adc1f81656126deae5bf7e0c912d5ad50dbbeb Stats: 33 lines in 6 files changed: 2 ins; 28 del; 3 mod 8367989: Remove InstanceKlass::allocate_objArray and ArrayKlass::allocate_arrayArray Reviewed-by: stefank, fparain ------------- PR: https://git.openjdk.org/jdk/pull/27372 From aph at openjdk.org Wed Sep 24 12:57:56 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 24 Sep 2025 12:57:56 GMT Subject: RFR: 8368303: AlwaysAtomicAccesses is excessively strict In-Reply-To: References: Message-ID: <3iNJe3osexjMT-Ifr8UkuPqQ38U2gjcYzVGT4TNZALw=.a67f797c-1cab-4d38-b249-88ecef5379c1@github.com> On Wed, 24 Sep 2025 09:00:58 GMT, Albert Mingkun Yang wrote: > I thought the `else` branch is implementing the "optimization" -- using plain store/move for smaller types. The problem is that when an access is marked as volatile, the back end has to believe it, even for less-than-word sizes when `AlwaysAtomicAssesses` is turned on. The back end has no way to know if the user code really needs a volatile store, so the back end has to assume that it is, and can't use a simple store. But all of this is pointless on a target that is single-copy atomic. x86 can generate plain accesses for volatile accesses, but most processors can't do that. we need to distinguish between volatile and non-volatile accesses. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27432#issuecomment-3328283888 From fbredberg at openjdk.org Wed Sep 24 12:58:57 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 24 Sep 2025 12:58:57 GMT Subject: RFR: 8365191: Cleanup after removing LockingMode related code [v2] In-Reply-To: References: <0xLQ9GAdAiDIXkO9rqULMOLK4oLe1_9nGwNKhxK-_7M=.57a07007-60e5-4d63-9bae-2b9442272a91@github.com> Message-ID: On Wed, 24 Sep 2025 12:48:00 GMT, Coleen Phillimore wrote: >> According to @mur47x111, they still need this line for their fast locking implementation. > > Oh you were supposed to leave the field in vmStructs_jvmci.cpp and remove it from this one. Yea, I got it all mixed up in my head. Will fix it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27448#discussion_r2375703603 From fbredberg at openjdk.org Wed Sep 24 13:05:23 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 24 Sep 2025 13:05:23 GMT Subject: RFR: 8365191: Cleanup after removing LockingMode related code [v3] In-Reply-To: References: Message-ID: > This is a general cleanup after removing `LockingMode` related code. > It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261). > It includes: > - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking. > - Removing or rewriting comments, arguments or functions that are related to displaced headers. > - Remove "always true" parameter from `MonitorExitStub`. > - Re-type/name metadata in `BasicLock`. > > Tier1-5 passes okay on supported platforms. > > All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu. Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: Fixed a mixup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27448/files - new: https://git.openjdk.org/jdk/pull/27448/files/85457638..43f9c0af Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27448&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27448&range=01-02 Stats: 3 lines in 2 files changed: 2 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27448.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27448/head:pull/27448 PR: https://git.openjdk.org/jdk/pull/27448 From fbredberg at openjdk.org Wed Sep 24 13:05:24 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 24 Sep 2025 13:05:24 GMT Subject: RFR: 8365191: Cleanup after removing LockingMode related code [v3] In-Reply-To: <8fpIz-2CpbqESb-a1kb_o8io13ZPzLgyWF1acLUn-A0=.b4a88a33-c938-40c9-aab2-cae6a28b0a45@github.com> References: <8fpIz-2CpbqESb-a1kb_o8io13ZPzLgyWF1acLUn-A0=.b4a88a33-c938-40c9-aab2-cae6a28b0a45@github.com> Message-ID: On Wed, 24 Sep 2025 11:58:43 GMT, Fredrik Bredberg wrote: >> Correct, I dont think JVMCI tests will be affected. We only use this field (offset) in the actual monitorenter implementation to write ObjectMonitor cache. >> edit: Sorry I missed the `delete it from vmStructs` context. We need this line for our fast locking implementation > > Removed line 171 from `vmStructs_jvmci.cpp`. Reinstalled line 171 from vmStructs_jvmci.cpp. Sorry for the mixup. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27448#discussion_r2375719236 From fbredberg at openjdk.org Wed Sep 24 13:05:25 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 24 Sep 2025 13:05:25 GMT Subject: RFR: 8365191: Cleanup after removing LockingMode related code [v3] In-Reply-To: References: <0xLQ9GAdAiDIXkO9rqULMOLK4oLe1_9nGwNKhxK-_7M=.57a07007-60e5-4d63-9bae-2b9442272a91@github.com> Message-ID: On Wed, 24 Sep 2025 12:55:51 GMT, Fredrik Bredberg wrote: >> Oh you were supposed to leave the field in vmStructs_jvmci.cpp and remove it from this one. > > Yea, I got it all mixed up in my head. Will fix it. Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27448#discussion_r2375717181 From coleenp at openjdk.org Wed Sep 24 13:07:00 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 24 Sep 2025 13:07:00 GMT Subject: RFR: 8365191: Cleanup after removing LockingMode related code [v3] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 13:05:23 GMT, Fredrik Bredberg wrote: >> This is a general cleanup after removing `LockingMode` related code. >> It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261). >> It includes: >> - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking. >> - Removing or rewriting comments, arguments or functions that are related to displaced headers. >> - Remove "always true" parameter from `MonitorExitStub`. >> - Re-type/name metadata in `BasicLock`. >> >> Tier1-5 passes okay on supported platforms. >> >> All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > Fixed a mixup Looks good! ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27448#pullrequestreview-3262810994 From yzheng at openjdk.org Wed Sep 24 13:13:53 2025 From: yzheng at openjdk.org (Yudi Zheng) Date: Wed, 24 Sep 2025 13:13:53 GMT Subject: RFR: 8365191: Cleanup after removing LockingMode related code [v3] In-Reply-To: References: Message-ID: <0-k1XZdfzcUtKM2YhXUXW7ySBnZUxyU4DZ-kUpzWSPM=.0cf78c01-e8db-4f55-94b1-a499b5b2fc85@github.com> On Wed, 24 Sep 2025 13:05:23 GMT, Fredrik Bredberg wrote: >> This is a general cleanup after removing `LockingMode` related code. >> It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261). >> It includes: >> - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking. >> - Removing or rewriting comments, arguments or functions that are related to displaced headers. >> - Remove "always true" parameter from `MonitorExitStub`. >> - Re-type/name metadata in `BasicLock`. >> >> Tier1-5 passes okay on supported platforms. >> >> All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > Fixed a mixup LGTM ------------- Marked as reviewed by yzheng (Committer). PR Review: https://git.openjdk.org/jdk/pull/27448#pullrequestreview-3262839280 From jkern at openjdk.org Wed Sep 24 13:29:31 2025 From: jkern at openjdk.org (Joachim Kern) Date: Wed, 24 Sep 2025 13:29:31 GMT Subject: RFR: 8368250: [AIX] now ubsan vptr check is also possible (follow up of JDK-8354686) Message-ID: After [JDK-8354686](https://bugs.openjdk.org/browse/JDK-8354686) the ubsan vptr checks still did not work. We finally found out, that they only work, if all linkage units are linked with the C++ compiler frontend as linker, especially the main executables (java, javac, ...) which are linked with the C compiler frontend. So for a ubsan enabled build on AIX we let everything link with the C++ compiler frontend. Background: The C++ compiler frontend inherently adds special static libraries which the C compiler does not. This results in missing symbols when trying to start a program and its shared libraries, when they were linked in mixed mode. ------------- Commit messages: - JDK-8368250 Changes: https://git.openjdk.org/jdk/pull/27468/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27468&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368250 Stats: 9 lines in 3 files changed: 5 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27468.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27468/head:pull/27468 PR: https://git.openjdk.org/jdk/pull/27468 From mli at openjdk.org Wed Sep 24 13:29:41 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 24 Sep 2025 13:29:41 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v7] In-Reply-To: References: Message-ID: <6xTzmgEcZfGmJkvGt0yvg7iqc_LmuAZb4Y6m5IDUOX8=.518950d7-aadc-487a-a33d-66ba7f2209f4@github.com> > Hi, > Can you help to review this patch? > > Currently, the cpu features of riscv are stored in separate RVFeature subclasses. > But to support the store/restore CPU features for aot in the future, we need to store the cpu features in a continuous memory. > As the riscv extensions are introduced continuously, I think it's better to do it via an simple bitmap at the beginning. > Currently, just suppose the non-extension features will not be stored in aot image, so I also split the extension and non-extenion features. When we implement the related aot feature in the short future, we can revisit the way of splitting the features. Currently, just change the storage way of cpu features, lay the foundation for future aot. > > Thanks Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: remove explicit cpu feature index in RV_EXT_FEATURE_FLAGS ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27152/files - new: https://git.openjdk.org/jdk/pull/27152/files/414f1463..8a00f215 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27152&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27152&range=05-06 Stats: 62 lines in 2 files changed: 0 ins; 0 del; 62 mod Patch: https://git.openjdk.org/jdk/pull/27152.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27152/head:pull/27152 PR: https://git.openjdk.org/jdk/pull/27152 From mli at openjdk.org Wed Sep 24 13:29:43 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 24 Sep 2025 13:29:43 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v6] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 10:51:50 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> >> Currently, the cpu features of riscv are stored in separate RVFeature subclasses. >> But to support the store/restore CPU features for aot in the future, we need to store the cpu features in a continuous memory. >> As the riscv extensions are introduced continuously, I think it's better to do it via an simple bitmap at the beginning. >> Currently, just suppose the non-extension features will not be stored in aot image, so I also split the extension and non-extenion features. When we implement the related aot feature in the short future, we can revisit the way of splitting the features. Currently, just change the storage way of cpu features, lay the foundation for future aot. >> >> Thanks > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > refine @luhenry Thank you for the suggestion, it make the code look much better! :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27152#issuecomment-3328430569 From tschatzl at openjdk.org Wed Sep 24 13:37:12 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 24 Sep 2025 13:37:12 GMT Subject: RFR: 8368367: Test jdk/jfr/event/gc/detailed/TestGCHeapMemoryUsageEvent.java fails jdk.GCHeapMemoryUsage "expected 0 > 0" [v2] In-Reply-To: References: <2E4HThSyBO6onGz4gXIEekO6Xi-LbLfnsPH5jiVBrgU=.813dfd55-7cb4-4fc2-86f6-f4b9bb6c168a@github.com> Message-ID: On Tue, 23 Sep 2025 16:40:44 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * fix copyright year > > Marked as reviewed by ayang (Reviewer). Thanks @albertnetymk @sendaoYan @walulyai for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/27451#issuecomment-3328482475 From asmehra at openjdk.org Wed Sep 24 13:37:13 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 24 Sep 2025 13:37:13 GMT Subject: RFR: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry [v5] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 02:32:29 GMT, Ashutosh Mehra wrote: >> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove incorrectly placed ShouldNotReachHere statements >> >> Signed-off-by: Ashutosh Mehra > > I have updated the changes to remove `ShouldNotReachHere()` from the entry point getter methods in `AdapterHandlerEntry`. With that I am able to build ZeroVM and `java -version` works fine too. > I started `hotspot_runtime_no_cds` tests with ZeroVM but it wass taking forever to complete on my system. And there were already some failures. Do we know if the jtreg tests pass with ZeroVM? > @ashu-mehra don't worry Zero Vm passing jtreg testing. We only need to pass the build. okay, then I think it is good to go now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27101#issuecomment-3328483775 From tschatzl at openjdk.org Wed Sep 24 13:41:10 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 24 Sep 2025 13:41:10 GMT Subject: Integrated: 8368367: Test jdk/jfr/event/gc/detailed/TestGCHeapMemoryUsageEvent.java fails jdk.GCHeapMemoryUsage "expected 0 > 0" In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 12:39:03 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to the TestGCHeapMemoryUsageEvent test that checks whether these kind of events are posted and contain some sensibles values. > > In this failure, the `used` metric for the first of two events that is checked was zero. This is because G1, the default collector, updates the `used` value only at certain synchronization points to avoid inconsistencies in other cases. One of these synchronization points is region refill. With the 30gb heap in the test environment, region size is larger than what is allocated during startup, so no region refill/synchronization point has been reached yet, and `used` turns out to be `0`. > > This change fixes this by checking the last event instead of the first, it must have happened after that `system.gc()` call in the test, and `used` ought to be larger than zero because of allocations during VM startup. > > An alternative could be limiting the test's heap size to something small, that would also help, but I thought this might need additional explanations. > > Testing: local runs with G1 heap region size >= 16M or so do not fail any more. > > Thanks, > Thomas This pull request has now been integrated. Changeset: ed31023f Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/ed31023fc5a96a6f9a16c8a5c0fc86e794ce4aa7 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8368367: Test jdk/jfr/event/gc/detailed/TestGCHeapMemoryUsageEvent.java fails jdk.GCHeapMemoryUsage "expected 0 > 0" Reviewed-by: iwalulya, ayang, syan ------------- PR: https://git.openjdk.org/jdk/pull/27451 From tschatzl at openjdk.org Wed Sep 24 13:41:09 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 24 Sep 2025 13:41:09 GMT Subject: RFR: 8352069: Renamings after JEP 522: G1 GC: Improve Throughput by Reducing Synchronization In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 16:41:30 GMT, Albert Mingkun Yang wrote: >> Hi all, >> >> please review this change that implements some deferred cleanups from JEP 522. >> >> Just some renaming for all platform-specific files. >> >> Testing: gha >> >> Thanks, >> Thomas > > Marked as reviewed by ayang (Reviewer). Thanks @albertnetymk @walulyai for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/27450#issuecomment-3328486436 From asmehra at openjdk.org Wed Sep 24 13:41:11 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 24 Sep 2025 13:41:11 GMT Subject: Integrated: 8366905: Store AdapterBlob pointer in AdapterHandlerEntry In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 14:49:48 GMT, Ashutosh Mehra wrote: > This PR removes the need to store entry point addresses in AdapterHandlerEntry by storing a direct pointer to AdapterBlob instead. Entry point addresses can be computed on the fly from the entry point offsets stored in AdapterBlob. This pull request has now been integrated. Changeset: 156eb767 Author: Ashutosh Mehra URL: https://git.openjdk.org/jdk/commit/156eb767f13ddc2c0a250950e208340db5989e3a Stats: 296 lines in 12 files changed: 66 ins; 113 del; 117 mod 8366905: Store AdapterBlob pointer in AdapterHandlerEntry Reviewed-by: kvn, adinn ------------- PR: https://git.openjdk.org/jdk/pull/27101 From tschatzl at openjdk.org Wed Sep 24 13:41:11 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 24 Sep 2025 13:41:11 GMT Subject: Integrated: 8352069: Renamings after JEP 522: G1 GC: Improve Throughput by Reducing Synchronization In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 11:45:08 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that implements some deferred cleanups from JEP 522. > > Just some renaming for all platform-specific files. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: f7c9fef9 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/f7c9fef9147ee3c6168469ec04d2946a34505d63 Stats: 66 lines in 6 files changed: 0 ins; 0 del; 66 mod 8352069: Renamings after JEP 522: G1 GC: Improve Throughput by Reducing Synchronization Reviewed-by: iwalulya, ayang ------------- PR: https://git.openjdk.org/jdk/pull/27450 From stuefe at openjdk.org Wed Sep 24 13:53:26 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 24 Sep 2025 13:53:26 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps [v3] In-Reply-To: References: Message-ID: > When we run with ASAN enabled and ASAN catches an error, it reports, then stops the JVM. hs-err files and crash dumps at that point would be incredibly useful, though. The ASAN error report itself is seldom enlightening since it only contains native stacks. > > This patch makes it possible to get hs-err files and subsequent crash dumps by using the error callback functionality of ASAN. It registers a callback which gets called when ASAN catches an error. We then - carefully - print out the ASAN report to stderr (as ASAN itself would have done) and proceeed to end the JVM with a `fatal()`, which gives us an hs-err file, a callstack at that point including Java frames, and - if enabled - core dumps. > > Tested on Fedora 42 and Debian 12, both manually and by running the new companion jtreg test. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: rethink core file behavior ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27446/files - new: https://git.openjdk.org/jdk/pull/27446/files/69d5cf5d..f1f5617f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27446&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27446&range=01-02 Stats: 95 lines in 4 files changed: 61 ins; 9 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/27446.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27446/head:pull/27446 PR: https://git.openjdk.org/jdk/pull/27446 From rcastanedalo at openjdk.org Wed Sep 24 14:21:10 2025 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Wed, 24 Sep 2025 14:21:10 GMT Subject: RFR: 8359378: aarch64: crash when using -XX:+UseFPUForSpilling In-Reply-To: References: <0MbLaZYRoz-raa9x1eZycxeHE7mvPiGJujQpg8vBdek=.e3483c47-ad65-4d09-baf5-2db9b780669d@github.com> Message-ID: On Thu, 18 Sep 2025 11:57:13 GMT, Roberto Casta?eda Lozano wrote: > > Right, @robcasloz, I started investigating this issue thinking it was something wrong in my own code. Once I realized it was a common issue already assigned, I decided to propose a fix since it looked a bit abandoned. I didn?t mean to bypass your work -- you?re right, I should have contacted you first. Anyway, I?d appreciate your review. Do you think my change is reasonable? If not, let me close this PR and leave it to you. The changeset looks good to me, let me just run some testing before approval. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27350#issuecomment-3328772823 From bulasevich at openjdk.org Wed Sep 24 14:21:08 2025 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Wed, 24 Sep 2025 14:21:08 GMT Subject: RFR: 8359378: aarch64: crash when using -XX:+UseFPUForSpilling In-Reply-To: <0MbLaZYRoz-raa9x1eZycxeHE7mvPiGJujQpg8vBdek=.e3483c47-ad65-4d09-baf5-2db9b780669d@github.com> References: <0MbLaZYRoz-raa9x1eZycxeHE7mvPiGJujQpg8vBdek=.e3483c47-ad65-4d09-baf5-2db9b780669d@github.com> Message-ID: On Wed, 17 Sep 2025 16:19:12 GMT, Boris Ulasevich wrote: > AArch64 BarrierSetAssembler path assumes only FP/vector ideal regs reach the FP spill/restore encoding. With -XX:+UseFPUForSpilling Register Allocator may allocate scalar values in FP registers. When such values (Op_RegI/Op_RegN/Op_RegL/Op_RegP) hit `BarrierSetAssembler::encode_float_vector_register_size`, we trip ShouldNotReachHere in release build and **"unexpected ideal register"** assertion in debug build. > > Fix: teach the encoder to handle scalar ideal regs when they physically live in FP regs: > - treat Op_RegI / Op_RegN as 32-bit (single slot) - same class as Op_RegF > - treat Op_RegL / Op_RegP as 64-bit (two slots) - same class as Op_RegD > > Related: > - reproduced since #19746 > - spilling logic: > - #18967 > - #17977 > > Testing: tier1-3 with javaoptions -Xcomp -Xbatch -XX:+UseFPUForSpilling on AARCH I suggest handling this in two steps: - In JDK 25 we fix the crash when UseFPUForSpilling is enabled. - In the next release we prohibit the option softly: if it is set on the command line, the VM prints a warning and resets it to false. Proposed change for the latter: diff --git a/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp b/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp index 308deeaf5e2..7702988c11c 100644 --- a/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp +++ b/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp @@ -621,4 +621,9 @@ void VM_Version::initialize() { FLAG_SET_DEFAULT(UseVectorizedHashCodeIntrinsic, true); } + + if (UseFPUForSpilling) { + warning("UseFPUForSpilling is known to degrade performance on this platform and will be ignored."); + FLAG_SET_DEFAULT(UseFPUForSpilling, false); + } #endif ------------- PR Comment: https://git.openjdk.org/jdk/pull/27350#issuecomment-3312695352 From stuefe at openjdk.org Wed Sep 24 14:23:45 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 24 Sep 2025 14:23:45 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps [v4] In-Reply-To: References: Message-ID: > When we run with ASAN enabled and ASAN catches an error, it reports, then stops the JVM. hs-err files and crash dumps at that point would be incredibly useful, though. The ASAN error report itself is seldom enlightening since it only contains native stacks. > > This patch makes it possible to get hs-err files and subsequent crash dumps by using the error callback functionality of ASAN. It registers a callback which gets called when ASAN catches an error. We then - carefully - print out the ASAN report to stderr (as ASAN itself would have done) and proceeed to end the JVM with a `fatal()`, which gives us an hs-err file, a callstack at that point including Java frames, and - if enabled - core dumps. > > Tested on Fedora 42 and Debian 12, both manually and by running the new companion jtreg test. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27446/files - new: https://git.openjdk.org/jdk/pull/27446/files/f1f5617f..4adc9689 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27446&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27446&range=02-03 Stats: 11 lines in 1 file changed: 3 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27446.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27446/head:pull/27446 PR: https://git.openjdk.org/jdk/pull/27446 From stuefe at openjdk.org Wed Sep 24 14:36:10 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 24 Sep 2025 14:36:10 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps [v4] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 14:23:45 GMT, Thomas Stuefe wrote: >> When we run with ASAN enabled and ASAN catches an error, it reports, then stops the JVM. hs-err files and crash dumps at that point would be incredibly useful, though. The ASAN error report itself is seldom enlightening since it only contains native stacks. >> >> This patch makes it possible to get hs-err files and subsequent crash dumps by using the error callback functionality of ASAN. It registers a callback which gets called when ASAN catches an error. We then - carefully - print out the ASAN report to stderr (as ASAN itself would have done) and proceeed to end the JVM with a `fatal()`, which gives us an hs-err file, a callstack at that point including Java frames, and - if enabled - core dumps. >> >> Tested on Fedora 42 and Debian 12, both manually and by running the new companion jtreg test. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > fix Hi all, After feedback by @MBaesken and the question of @dean-long, I reworked the patch to make the JVM exhibit exactly the same behaviors with regard to core files that a standard ASAN-instrumented binary would show. There is a longer story behind that; see the lengthy comment in address.cpp. The gist of it: ASAN, by default, inhibits core file generation. To get cores, one needs to set `abort_on_error=1` and `disable_coredump=0`. The first version of my patch was more permissive and allowed core files despite these settings; that was bad (thanks @MBaesken for reminding me) since in mass integration tests done with ASAN, you don't want cores enabled. Note that cores can also get enormous with ASAN. The new patch exhibits the same behavior as a standard ASAN-instrumented binary: core files are only generated if `abort_on_error=1` and `disable_coredump=0`. By default, this prevents core files. This overrules +CreateCoredumpOnCrash in the JVM (by default enabled). I think this is a good compromise. Anyone wanting to get cores with ASAN would use the standard ASAN options for this. @dean-long > I haven't tried it yet, but what happens if we cause ASAN to abort by setting the flag in the environment: export ASAN_OPTIONS=abort_on_error=1. Do we get a useful stack trace in the hs_err file? Yes, hs-err files are now generated in all cases. That is independent of core generation. We now 1) print the ASAN report to stderr, then 2) dump an hs-err file, which also contains the ASAN report, then optionally 3) create a core dump. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27446#issuecomment-3328850811 From stefank at openjdk.org Wed Sep 24 14:39:21 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 24 Sep 2025 14:39:21 GMT Subject: RFR: 8367013: Add Atomic to package/replace idiom of volatile var plus AtomicAccess:: operations In-Reply-To: References: Message-ID: <3nRiWxbET2Bf7i1VNfWGH12omfPxcTaC6W2UhLVDDH0=.0c34542e-e08b-42e3-b35b-ae98c46abe0a@github.com> On Wed, 24 Sep 2025 05:32:38 GMT, Kim Barrett wrote: > Please review this change that adds the type `Atomic`, to use as the type > of a variable that is accessed (including writes) concurrently by multiple > threads. This is intended to replace (most) uses of the current HotSpot idiom > of declaring a variable `volatile` and accessing that variable using functions > from the AtomicAccess class. > https://github.com/openjdk/jdk/blame/528f93f8cb9f1fb9c19f31ab80c8a546f47beed2/doc/hotspot-style.md#L138-L147 > > Testing: mach5 tier1-6, GHA sanity tests I tested this in my editor (Eclipse) and it doesn't seem to give any code completion because of this: // The Atomic type. template using Atomic = AtomicImpl::Selected; If I explicitly use AtomicImpl::AtomicInteger then I get the expected code completion. I wonder if this is going to be problematic with other editors or if this is just a problem with Eclipse. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27462#issuecomment-3328888539 From aph at openjdk.org Wed Sep 24 14:45:47 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 24 Sep 2025 14:45:47 GMT Subject: RFR: 8359378: aarch64: crash when using -XX:+UseFPUForSpilling In-Reply-To: <0MbLaZYRoz-raa9x1eZycxeHE7mvPiGJujQpg8vBdek=.e3483c47-ad65-4d09-baf5-2db9b780669d@github.com> References: <0MbLaZYRoz-raa9x1eZycxeHE7mvPiGJujQpg8vBdek=.e3483c47-ad65-4d09-baf5-2db9b780669d@github.com> Message-ID: On Wed, 17 Sep 2025 16:19:12 GMT, Boris Ulasevich wrote: > AArch64 BarrierSetAssembler path assumes only FP/vector ideal regs reach the FP spill/restore encoding. With -XX:+UseFPUForSpilling Register Allocator may allocate scalar values in FP registers. When such values (Op_RegI/Op_RegN/Op_RegL/Op_RegP) hit `BarrierSetAssembler::encode_float_vector_register_size`, we trip ShouldNotReachHere in release build and **"unexpected ideal register"** assertion in debug build. > > Fix: teach the encoder to handle scalar ideal regs when they physically live in FP regs: > - treat Op_RegI / Op_RegN as 32-bit (single slot) - same class as Op_RegF > - treat Op_RegL / Op_RegP as 64-bit (two slots) - same class as Op_RegD > > Related: > - reproduced since #19746 > - spilling logic: > - #18967 > - #17977 > > Testing: tier1-3 with javaoptions -Xcomp -Xbatch -XX:+UseFPUForSpilling on AARCH Marked as reviewed by aph (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27350#pullrequestreview-3263280018 From bulasevich at openjdk.org Wed Sep 24 14:55:48 2025 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Wed, 24 Sep 2025 14:55:48 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v4] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Fri, 12 Sep 2025 16:36:56 GMT, Ruben wrote: >> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. >> >> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. > > Ruben has updated the pull request incrementally with two additional commits since the last revision: > > - Offset the deoptimization handler entry point > > Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722 > - Revert "Ensure stub code is not adjacent to a call" Hi. With current change I get a couple of new fails on ARM32: # Internal Error (jdk/src/hotspot/share/code/nmethod.cpp:669), pid=14516, tid=14517 # guarantee(pd != nullptr) failed: scope must be present Current thread (0xf561cda0): JavaThread "main" [_thread_in_Java, id=14517, stack(0xf57a8000,0xf57f8000) (320K)] Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x115d1d0] nmethod::scope_desc_at(unsigned char*)+0x11c (nmethod.cpp:669) V [libjvm.so+0x162dfd8] compiledVFrame::compiledVFrame(frame const*, RegisterMap const*, JavaThread*, nmethod*)+0x54 V [libjvm.so+0x161ed44] vframe::new_vframe(frame const*, RegisterMap const*, JavaThread*)+0x138 V [libjvm.so+0x80d150] Deoptimization::fetch_unroll_info_helper(JavaThread*, int)+0x290 V [libjvm.so+0x80e724] Deoptimization::fetch_unroll_info(JavaThread*, int)+0x98 Failing tests: - test/jdk/com/sun/jdi/PopAsynchronousTest.java - test/jdk/java/foreign/TestConcurrentClose.java - test/jdk/java/foreign/TestHandshake.java - test/jdk/java/lang/Math/WorstCaseTests.java - test/jdk/java/lang/StackWalker/LocalsAndOperands.java - test/jdk/java/lang/StringBuilder/CompactStringBuilder.java - test/jdk/java/lang/StringBuilder/RacingSBThreads.java - test/jdk/java/lang/Thread/virtual/MonitorEnterExit.java - test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java - test/jdk/java/lang/Thread/virtual/Parking.java - test/jdk/java/util/Arrays/HashCode.java - test/jdk/java/util/Calendar/RollDayOfWeekTest.java - test/jdk/java/util/concurrent/CompletableFuture/ThenComposeAsyncTest.java - test/jdk/java/util/Locale/AvailableLocalesTest.java - test/jdk/java/util/PluggableLocale/DateFormatProviderTest.java - test/jdk/java/util/ResourceBundle/TestBug4179766.java - test/jdk/java/util/stream/boottest/java.base/java/util/stream/LongNodeTest.java - test/jdk/java/util/stream/boottest/java.base/java/util/stream/NodeTest.java - test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/CollectorsTest.java - test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java - test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/mapMultiOpTest.java - test/jdk/jdk/classfile/CorpusTest.java - test/jdk/jdk/internal/jimage/JImageOpenTest.java - test/jdk/jdk/internal/reflect/CallerSensitive/CallerSensitiveFinder.java - test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3329064073 From luhenry at openjdk.org Wed Sep 24 15:33:53 2025 From: luhenry at openjdk.org (Ludovic Henry) Date: Wed, 24 Sep 2025 15:33:53 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v7] In-Reply-To: <6xTzmgEcZfGmJkvGt0yvg7iqc_LmuAZb4Y6m5IDUOX8=.518950d7-aadc-487a-a33d-66ba7f2209f4@github.com> References: <6xTzmgEcZfGmJkvGt0yvg7iqc_LmuAZb4Y6m5IDUOX8=.518950d7-aadc-487a-a33d-66ba7f2209f4@github.com> Message-ID: On Wed, 24 Sep 2025 13:29:41 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> >> Currently, the cpu features of riscv are stored in separate RVFeature subclasses. >> But to support the store/restore CPU features for aot in the future, we need to store the cpu features in a continuous memory. >> As the riscv extensions are introduced continuously, I think it's better to do it via an simple bitmap at the beginning. >> Currently, just suppose the non-extension features will not be stored in aot image, so I also split the extension and non-extenion features. When we implement the related aot feature in the short future, we can revisit the way of splitting the features. Currently, just change the storage way of cpu features, lay the foundation for future aot. >> >> Thanks > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > remove explicit cpu feature index in RV_EXT_FEATURE_FLAGS LGTM! src/hotspot/cpu/riscv/vm_version_riscv.hpp line 248: > 246: static NAME##RVExtFeatureValue NAME; \ > 247: > 248: RV_EXT_FEATURE_FLAGS(DECLARE_RV_EXT_FEATURE) Maybe an `#undef DECLARE_RV_EXT_FEATURE` after that line? src/hotspot/cpu/riscv/vm_version_riscv.hpp line 268: > 266: static NAME##RVNonExtFeatureValue NAME; \ > 267: > 268: RV_NON_EXT_FEATURE_FLAGS(DECLARE_RV_NON_EXT_FEATURE) It would be good to `#undef DECLARE_RV_NON_EXT_FEATURE` right after that. ------------- Marked as reviewed by luhenry (Committer). PR Review: https://git.openjdk.org/jdk/pull/27152#pullrequestreview-3263473326 PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2376188713 PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2376191865 From stuefe at openjdk.org Wed Sep 24 15:38:59 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 24 Sep 2025 15:38:59 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v5] In-Reply-To: References: Message-ID: <4wIXGf7_yCzJc-X1Hv6XNmCnxLfnub_veWXDUDO4MjE=.4f742937-398d-47d8-82f9-b77dae8a01f4@github.com> > On Linux, ASAN only shows some internal thread designation on reports, e.g. `T49`, which is useless. > > This patch adds the ability to see the real internal JVM thread names or user-supplied Java thread names in ASAN. This makes it possible to correlate ASAN reports with hs-err file reports (if ASAN is run with `halt_on_error=0` to give us a chance to get an hs-err file) or with a thread dump done beforehand. > > Note that it can only show up to 15 characters, though. Therefore, the patch tries to be smart about names that end in digits: such numbers are preserved such that the truncation happens in the middle of the name, e.g.: > > `"MyAllocationWorkerThread#4411"` -> `"MyAllocat..4411"` > > This latter improvement now also applies to thread names in gdb, since they are subject to the same limitation. > > For a detailed analysis of why the old version, using libpthread's `pthread_setname_np`, is not sufficient for thread names in ASAN, please see the issue description. > > ----- > > Some examples from ASAN report: > > Before: > > WRITE of size 8 at 0x7b749d2d9190 thread T49 > > > Now: > > WRITE of size 8 at 0x7bfc2f0d8380 thread T49 (MyThread#0) > > > > ==593899==ERROR: AddressSanitizer: attempting free .. in thread T76 (MyAllocati..29) Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: - correct comment - comments - Merge branch 'master' into JDK-8368124-Show-useful-thread-names-in-ASAN-reports - giving up on general string truncation function; adding gtest for set_thread_name - review feedback - simplify truncation function - windows build error - fix comments - remove comment duplicates - factor out string utility; provide tests - ... and 2 more: https://git.openjdk.org/jdk/compare/6dde79fa...996a4958 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27395/files - new: https://git.openjdk.org/jdk/pull/27395/files/62ab1b15..996a4958 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27395&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27395&range=03-04 Stats: 118555 lines in 833 files changed: 108232 ins; 6579 del; 3744 mod Patch: https://git.openjdk.org/jdk/pull/27395.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27395/head:pull/27395 PR: https://git.openjdk.org/jdk/pull/27395 From vaivanov at openjdk.org Wed Sep 24 15:41:48 2025 From: vaivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 24 Sep 2025 15:41:48 GMT Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays [v7] In-Reply-To: References: Message-ID: > On the SRF platform after PR https://github.com/openjdk/jdk/pull/26974 the fill intrinsics used by default. > For some types/ sizes scores for the ArrayFill test reports ~2x drop due to a lot of the 'MEM_UOPS_RETIRED.SPLIT_STORES' events. For example, the 'good' case for the ArraysFill.testCharFill with size=8195 reports numbers like > MEM_UOPS_RETIRED.SPLIT_LOADS | 22.6711 > MEM_UOPS_RETIRED.SPLIT_STORES | 4.0859 > while for 'bad' case these metrics are > MEM_UOPS_RETIRED.SPLIT_LOADS | 69.1785 > MEM_UOPS_RETIRED.SPLIT_STORES | 259200.3659 > > With alignment for the cache line size no score drops due to split_stores but small reduction may be reported for 'good' cases due to extra instructions in the intrinsic. The default options set was used for testing with '-XX:-OptimizeFill' for compiled code and with '-XX:+OptimizeFill' to force intrinsic. > SRF 6740E | Size | compiled code| patched intrinsic| patched/compiled > -- | -- | -- | -- | -- > ArraysFill.testByteFill | 16 | 152031.2 | 157001.2 | 1.03 > ArraysFill.testByteFill | 31 | 125795.9 | 177399.2 | 1.41 > ArraysFill.testByteFill | 250 | 57961.69 | 120981.9 | 2.09 > ArraysFill.testByteFill | 266 | 44900.15 | 147893.8 | 3.29 > ArraysFill.testByteFill | 511 | 61908.17 | 129830.1 | 2.10 > ArraysFill.testByteFill | 2047 | 32255.51 | 41986.6 | 1.30 > ArraysFill.testByteFill | 2048 | 31928.97 | 42154.3 | 1.32 > ArraysFill.testByteFill | 8195 | 10690.15 | 11036.3 | 1.03 > ArraysFill.testIntFill | 16 | 145030.7 | 318796.9 | 2.20 > ArraysFill.testIntFill | 31 | 134138.4 | 212487 | 1.58 > ArraysFill.testIntFill | 250 | 74179.23 | 79522.66 | 1.07 > ArraysFill.testIntFill | 266 | 68112.72 | 60116.49 | 0.88 > ArraysFill.testIntFill | 511 | 39693.28 | 36225.09 | 0.91 > ArraysFill.testIntFill | 2047 | 11504.14 | 10616.91 | 0.92 > ArraysFill.testIntFill | 2048 | 11244.71 | 10969.14 | 0.98 > ArraysFill.testIntFill | 8195 | 2751.289 | 2692.216 | 0.98 > ArraysFill.testLongFill | 16 | 212532.5 | 212526 | 1.00 > ArraysFill.testLongFill | 31 | 137432.4 | 137283.3 | 1.00 > ArraysFill.testLongFill | 250 | 43185 | 43159.78 | 1.00 > ArraysFill.testLongFill | 266 | 42172.22 | 42170.5 | 1.00 > ArraysFill.testLongFill | 511 | 23370.15 | 23370.86 | 1.00 > ArraysFill.testLongFill | 2047 | 6123.008 | 6122.73 | 1.00 > ArraysFill.testLongFill | 2048 | 5793.722 | 5792.855 | 1.00 > ArraysFill.testLongFill | 8195 | 616.552 | 616.585 | 1.00 > ArraysFill.testShortFill | 16 | 152088.6 | 265646.1 | 1.75 > ArraysFill.testShortFill | 31 | 137369.8 | 185596.4 | 1.35 > ArraysFill.testShortFill | 250 | 58872.03 | 9962... Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26747/files - new: https://git.openjdk.org/jdk/pull/26747/files/b20035dd..3957771b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26747&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26747&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26747.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26747/head:pull/26747 PR: https://git.openjdk.org/jdk/pull/26747 From mli at openjdk.org Wed Sep 24 15:54:59 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 24 Sep 2025 15:54:59 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v8] In-Reply-To: References: Message-ID: > Hi, > Can you help to review this patch? > > Currently, the cpu features of riscv are stored in separate RVFeature subclasses. > But to support the store/restore CPU features for aot in the future, we need to store the cpu features in a continuous memory. > As the riscv extensions are introduced continuously, I think it's better to do it via an simple bitmap at the beginning. > Currently, just suppose the non-extension features will not be stored in aot image, so I also split the extension and non-extenion features. When we implement the related aot feature in the short future, we can revisit the way of splitting the features. Currently, just change the storage way of cpu features, lay the foundation for future aot. > > Thanks Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: undef macros ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27152/files - new: https://git.openjdk.org/jdk/pull/27152/files/8a00f215..3131ab70 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27152&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27152&range=06-07 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27152.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27152/head:pull/27152 PR: https://git.openjdk.org/jdk/pull/27152 From mli at openjdk.org Wed Sep 24 15:55:02 2025 From: mli at openjdk.org (Hamlin Li) Date: Wed, 24 Sep 2025 15:55:02 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v7] In-Reply-To: References: <6xTzmgEcZfGmJkvGt0yvg7iqc_LmuAZb4Y6m5IDUOX8=.518950d7-aadc-487a-a33d-66ba7f2209f4@github.com> Message-ID: On Wed, 24 Sep 2025 15:30:31 GMT, Ludovic Henry wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> remove explicit cpu feature index in RV_EXT_FEATURE_FLAGS > > src/hotspot/cpu/riscv/vm_version_riscv.hpp line 248: > >> 246: static NAME##RVExtFeatureValue NAME; \ >> 247: >> 248: RV_EXT_FEATURE_FLAGS(DECLARE_RV_EXT_FEATURE) > > Maybe an `#undef DECLARE_RV_EXT_FEATURE` after that line? fixed > src/hotspot/cpu/riscv/vm_version_riscv.hpp line 268: > >> 266: static NAME##RVNonExtFeatureValue NAME; \ >> 267: >> 268: RV_NON_EXT_FEATURE_FLAGS(DECLARE_RV_NON_EXT_FEATURE) > > It would be good to `#undef DECLARE_RV_NON_EXT_FEATURE` right after that. fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2376269034 PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2376269184 From stuefe at openjdk.org Wed Sep 24 16:09:28 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 24 Sep 2025 16:09:28 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v5] In-Reply-To: <4wIXGf7_yCzJc-X1Hv6XNmCnxLfnub_veWXDUDO4MjE=.4f742937-398d-47d8-82f9-b77dae8a01f4@github.com> References: <4wIXGf7_yCzJc-X1Hv6XNmCnxLfnub_veWXDUDO4MjE=.4f742937-398d-47d8-82f9-b77dae8a01f4@github.com> Message-ID: On Wed, 24 Sep 2025 15:38:59 GMT, Thomas Stuefe wrote: >> On Linux, ASAN only shows some internal thread designation on reports, e.g. `T49`, which is useless. >> >> This patch adds the ability to see the real internal JVM thread names or user-supplied Java thread names in ASAN. This makes it possible to correlate ASAN reports with hs-err file reports (if ASAN is run with `halt_on_error=0` to give us a chance to get an hs-err file) or with a thread dump done beforehand. >> >> Note that it can only show up to 15 characters, though. Therefore, the patch tries to be smart about names that end in digits: such numbers are preserved such that the truncation happens in the middle of the name, e.g.: >> >> `"MyAllocationWorkerThread#4411"` -> `"MyAllocat..4411"` >> >> This latter improvement now also applies to thread names in gdb, since they are subject to the same limitation. >> >> For a detailed analysis of why the old version, using libpthread's `pthread_setname_np`, is not sufficient for thread names in ASAN, please see the issue description. >> >> ----- >> >> Some examples from ASAN report: >> >> Before: >> >> WRITE of size 8 at 0x7b749d2d9190 thread T49 >> >> >> Now: >> >> WRITE of size 8 at 0x7bfc2f0d8380 thread T49 (MyThread#0) >> >> >> >> ==593899==ERROR: AddressSanitizer: attempting free .. in thread T76 (MyAllocati..29) > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: > > - correct comment > - comments > - Merge branch 'master' into JDK-8368124-Show-useful-thread-names-in-ASAN-reports > - giving up on general string truncation function; adding gtest for set_thread_name > - review feedback > - simplify truncation function > - windows build error > - fix comments > - remove comment duplicates > - factor out string utility; provide tests > - ... and 2 more: https://git.openjdk.org/jdk/compare/76a5972d...996a4958 @dholmes-ora I gave up on the idea of a generalized middle-truncation function and went with a solution just for this case. This is a bit simpler, hope you like this better. I added new tests for set_native_thread_name gtests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27395#issuecomment-3329675992 From stuefe at openjdk.org Wed Sep 24 16:09:24 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 24 Sep 2025 16:09:24 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v6] In-Reply-To: References: Message-ID: > On Linux, ASAN only shows some internal thread designation on reports, e.g. `T49`, which is useless. > > This patch adds the ability to see the real internal JVM thread names or user-supplied Java thread names in ASAN. This makes it possible to correlate ASAN reports with hs-err file reports (if ASAN is run with `halt_on_error=0` to give us a chance to get an hs-err file) or with a thread dump done beforehand. > > Note that it can only show up to 15 characters, though. Therefore, the patch tries to be smart about names that end in digits: such numbers are preserved such that the truncation happens in the middle of the name, e.g.: > > `"MyAllocationWorkerThread#4411"` -> `"MyAllocat..4411"` > > This latter improvement now also applies to thread names in gdb, since they are subject to the same limitation. > > For a detailed analysis of why the old version, using libpthread's `pthread_setname_np`, is not sufficient for thread names in ASAN, please see the issue description. > > ----- > > Some examples from ASAN report: > > Before: > > WRITE of size 8 at 0x7b749d2d9190 thread T49 > > > Now: > > WRITE of size 8 at 0x7bfc2f0d8380 thread T49 (MyThread#0) > > > > ==593899==ERROR: AddressSanitizer: attempting free .. in thread T76 (MyAllocati..29) Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: some more tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27395/files - new: https://git.openjdk.org/jdk/pull/27395/files/996a4958..7c033ad7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27395&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27395&range=04-05 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27395.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27395/head:pull/27395 PR: https://git.openjdk.org/jdk/pull/27395 From tanksherman27 at gmail.com Wed Sep 24 17:08:34 2025 From: tanksherman27 at gmail.com (Julian Waters) Date: Thu, 25 Sep 2025 01:08:34 +0800 Subject: Problems with LTO for HotSpot Message-ID: Hi all, Recently I've been picking up and resuming work on making LTO viable for HotSpot. The aim is to have LTO as a working option available so the benefits of enhanced optimization can be enjoyed by running Java code, though making LTO the default is not really a goal, at least not yet. The work has been going on decently well so far, but while working on it, there have been 2 rather longstanding problems I haven't really been able to solve. The first is related to https://github.com/openjdk/jdk/pull/22864 switching os::current_stack_pointer() to using runtime assembly, but we can visit that later. The bigger issue is related to the flatten attribute on the gcc compiler. In short, some G1 code (More specifically void G1ParScanThreadState::trim_queue_to_threshold(uint threshold), void G1ParScanThreadState::steal_and_trim_queue(G1ScannerTasksQueueSet* task_queues) and oop G1ParScanThreadState::copy_to_survivor_space(G1HeapRegionAttr region_attr, oop old, markWord old_mark)) is marked as flatten, which causes gcc to inline all calls inside those methods. This normally would be fine since the compilation unit boundary prevents inlining from across source files, but when LTO is active, the method bodies from other compilation units become available, and gcc then goes on a rampage, mass inlining everything it can find until there is nothing left to inline. On top of causing the JVM inflate to at least 60MB in the best case, it also causes build problems, notably JDK-8343698 and (suspected) JDK-8334616 and in general LTO is extremely slow, likely due to this problem. It would seem that we'd need to create NOINLINE wrappers for methods which are called by the flattened code but are not defined in the same source file (g1ParScanThreadState.cpp). Problematically however, the call hierarchy for these 3 methods is downright *massive* since these methods are absolute monsters. This makes trying to find which methods these 3 call very tedious and error prone. After months and many different approaches, all of which have failed, I'm still no closer to finding out which code needs NOINLINE wrappers to prevent cross compilation unit inlining. Might there be a better way to figure out which methods are called from outside the g1ParScanThreadState.cpp source file than my current approach of manually looking through an IDE (Since all automated tools have failed in one way or another)? This is a very big blocker for working LTO with HotSpot, once I manage to get this and the stack pointer issue solved I believe I'll (hopefully) be able to get working LTO into the JDK soon. best regards, Julian From vlivanov at openjdk.org Wed Sep 24 17:39:35 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 24 Sep 2025 17:39:35 GMT Subject: RFR: 8368303: AlwaysAtomicAccesses is excessively strict In-Reply-To: References: Message-ID: <3EIT8mAB0k4dSVjfJzJL2k6B_6rOeQNPExWGWUwXeWc=.6f94a495-ebad-4f88-b37c-86e2fcb8f7fc@github.com> On Mon, 22 Sep 2025 16:51:08 GMT, Andrew Haley wrote: > In C1, the experimental flag `AlwaysAtomicAccesses` treats accesses to all fields as if they were volatile fields. This is correct but excessive: we only need single-copy atomicity to satisfy `AlwaysAtomicAccesses`. > > We need this in order to allow progress on JDK-8365147. src/hotspot/share/gc/shared/c1/barrierSetC1.cpp line 43: > 41: // Return true iff an access to bt is single-copy atomic. > 42: static bool access_is_atomic(BasicType bt) { > 43: #ifdef CPU_MULTI_COPY_ATOMIC Why do you require `CPU_MULTI_COPY_ATOMIC`? Why can't you unconditionally treat all sub-word/word accesses (naturally aligned) as atomic instead? Isn't that what JVM already guarantees? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27432#discussion_r2376543756 From iveresov at openjdk.org Wed Sep 24 17:54:32 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Wed, 24 Sep 2025 17:54:32 GMT Subject: RFR: 8366948: AOT cache creation crashes when iterating training data [v2] In-Reply-To: References: Message-ID: > I forgot a lock around `CTD::_ci_records`. It also has to respect the snapshotting protocol. Testing is good. Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: Make DepList more defensive against non-MT-safe use ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27461/files - new: https://git.openjdk.org/jdk/pull/27461/files/6fc9d856..bb3add97 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27461&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27461&range=00-01 Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27461/head:pull/27461 PR: https://git.openjdk.org/jdk/pull/27461 From iveresov at openjdk.org Wed Sep 24 17:54:34 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Wed, 24 Sep 2025 17:54:34 GMT Subject: RFR: 8366948: AOT cache creation crashes when iterating training data [v2] In-Reply-To: References: Message-ID: <5WaTBDB40ZTa7_Oc0YczxspLCAL18vNr0sZEGYNgFyc=.882cfc59-d973-43c4-80db-2ae705a954b5@github.com> On Wed, 24 Sep 2025 02:18:09 GMT, Ioi Lam wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Make DepList more defensive against non-MT-safe use > > src/hotspot/share/oops/trainingData.hpp line 606: > >> 604: TrainingDataLocker l; >> 605: if (l.can_add()) { >> 606: _data.append_if_missing(Record(result, ArgumentsType(args...))); > > This calls `DepList::append_if_missing()`. Should we add an `TrainingDataLocker::assert_locked()` in that function? I see many functions in this header file have this assert. This is a very good idea. I sprinkled it around the public DepList functions and retested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27461#discussion_r2376590553 From erikj at openjdk.org Wed Sep 24 18:18:55 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 24 Sep 2025 18:18:55 GMT Subject: RFR: 8368250: [AIX] now ubsan vptr check is also possible (follow up of JDK-8354686) In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 13:23:00 GMT, Joachim Kern wrote: > After [JDK-8354686](https://bugs.openjdk.org/browse/JDK-8354686) the ubsan vptr checks still did not work. We finally found out, that they only work, if all linkage units are linked with the C++ compiler frontend as linker, especially the main executables (java, javac, ...) which are linked with the C compiler frontend. > So for a ubsan enabled build on AIX we let everything link with the C++ compiler frontend. > Background: The C++ compiler frontend inherently adds special static libraries which the C compiler does not. This results in missing symbols when trying to start a program and its shared libraries, when they were linked in mixed mode. make/autoconf/jdk-options.m4 line 570: > 568: # In the ubsan case we have to link every binary with the C++-compiler as linker, because inherently > 569: # the C-Compiler and the C++-compiler used as linker provide a different set of ubsan exports. > 570: # Linkung an executable with the C-compiler and one of its shared libraries with the C++-compiler Suggestion: # Linking an executable with the C-compiler and one of its shared libraries with the C++-compiler make/autoconf/jdk-options.m4 line 575: > 573: UBSAN_CFLAGS="$UBSAN_CFLAGS -DLLVM_SYMBOLIZER=$(dirname $(dirname $CC))/tools/ibm-llvm-symbolizer" > 574: UBSAN_LDFLAGS="$UBSAN_LDFLAGS -Wl,-bbigtoc" > 575: LD="$LDCXX" Indentation for blocks should be 2 spaces. https://openjdk.org/groups/build/doc/code-conventions.html Suggestion: UBSAN_CFLAGS="$UBSAN_CFLAGS -DLLVM_SYMBOLIZER=$(dirname $(dirname $CC))/tools/ibm-llvm-symbolizer" UBSAN_LDFLAGS="$UBSAN_LDFLAGS -Wl,-bbigtoc" LD="$LDCXX" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27468#discussion_r2376669448 PR Review Comment: https://git.openjdk.org/jdk/pull/27468#discussion_r2376675889 From vlivanov at openjdk.org Wed Sep 24 18:24:55 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 24 Sep 2025 18:24:55 GMT Subject: RFR: 8366948: AOT cache creation crashes when iterating training data [v2] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 17:54:32 GMT, Igor Veresov wrote: >> I forgot a lock around `CTD::_ci_records`. It also has to respect the snapshotting protocol. Testing is good. > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Make DepList more defensive against non-MT-safe use Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27461#pullrequestreview-3264154118 From lucy at openjdk.org Wed Sep 24 19:23:11 2025 From: lucy at openjdk.org (Lutz Schmidt) Date: Wed, 24 Sep 2025 19:23:11 GMT Subject: RFR: 8368518: [s390x] test failure with failed: wrong size of mach node In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 11:11:12 GMT, Amit Kumar wrote: > Fixes the test failures. Tested tier1 with release and fastdebug vm. > > Moves one comment related to INTPRESSURE, a leftover from previous change. LGTM ------------- Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27465#pullrequestreview-3264350782 From dlong at openjdk.org Wed Sep 24 19:35:19 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 24 Sep 2025 19:35:19 GMT Subject: RFR: 8368303: AlwaysAtomicAccesses is excessively strict In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 16:51:08 GMT, Andrew Haley wrote: > In C1, the experimental flag `AlwaysAtomicAccesses` treats accesses to all fields as if they were volatile fields. This is correct but excessive: we only need single-copy atomicity to satisfy `AlwaysAtomicAccesses`. > > We need this in order to allow progress on JDK-8365147. It does seem like access_is_atomic() could be moved to platform-specific code, but which platforms would need a different implementation? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27432#issuecomment-3330373806 From liach at openjdk.org Wed Sep 24 20:55:17 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 24 Sep 2025 20:55:17 GMT Subject: RFR: 8368174: Proactive initialization of @AOTSafeClassInitializer classes [v2] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 22:10:53 GMT, Ioi Lam wrote: >> This is an alternative to https://github.com/openjdk/jdk/pull/27024. Thanks to @ashu-mehra for the suggestion. >> >> ### Background: >> >> The AOT Assembly Phase is in essence a small Java program that executes a limited set of Java bytecodes. This program bootstraps the module system, loads classes, and performs certain ahead-of-time optimizations such as resolving `invokedynamic` call sites. >> >> As a side effect of Java program execution, a small set of Java classes are initialized in the Assembly Phase. >> >> Since [JDK-8360163](https://bugs.openjdk.org/browse/JDK-8360163), if a class `X` is annotated with `@AOTSafeClassInitializer` *and* is initialized in the Assembly Phase, then `X` will be stored in the AOT cache in the "initialized" state. When the AOT cache is used in the Production Run, `X::` will not be executed, and the static variables of `X` will be available upon JVM bootstrap. >> >> ### Problem: >> >> The Assembly Phase doesn't touch many classes that may benefit from `@AOTSafeClassInitializer`. For example, `jdk.internal.math.MathUtils::` creates a few large tables. Caching `MathUtils` in the "initialized" state will improve start-up time. However, since no bytecodes executed by the Assembly Phase use `MathUtils`. it will not be initialized. >> >> ### Fix: >> >> If a class `X` has the `@AOTSafeClassInitializer` annotation *and* was initialized in the AOT Training Run, the JVM will proactively initialize `X` in the Assembly Phase. This will ensure that `X` will be cached in the "initialized" state. >> >> As a proof of concept, `@AOTSafeClassInitializer` is added to `MathUtils`. `@AOTSafeClassInitializer` will be added to more classes in future RFEs. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Exclude new test from hotspot_aot_classlinking and hotspot_appcds_dynamic test groups > - @adinn and @liach comments > - Merge branch 'master' into 8368174-proactive-init-aot-safe-class-initializer > - updated javadoc for AOTSafeClassInitializer.java > - Fix > - imported Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27402#pullrequestreview-3264702460 From sviswanathan at openjdk.org Wed Sep 24 21:00:33 2025 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Wed, 24 Sep 2025 21:00:33 GMT Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays [v7] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 15:41:48 GMT, Vladimir Ivanov wrote: >> On the SRF platform after PR https://github.com/openjdk/jdk/pull/26974 the fill intrinsics used by default. >> For some types/ sizes scores for the ArrayFill test reports ~2x drop due to a lot of the 'MEM_UOPS_RETIRED.SPLIT_STORES' events. For example, the 'good' case for the ArraysFill.testCharFill with size=8195 reports numbers like >> MEM_UOPS_RETIRED.SPLIT_LOADS | 22.6711 >> MEM_UOPS_RETIRED.SPLIT_STORES | 4.0859 >> while for 'bad' case these metrics are >> MEM_UOPS_RETIRED.SPLIT_LOADS | 69.1785 >> MEM_UOPS_RETIRED.SPLIT_STORES | 259200.3659 >> >> With alignment for the cache line size no score drops due to split_stores but small reduction may be reported for 'good' cases due to extra instructions in the intrinsic. The default options set was used for testing with '-XX:-OptimizeFill' for compiled code and with '-XX:+OptimizeFill' to force intrinsic. >> SRF 6740E | Size | compiled code| patched intrinsic| patched/compiled >> -- | -- | -- | -- | -- >> ArraysFill.testByteFill | 16 | 152031.2 | 157001.2 | 1.03 >> ArraysFill.testByteFill | 31 | 125795.9 | 177399.2 | 1.41 >> ArraysFill.testByteFill | 250 | 57961.69 | 120981.9 | 2.09 >> ArraysFill.testByteFill | 266 | 44900.15 | 147893.8 | 3.29 >> ArraysFill.testByteFill | 511 | 61908.17 | 129830.1 | 2.10 >> ArraysFill.testByteFill | 2047 | 32255.51 | 41986.6 | 1.30 >> ArraysFill.testByteFill | 2048 | 31928.97 | 42154.3 | 1.32 >> ArraysFill.testByteFill | 8195 | 10690.15 | 11036.3 | 1.03 >> ArraysFill.testIntFill | 16 | 145030.7 | 318796.9 | 2.20 >> ArraysFill.testIntFill | 31 | 134138.4 | 212487 | 1.58 >> ArraysFill.testIntFill | 250 | 74179.23 | 79522.66 | 1.07 >> ArraysFill.testIntFill | 266 | 68112.72 | 60116.49 | 0.88 >> ArraysFill.testIntFill | 511 | 39693.28 | 36225.09 | 0.91 >> ArraysFill.testIntFill | 2047 | 11504.14 | 10616.91 | 0.92 >> ArraysFill.testIntFill | 2048 | 11244.71 | 10969.14 | 0.98 >> ArraysFill.testIntFill | 8195 | 2751.289 | 2692.216 | 0.98 >> ArraysFill.testLongFill | 16 | 212532.5 | 212526 | 1.00 >> ArraysFill.testLongFill | 31 | 137432.4 | 137283.3 | 1.00 >> ArraysFill.testLongFill | 250 | 43185 | 43159.78 | 1.00 >> ArraysFill.testLongFill | 266 | 42172.22 | 42170.5 | 1.00 >> ArraysFill.testLongFill | 511 | 23370.15 | 23370.86 | 1.00 >> ArraysFill.testLongFill | 2047 | 6123.008 | 6122.73 | 1.00 >> ArraysFill.testLongFill | 2048 | 5793.722 | 5792.855 | 1.00 >> ArraysFill.testLongFill | 8195 | 616.552 | 616.585 | 1.00 >> ArraysFill.testShortFill | 16 | 152088.6 | 265646.1 | 1.75 >> ArraysFill.testShortFill | 31 | 1... > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays Looks good to me. ------------- Marked as reviewed by sviswanathan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26747#pullrequestreview-3264716595 From iklam at openjdk.org Wed Sep 24 21:01:57 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 24 Sep 2025 21:01:57 GMT Subject: RFR: 8368174: Proactive initialization of @AOTSafeClassInitializer classes [v2] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 09:38:16 GMT, Andrew Dinn wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Exclude new test from hotspot_aot_classlinking and hotspot_appcds_dynamic test groups >> - @adinn and @liach comments >> - Merge branch 'master' into 8368174-proactive-init-aot-safe-class-initializer >> - updated javadoc for AOTSafeClassInitializer.java >> - Fix >> - imported > > This is much simpler and clearer than the previous version making it easier for non-Leyden devs to understand what they are buying into when they use the annotation. Nice work @ashu-mehra and @iklam. > I made a few suggestions to clarify comments which you are free to adopt or drop as you see fit. Otherwise looks good to go. Thanks @adinn @liach @ashu-mehra for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/27402#issuecomment-3330687291 From iklam at openjdk.org Wed Sep 24 21:01:59 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 24 Sep 2025 21:01:59 GMT Subject: Integrated: 8368174: Proactive initialization of @AOTSafeClassInitializer classes In-Reply-To: References: Message-ID: On Sat, 20 Sep 2025 02:57:50 GMT, Ioi Lam wrote: > This is an alternative to https://github.com/openjdk/jdk/pull/27024. Thanks to @ashu-mehra for the suggestion. > > ### Background: > > The AOT Assembly Phase is in essence a small Java program that executes a limited set of Java bytecodes. This program bootstraps the module system, loads classes, and performs certain ahead-of-time optimizations such as resolving `invokedynamic` call sites. > > As a side effect of Java program execution, a small set of Java classes are initialized in the Assembly Phase. > > Since [JDK-8360163](https://bugs.openjdk.org/browse/JDK-8360163), if a class `X` is annotated with `@AOTSafeClassInitializer` *and* is initialized in the Assembly Phase, then `X` will be stored in the AOT cache in the "initialized" state. When the AOT cache is used in the Production Run, `X::` will not be executed, and the static variables of `X` will be available upon JVM bootstrap. > > ### Problem: > > The Assembly Phase doesn't touch many classes that may benefit from `@AOTSafeClassInitializer`. For example, `jdk.internal.math.MathUtils::` creates a few large tables. Caching `MathUtils` in the "initialized" state will improve start-up time. However, since no bytecodes executed by the Assembly Phase use `MathUtils`. it will not be initialized. > > ### Fix: > > If a class `X` has the `@AOTSafeClassInitializer` annotation *and* was initialized in the AOT Training Run, the JVM will proactively initialize `X` in the Assembly Phase. This will ensure that `X` will be cached in the "initialized" state. > > As a proof of concept, `@AOTSafeClassInitializer` is added to `MathUtils`. `@AOTSafeClassInitializer` will be added to more classes in future RFEs. This pull request has now been integrated. Changeset: 17accf4a Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/17accf4a06fe654fef6db8dbd0dcd3411729316f Stats: 289 lines in 11 files changed: 198 ins; 47 del; 44 mod 8368174: Proactive initialization of @AOTSafeClassInitializer classes Reviewed-by: liach, adinn, asmehra ------------- PR: https://git.openjdk.org/jdk/pull/27402 From dlong at openjdk.org Wed Sep 24 21:25:08 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 24 Sep 2025 21:25:08 GMT Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v4] In-Reply-To: References: Message-ID: > 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 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 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27059/files - new: https://git.openjdk.org/jdk/pull/27059/files/eac482a5..a4f2383c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=02-03 Stats: 179654 lines in 2239 files changed: 141573 ins; 24044 del; 14037 mod Patch: https://git.openjdk.org/jdk/pull/27059.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27059/head:pull/27059 PR: https://git.openjdk.org/jdk/pull/27059 From dlong at openjdk.org Wed Sep 24 21:36:30 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 24 Sep 2025 21:36:30 GMT Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v5] In-Reply-To: References: Message-ID: > 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: copyright year update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27059/files - new: https://git.openjdk.org/jdk/pull/27059/files/a4f2383c..81d56860 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=03-04 Stats: 10 lines in 10 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/27059.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27059/head:pull/27059 PR: https://git.openjdk.org/jdk/pull/27059 From dlong at openjdk.org Wed Sep 24 21:40:44 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 24 Sep 2025 21:40:44 GMT Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3] In-Reply-To: References: <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com> Message-ID: On Wed, 24 Sep 2025 11:10:22 GMT, Manuel H?ssig wrote: >> Dean Long has updated the pull request incrementally with three additional commits since the last revision: >> >> - revert whitespace change >> - undo debug changes >> - cleanup > > src/hotspot/cpu/arm/arm_32.ad line 436: > >> 434: bool far = (_method == nullptr) ? maybe_far_call(this) : !cache_reachable(); >> 435: return (far ? 3 : 1) * NativeInstruction::instruction_size; >> 436: } > > Why do we still need the `instruction_size` offset? Are all static java calls now method handles? The offset is in bytes, so we still need to convert from instruction count to bytes with instruction_size. This change adjusts for the fact that method handle calls have 1 fewer instruction on arm32 now, because preserve_SP was removed. > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java line 1: > >> 1: /* > > Please update the copyright year. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2377135523 PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2377136479 From sspitsyn at openjdk.org Wed Sep 24 21:41:43 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 24 Sep 2025 21:41:43 GMT Subject: RFR: 8368159: Significant performance overhead when started with jdwp agent and unattached debugger [v2] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 05:02:01 GMT, Chris Plummer wrote: > But if we are not in interp_only mode isn't it already invalidated? It does not need to be invalidated if not in `interp_only` mode. The issue I see is with the test `test/hotspot/jtreg/serviceability/jvmti/vthread/ContStackDepthTest` only which is for plain Continuations. Otherwise, the `invalidate_jvmti_stack()` would not be needed. It plays as a workaround to make this test to pass. It seems there is a bug related to plain Continuation lurking somewhere. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27403#discussion_r2377137978 From dlong at openjdk.org Wed Sep 24 21:47:29 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 24 Sep 2025 21:47:29 GMT Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v6] In-Reply-To: References: Message-ID: <1ChaRPjjHEx-yM_RJR8JDfbq3v8mhNkkM4WomJstN_o=.ac7eeeed-250e-4511-bdeb-ae720aa5cc20@github.com> > 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: copyright year update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27059/files - new: https://git.openjdk.org/jdk/pull/27059/files/81d56860..10668bd7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27059.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27059/head:pull/27059 PR: https://git.openjdk.org/jdk/pull/27059 From kbarrett at openjdk.org Wed Sep 24 21:55:48 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 24 Sep 2025 21:55:48 GMT Subject: RFR: 8367013: Add Atomic to package/replace idiom of volatile var plus AtomicAccess:: operations In-Reply-To: <3nRiWxbET2Bf7i1VNfWGH12omfPxcTaC6W2UhLVDDH0=.0c34542e-e08b-42e3-b35b-ae98c46abe0a@github.com> References: <3nRiWxbET2Bf7i1VNfWGH12omfPxcTaC6W2UhLVDDH0=.0c34542e-e08b-42e3-b35b-ae98c46abe0a@github.com> Message-ID: On Wed, 24 Sep 2025 14:36:25 GMT, Stefan Karlsson wrote: > I wonder if this is going to be problematic with other editors or if this is just a problem with Eclipse. I can see how this code might be fairly opaque to an IDE. There's a different way to structure things (leaning on SFINAE rather that constexpr-if and decltype) that might be more IDE friendly, maybe? Though it seems like a template type whose interface is dependent might be pretty hard for IDE code completion. But that's just a guess, and not a well-informed one at that. I'll try putting together an alternative branch tonight for you to try out. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27462#issuecomment-3330828460 From iklam at openjdk.org Wed Sep 24 22:02:37 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 24 Sep 2025 22:02:37 GMT Subject: RFR: 8366948: AOT cache creation crashes when iterating training data [v2] In-Reply-To: References: Message-ID: <-3wYuu2XaNJGHc4Yq3xtokiYhlr2AtzEnuMI-kmKL4M=.f57d0a95-8f5c-4eb2-855f-13ed1709f5e5@github.com> On Wed, 24 Sep 2025 17:54:32 GMT, Igor Veresov wrote: >> I forgot a lock around `CTD::_ci_records`. It also has to respect the snapshotting protocol. Testing is good. > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Make DepList more defensive against non-MT-safe use Marked as reviewed by iklam (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27461#pullrequestreview-3264870849 From cjplummer at openjdk.org Wed Sep 24 22:09:31 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 24 Sep 2025 22:09:31 GMT Subject: RFR: 8368159: Significant performance overhead when started with jdwp agent and unattached debugger [v2] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 21:38:58 GMT, Serguei Spitsyn wrote: >>> The interp_only check is needed for optimization to avoid a performance overhead of current stack depth invalidation. >> >> But if we are not in interp_only mode isn't it already invalidated? > >> But if we are not in interp_only mode isn't it already invalidated? > > It does not need to be invalidated if not in `interp_only` mode as it should not be used there or has to be explicitly invalidated exactly where it is needed. The issue I see is only with the test `test/hotspot/jtreg/serviceability/jvmti/vthread/ContStackDepthTest` which is for plain Continuations. Otherwise, the `invalidate_jvmti_stack()` would not be needed. It plays as a workaround to make this test to pass. It seems there is a bug related to plain Continuations lurking somewhere. My point is we could just unconditionally invalidate. It would do no harm. It would not be invalidating a curr stack depth that could later be used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27403#discussion_r2377189171 From kim.barrett at oracle.com Wed Sep 24 22:16:27 2025 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 24 Sep 2025 18:16:27 -0400 Subject: Problems with LTO for HotSpot In-Reply-To: References: Message-ID: <736d1d36-bb0e-4661-987c-12bf05bebe54@oracle.com> On 9/24/25 1:08 PM, Julian Waters wrote: > Recently I've been picking up and resuming work on making LTO viable > for HotSpot. [...] The bigger issue is related to the flatten attribute > on the gcc compiler. In short, some G1 code (More specifically void > G1ParScanThreadState::trim_queue_to_threshold(uint threshold), void > G1ParScanThreadState::steal_and_trim_queue(G1ScannerTasksQueueSet* > task_queues) and oop > G1ParScanThreadState::copy_to_survivor_space(G1HeapRegionAttr > region_attr, oop old, markWord old_mark)) is marked as flatten The flatten attribute is being used there because the code in question has been found to be very (performance) sensitive to compiler decisions to sometimes not inline something. So apply the big hammer. (Note that some critical path stuff is conditionally noinline in debug builds, because otherwise such builds were also running into excessive inlining, leading to things like "conditional branch out of range" failures.) Using flatten is certainly leading to more inlining than actually needed. An alternative to using flatten would be to try to mark all the critical path stuff always_inline. I found that pretty hard to do, and also brittle, much like Julian is encountering with the flatten + noinline approach. But it might be that some judicious always_inline + noinline + either (but not both) flatten or LTO might work. That was the direction I was going to explore, but haven't found any spare 'tuits to allocate in that direction. Supporting LTO just hasn't percolated up the priority list here. From dlong at openjdk.org Wed Sep 24 22:19:03 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 24 Sep 2025 22:19:03 GMT Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3] In-Reply-To: References: <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com> Message-ID: On Wed, 24 Sep 2025 11:14:01 GMT, Manuel H?ssig wrote: >> Dean Long has updated the pull request incrementally with three additional commits since the last revision: >> >> - revert whitespace change >> - undo debug changes >> - cleanup > > src/hotspot/cpu/arm/frame_arm.cpp line 365: > >> 363: DEBUG_ONLY(verify_deopt_original_pc(sender_nm, _unextended_sp)); >> 364: } >> 365: } > > All of this could be `NOT_PRODUCT` and the method `const` if I did not miss any side effects. Right, there is no adjustment anymore on any platform. I think this function and verify_deopt_original_pc only ever existed to support code that is now getting removed. So I could change the name to verify_unextended_sp() and make it const, but it might make more sense to remove both this function and verify_deopt_original_pc now. What do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2377202692 From iveresov at openjdk.org Wed Sep 24 23:10:20 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Wed, 24 Sep 2025 23:10:20 GMT Subject: RFR: 8366948: AOT cache creation crashes when iterating training data [v2] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 17:54:32 GMT, Igor Veresov wrote: >> I forgot a lock around `CTD::_ci_records`. It also has to respect the snapshotting protocol. Testing is good. > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Make DepList more defensive against non-MT-safe use Thanks guys! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27461#issuecomment-3330974816 From iveresov at openjdk.org Wed Sep 24 23:10:22 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Wed, 24 Sep 2025 23:10:22 GMT Subject: Integrated: 8366948: AOT cache creation crashes when iterating training data In-Reply-To: References: Message-ID: <65UQXq0uQGgMjODFuTSXdwdixb7yPqu6torTFlJ_IeI=.bb166836-cc5a-4cd4-9f53-7618462ab7e2@github.com> On Wed, 24 Sep 2025 01:18:54 GMT, Igor Veresov wrote: > I forgot a lock around `CTD::_ci_records`. It also has to respect the snapshotting protocol. Testing is good. This pull request has now been integrated. Changeset: 2aafda19 Author: Igor Veresov URL: https://git.openjdk.org/jdk/commit/2aafda1968f3fc8902f7d146a1cba72998aeb976 Stats: 17 lines in 1 file changed: 15 ins; 0 del; 2 mod 8366948: AOT cache creation crashes when iterating training data Reviewed-by: vlivanov, iklam ------------- PR: https://git.openjdk.org/jdk/pull/27461 From duke at openjdk.org Wed Sep 24 23:13:30 2025 From: duke at openjdk.org (Ruben) Date: Wed, 24 Sep 2025 23:13:30 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v4] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Wed, 24 Sep 2025 09:13:44 GMT, Martin Doerr wrote: >> Ruben has updated the pull request incrementally with two additional commits since the last revision: >> >> - Offset the deoptimization handler entry point >> >> Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722 >> - Revert "Ensure stub code is not adjacent to a call" > > Right, it works after adapting C1 deopt handler (see below). So, you convinced me that your new solution is better. Please don't add Copyright headers everywhere. Arm has contributed less than 1% of ppc.ad. I don't think that justifies a Copyright for the whole file. We don't want everyone's Copyright in every file. > > Thanks a lot for debugging the issue! > > > diff --git a/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp b/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp > index 3ca75305eca..fe735c8831b 100644 > --- a/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp > +++ b/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp > @@ -263,13 +263,17 @@ int LIR_Assembler::emit_deopt_handler() { > return -1; > } > > - int offset = code_offset(); > + Label start; > + > + __ bind(start); > __ bl64_patchable(SharedRuntime::deopt_blob()->unpack(), relocInfo::runtime_call_type); > + int entry_point = __ offset(); > + __ b(start); > > - guarantee(code_offset() - offset <= deopt_handler_size(), "overflow"); > + guarantee(code_offset() - entry_point <= deopt_handler_size(), "overflow"); > __ end_a_stub(); > > - return offset; > + return entry_point; > } > > > diff --git a/src/hotspot/cpu/ppc/ppc.ad b/src/hotspot/cpu/ppc/ppc.ad > index 1f6819c4bf6..9473dd3d57b 100644 > --- a/src/hotspot/cpu/ppc/ppc.ad > +++ b/src/hotspot/cpu/ppc/ppc.ad > @@ -1,7 +1,6 @@ > // > // Copyright (c) 2011, 2025, Oracle and/or its affiliates. All rights reserved. > // Copyright (c) 2012, 2025 SAP SE. All rights reserved. > -// Copyright 2025 Arm Limited and/or its affiliates. > // DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > // > // This code is free software; you can redistribute it and/or modify it > diff --git a/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp b/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp > index ced1b38541b..3d037540766 100644 > --- a/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp > +++ b/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp > @@ -2965,7 +2965,6 @@ void SharedRuntime::generate_deopt_blob() { > // The return_pc has been stored in the frame of the deoptee and > // will replace the address of the deopt_handler in the call > // to Deoptimization::fetch_unroll_info below. > - const int return_pc_adjustment_no_exception = -MacroAssembler::bl64_patchable_size; > > // Push the "unpack frame" > // Save everything in sight. Thank you @TheRealMDoerr, @offamitkumar, @bulasevich, @adinn, I think, in my local version the `nmethod::scope_desc_at` issues are solved. I'm planning to share it soon - after some more testing. @TheRealMDoerr, I will update the patch as you suggested. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3330979850 From iklam at openjdk.org Wed Sep 24 23:22:54 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 24 Sep 2025 23:22:54 GMT Subject: RFR: 8367910: Reduce warnings about unsupported classes in AOT cache creation Message-ID: Currently AOT cache creation may print lots of warning (depending on the actions performed by the application's training run). Most of these warnings are harmless and are caused by JVM limitations; there's nothing that the user can do about them: [1.096s][warning][aot] Skipping jdk/internal/event/Event: JFR event class [1.096s][warning][aot] Skipping jdk/jfr/Event: JFR event class [1.099s][warning][aot] Skipping jdk/proxy1/$Proxy14: Unsupported location [1.100s][warning][aot] Skipping jdk/proxy1/$Proxy12: Unsupported location [1.100s][warning][aot] Skipping jdk/proxy1/$Proxy11: Unsupported location This PR moves most of these warnings to the "info" level. The only messages that are still logged in the "warning" levels are: - class is in an error state - class failed verification These could indicate issues with the application so it's good to let the user know. ------------- Commit messages: - 8367910: Reduce warnings about unsupported classes in AOT cache creation Changes: https://git.openjdk.org/jdk/pull/27480/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27480&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367910 Stats: 50 lines in 8 files changed: 18 ins; 5 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/27480.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27480/head:pull/27480 PR: https://git.openjdk.org/jdk/pull/27480 From dlong at openjdk.org Wed Sep 24 23:38:16 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 24 Sep 2025 23:38:16 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps [v4] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 14:23:45 GMT, Thomas Stuefe wrote: >> When we run with ASAN enabled and ASAN catches an error, it reports, then stops the JVM. hs-err files and crash dumps at that point would be incredibly useful, though. The ASAN error report itself is seldom enlightening since it only contains native stacks. >> >> This patch makes it possible to get hs-err files and subsequent crash dumps by using the error callback functionality of ASAN. It registers a callback which gets called when ASAN catches an error. We then - carefully - print out the ASAN report to stderr (as ASAN itself would have done) and proceeed to end the JVM with a `fatal()`, which gives us an hs-err file, a callstack at that point including Java frames, and - if enabled - core dumps. >> >> Tested on Fedora 42 and Debian 12, both manually and by running the new companion jtreg test. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > fix Actually, what I was trying to get at with my question was whether we need the callback if abort_on_error=1 is set. If abort_on_error=1 is set, it will call abort(), which should send a SIGABRT and then cause an hs_err file to get generated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27446#issuecomment-3331019879 From sspitsyn at openjdk.org Thu Sep 25 00:12:40 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 25 Sep 2025 00:12:40 GMT Subject: RFR: 8368159: Significant performance overhead when started with jdwp agent and unattached debugger [v2] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 22:06:29 GMT, Chris Plummer wrote: >>> But if we are not in interp_only mode isn't it already invalidated? >> >> It does not need to be invalidated if not in `interp_only` mode as it should not be used there or has to be explicitly invalidated exactly where it is needed (the frame pops cleaning code for plain Continuations). The issue I see is only with the test `test/hotspot/jtreg/serviceability/jvmti/vthread/ContStackDepthTest` which is for plain Continuations. Otherwise, the `invalidate_jvmti_stack()` would not be needed. It plays as a workaround to make this test to pass. It seems there is a bug related to plain Continuations lurking somewhere. > > My point is we could just unconditionally invalidate. It would do no harm. It would not be invalidating a curr stack depth that could later be used. Okay, thanks! I'll make it unconditional. I do not see any performance degradation with that. Also, it will keep the `test/hotspot/jtreg/serviceability/jvmti/vthread/ContStackDepthTest` test passed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27403#discussion_r2377332233 From sspitsyn at openjdk.org Thu Sep 25 00:18:02 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 25 Sep 2025 00:18:02 GMT Subject: RFR: 8368159: Significant performance overhead when started with jdwp agent and unattached debugger [v3] In-Reply-To: References: Message-ID: > This update removes a significant performance overhead when an application running millions of virtual threads is started with the JDWP agent but debugger has not been attached. The overhead is 4X-6X slowdown. > The tested app normally (without debug agent) takes around 3+ seconds. With debug agent enabled it takes 14 seconds and more. The performance overhead is caused by the `jvmti_yield_cleanup()` recursively calling `JvmtiExport::continuation_yield_cleanup()`. The reason of this overhead is because the function `JvmtiExport::can_post_frame_pop()` is used to identify a need for the JVMTI cleanup which is not precise and triggers unneeded work when debugger has not been attached yet. The fix is to trigger the JVMTI cleanup with new function: `bool JvmtiExport::has_frame_pops(JavaThread* thread)`. > > Testing: > - Insure the 4X-6X slowdown is gone for an application running millions of virtual threads and started with JDWP agent > - Mach5 tiers 1-6 are all passed Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: remove unneeded condition from invalidate_jvmti_stack() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27403/files - new: https://git.openjdk.org/jdk/pull/27403/files/4b0478fc..52309bce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27403&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27403&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27403.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27403/head:pull/27403 PR: https://git.openjdk.org/jdk/pull/27403 From lmesnik at openjdk.org Thu Sep 25 00:24:05 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 25 Sep 2025 00:24:05 GMT Subject: RFR: 8368159: Significant performance overhead when started with jdwp agent and unattached debugger [v3] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 00:18:02 GMT, Serguei Spitsyn wrote: >> This update removes a significant performance overhead when an application running millions of virtual threads is started with the JDWP agent but debugger has not been attached. The overhead is 4X-6X slowdown. >> The tested app normally (without debug agent) takes around 3+ seconds. With debug agent enabled it takes 14 seconds and more. The performance overhead is caused by the `jvmti_yield_cleanup()` recursively calling `JvmtiExport::continuation_yield_cleanup()`. The reason of this overhead is because the function `JvmtiExport::can_post_frame_pop()` is used to identify a need for the JVMTI cleanup which is not precise and triggers unneeded work when debugger has not been attached yet. The fix is to trigger the JVMTI cleanup with new function: `bool JvmtiExport::has_frame_pops(JavaThread* thread)`. >> >> Testing: >> - Insure the 4X-6X slowdown is gone for an application running millions of virtual threads and started with JDWP agent >> - Mach5 tiers 1-6 are all passed > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: remove unneeded condition from invalidate_jvmti_stack() Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27403#pullrequestreview-3265088332 From sparasa at openjdk.org Thu Sep 25 00:48:37 2025 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Thu, 25 Sep 2025 00:48:37 GMT Subject: RFR: 8367780: Enable UseAPX on Intel CPUs only when both APX_F and APX_NCI_NDD_NF cpuid features are present [v4] In-Reply-To: References: <-cYOL5wwp8oSisK5utj0B7mHi0D_Ne0i_N_RI-bsbLk=.87c1bc5f-a6a3-4d4e-9530-fc91e676656f@github.com> Message-ID: On Tue, 23 Sep 2025 10:37:53 GMT, Jatin Bhateja wrote: > EMR>sde64 -dmr -ptr_raise -- java -XX:+PrintFlagsFinal -XX:+UnlockExperimentalVMOptions -XX:+UseAPX --version | grep APX > OpenJDK 64-Bit Server VM warning: UseAPX is not supported on this CPU, setting it to false > Hi Jatin, Thank for informing about this issue! Sorry about the SDE issue. Will inform you once the public version of SDE which supports this feature is avalible. Thanks, Vamsi ------------- PR Comment: https://git.openjdk.org/jdk/pull/27320#issuecomment-3331286352 From dlong at openjdk.org Thu Sep 25 00:56:39 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 25 Sep 2025 00:56:39 GMT Subject: RFR: 8368518: [s390x] test failure with failed: wrong size of mach node In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 11:11:12 GMT, Amit Kumar wrote: > Fixes the test failures. Tested tier1 with release and fastdebug vm. > > Moves one comment related to INTPRESSURE, a leftover from previous change. src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp line 358: > 356: > 357: int minimum_alignment = 16; > 358: #if (defined(X86) || defined(S390)) && !defined(AMD64) Suggestion: #if (defined(X86) && !defined(AMD64)) || defined(S390) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27465#discussion_r2377386991 From fyang at openjdk.org Thu Sep 25 01:30:24 2025 From: fyang at openjdk.org (Fei Yang) Date: Thu, 25 Sep 2025 01:30:24 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v8] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 15:54:59 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> >> Currently, the cpu features of riscv are stored in separate RVFeature subclasses. >> But to support the store/restore CPU features for aot in the future, we need to store the cpu features in a continuous memory. >> As the riscv extensions are introduced continuously, I think it's better to do it via an simple bitmap at the beginning. >> Currently, just suppose the non-extension features will not be stored in aot image, so I also split the extension and non-extenion features. When we implement the related aot feature in the short future, we can revisit the way of splitting the features. Currently, just change the storage way of cpu features, lay the foundation for future aot. >> >> Thanks > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > undef macros A few minor cleanup suggestions. Looks good otherwise. src/hotspot/cpu/riscv/vm_version_riscv.hpp line 293: > 291: > 292: constexpr static int element_shift_count() { > 293: return LogBitsPerLong; This `element_shift_count` doesn't seem intuitive from its name and could be factored out. See my comments about its callers. src/hotspot/cpu/riscv/vm_version_riscv.hpp line 296: > 294: } > 295: > 296: static int element_index(RVFeatureIndex feature) { Can we rename this as `feature_element`? This together with `feature_bit` tell us where the bit lies. src/hotspot/cpu/riscv/vm_version_riscv.hpp line 297: > 295: > 296: static int element_index(RVFeatureIndex feature) { > 297: int idx = feature >> element_shift_count(); Suggestion: `int idx = feature / BitsPerLong;` src/hotspot/cpu/riscv/vm_version_riscv.hpp line 304: > 302: static uint64_t feature_bit(RVFeatureIndex feature) { > 303: constexpr static uint64_t m = (1ULL << element_shift_count()) - 1; > 304: return (1ULL << (feature & m)); Suggestion: `return (1ULL << (feature % BitsPerLong));` ------------- PR Review: https://git.openjdk.org/jdk/pull/27152#pullrequestreview-3265195893 PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2377419105 PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2377422343 PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2377415221 PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2377416959 From dholmes at openjdk.org Thu Sep 25 02:09:35 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 25 Sep 2025 02:09:35 GMT Subject: RFR: 8365191: Cleanup after removing LockingMode related code [v3] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 13:05:23 GMT, Fredrik Bredberg wrote: >> This is a general cleanup after removing `LockingMode` related code. >> It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261). >> It includes: >> - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking. >> - Removing or rewriting comments, arguments or functions that are related to displaced headers. >> - Remove "always true" parameter from `MonitorExitStub`. >> - Re-type/name metadata in `BasicLock`. >> >> Tier1-5 passes okay on supported platforms. >> >> All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > Fixed a mixup Still good. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27448#pullrequestreview-3265275100 From dholmes at openjdk.org Thu Sep 25 02:33:12 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 25 Sep 2025 02:33:12 GMT Subject: RFR: 8367910: Reduce warnings about unsupported classes in AOT cache creation In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 23:15:21 GMT, Ioi Lam wrote: > Currently AOT cache creation may print lots of warning (depending on the actions performed by the application's training run). Most of these warnings are harmless and are caused by JVM limitations; there's nothing that the user can do about them: > > > [1.096s][warning][aot] Skipping jdk/internal/event/Event: JFR event class > [1.096s][warning][aot] Skipping jdk/jfr/Event: JFR event class > [1.099s][warning][aot] Skipping jdk/proxy1/$Proxy14: Unsupported location > [1.100s][warning][aot] Skipping jdk/proxy1/$Proxy12: Unsupported location > [1.100s][warning][aot] Skipping jdk/proxy1/$Proxy11: Unsupported location > > > This PR moves most of these warnings to the "info" level. The only messages that are still logged in the "warning" levels are: > > - class is in an error state > - class failed verification > > These could indicate issues with the application so it's good to let the user know. Seems reasonable. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27480#pullrequestreview-3265332092 From dholmes at openjdk.org Thu Sep 25 02:45:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 25 Sep 2025 02:45:54 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v6] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 16:09:24 GMT, Thomas Stuefe wrote: >> On Linux, ASAN only shows some internal thread designation on reports, e.g. `T49`, which is useless. >> >> This patch adds the ability to see the real internal JVM thread names or user-supplied Java thread names in ASAN. This makes it possible to correlate ASAN reports with hs-err file reports (if ASAN is run with `halt_on_error=0` to give us a chance to get an hs-err file) or with a thread dump done beforehand. >> >> Note that it can only show up to 15 characters, though. Therefore, the patch tries to be smart about names that end in digits: such numbers are preserved such that the truncation happens in the middle of the name, e.g.: >> >> `"MyAllocationWorkerThread#4411"` -> `"MyAllocat..4411"` >> >> This latter improvement now also applies to thread names in gdb, since they are subject to the same limitation. >> >> For a detailed analysis of why the old version, using libpthread's `pthread_setname_np`, is not sufficient for thread names in ASAN, please see the issue description. >> >> ----- >> >> Some examples from ASAN report: >> >> Before: >> >> WRITE of size 8 at 0x7b749d2d9190 thread T49 >> >> >> Now: >> >> WRITE of size 8 at 0x7bfc2f0d8380 thread T49 (MyThread#0) >> >> >> >> ==593899==ERROR: AddressSanitizer: attempting free .. in thread T76 (MyAllocati..29) > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > some more tests Simplified spot-fix looks good - thanks. You missed my follow up re the redundancy of `Linux::_pthread_setname_np`. test/hotspot/gtest/runtime/test_os_linux.cpp line 38: > 36: > 37: #include > 38: #include Nit: alphabetic order please ------------- PR Review: https://git.openjdk.org/jdk/pull/27395#pullrequestreview-3265344997 PR Review Comment: https://git.openjdk.org/jdk/pull/27395#discussion_r2377518644 From fyang at openjdk.org Thu Sep 25 02:58:39 2025 From: fyang at openjdk.org (Fei Yang) Date: Thu, 25 Sep 2025 02:58:39 GMT Subject: RFR: 8367692: RISC-V: Align post call nop In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 11:52:20 GMT, Robbin Ehn wrote: > Hi please, consider. > > As ziccif require instructions to natural aligned to be atomic the 4 byte post call nop must be aligned. > But I don't want to add a c.nop(2b) to align the nop(4b) which means the jal(r) must also be algined. > As we have no utility to aligned the end of an instruction sequence the call it self is aligned and uses only 4 byte instructions. Only in the case where we could use an two c-instruction we may loose space. > > Thanks, Robbin Hi, Thanks for finding this. Nice fix! I only have several minor comments. src/hotspot/cpu/riscv/assembler_riscv.hpp line 859: > 857: return insn; > 858: } > 859: I am not sure but is it better to place this with friends `encode_jal` and `encode_jalr` at line 928? These all return an instruction encoding instead of writing the code cache and thus are different from other assember routines. src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 359: > 357: void MacroAssembler::post_call_nop() { > 358: assert(!in_compressible_scope(), "Must be"); > 359: assert_alignment(pc()); Does the first assertion make sense here? Seems to me the second one will just suffice. src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp line 1007: > 1005: __ bnez(c_rarg2, call_thaw); > 1006: > 1007: address tr_call; Can you rename this to `call_pc` while you are on it? `tr_call` is named after trampoline call, but we don't have that now. src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp line 1042: > 1040: __ bnez(c_rarg2, call_thaw); > 1041: > 1042: address tr_call; Similar here. ------------- PR Review: https://git.openjdk.org/jdk/pull/27467#pullrequestreview-3263439361 PR Review Comment: https://git.openjdk.org/jdk/pull/27467#discussion_r2377446188 PR Review Comment: https://git.openjdk.org/jdk/pull/27467#discussion_r2376159064 PR Review Comment: https://git.openjdk.org/jdk/pull/27467#discussion_r2377533241 PR Review Comment: https://git.openjdk.org/jdk/pull/27467#discussion_r2377533438 From amitkumar at openjdk.org Thu Sep 25 04:12:09 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 25 Sep 2025 04:12:09 GMT Subject: RFR: 8368518: [s390x] test failure with failed: wrong size of mach node [v2] In-Reply-To: References: Message-ID: > Fixes the test failures. Tested tier1 with release and fastdebug vm. > > Moves one comment related to INTPRESSURE, a leftover from previous change. Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27465/files - new: https://git.openjdk.org/jdk/pull/27465/files/866f3f75..6f440382 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27465&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27465&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27465.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27465/head:pull/27465 PR: https://git.openjdk.org/jdk/pull/27465 From cjplummer at openjdk.org Thu Sep 25 04:19:36 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 25 Sep 2025 04:19:36 GMT Subject: RFR: 8368159: Significant performance overhead when started with jdwp agent and unattached debugger [v3] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 00:18:02 GMT, Serguei Spitsyn wrote: >> This update removes a significant performance overhead when an application running millions of virtual threads is started with the JDWP agent but debugger has not been attached. The overhead is 4X-6X slowdown. >> The tested app normally (without debug agent) takes around 3+ seconds. With debug agent enabled it takes 14 seconds and more. The performance overhead is caused by the `jvmti_yield_cleanup()` recursively calling `JvmtiExport::continuation_yield_cleanup()`. The reason of this overhead is because the function `JvmtiExport::can_post_frame_pop()` is used to identify a need for the JVMTI cleanup which is not precise and triggers unneeded work when debugger has not been attached yet. The fix is to trigger the JVMTI cleanup with new function: `bool JvmtiExport::has_frame_pops(JavaThread* thread)`. >> >> Testing: >> - Insure the 4X-6X slowdown is gone for an application running millions of virtual threads and started with JDWP agent >> - Mach5 tiers 1-6 are all passed > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: remove unneeded condition from invalidate_jvmti_stack() Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27403#pullrequestreview-3265601862 From dlong at openjdk.org Thu Sep 25 04:34:30 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 25 Sep 2025 04:34:30 GMT Subject: RFR: 8368518: [s390x] test failure with failed: wrong size of mach node [v2] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 04:12:09 GMT, Amit Kumar wrote: >> Fixes the test failures. Tested tier1 with release and fastdebug vm. >> >> Moves one comment related to INTPRESSURE, a leftover from previous change. > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp > > Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com> For the record, please describe what goes wrong and how this fixes it. ------------- Marked as reviewed by dlong (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27465#pullrequestreview-3265640037 From sspitsyn at openjdk.org Thu Sep 25 05:44:35 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 25 Sep 2025 05:44:35 GMT Subject: RFR: 8368159: Significant performance overhead when started with jdwp agent and unattached debugger [v3] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 00:18:02 GMT, Serguei Spitsyn wrote: >> This update removes a significant performance overhead when an application running millions of virtual threads is started with the JDWP agent but debugger has not been attached. The overhead is 4X-6X slowdown. >> The tested app normally (without debug agent) takes around 3+ seconds. With debug agent enabled it takes 14 seconds and more. The performance overhead is caused by the `jvmti_yield_cleanup()` recursively calling `JvmtiExport::continuation_yield_cleanup()`. The reason of this overhead is because the function `JvmtiExport::can_post_frame_pop()` is used to identify a need for the JVMTI cleanup which is not precise and triggers unneeded work when debugger has not been attached yet. The fix is to trigger the JVMTI cleanup with new function: `bool JvmtiExport::has_frame_pops(JavaThread* thread)`. >> >> Testing: >> - Insure the 4X-6X slowdown is gone for an application running millions of virtual threads and started with JDWP agent >> - Mach5 tiers 1-6 are all passed > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: remove unneeded condition from invalidate_jvmti_stack() Chris and Leonid, thank you for review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27403#issuecomment-3332225678 From sspitsyn at openjdk.org Thu Sep 25 05:44:36 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 25 Sep 2025 05:44:36 GMT Subject: Integrated: 8368159: Significant performance overhead when started with jdwp agent and unattached debugger In-Reply-To: References: Message-ID: On Sat, 20 Sep 2025 04:40:16 GMT, Serguei Spitsyn wrote: > This update removes a significant performance overhead when an application running millions of virtual threads is started with the JDWP agent but debugger has not been attached. The overhead is 4X-6X slowdown. > The tested app normally (without debug agent) takes around 3+ seconds. With debug agent enabled it takes 14 seconds and more. The performance overhead is caused by the `jvmti_yield_cleanup()` recursively calling `JvmtiExport::continuation_yield_cleanup()`. The reason of this overhead is because the function `JvmtiExport::can_post_frame_pop()` is used to identify a need for the JVMTI cleanup which is not precise and triggers unneeded work when debugger has not been attached yet. The fix is to trigger the JVMTI cleanup with new function: `bool JvmtiExport::has_frame_pops(JavaThread* thread)`. > > Testing: > - Insure the 4X-6X slowdown is gone for an application running millions of virtual threads and started with JDWP agent > - Mach5 tiers 1-6 are all passed This pull request has now been integrated. Changeset: 17244c69 Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/17244c699ad20fafe7448678a53266ce6bf017e5 Stats: 24 lines in 3 files changed: 18 ins; 1 del; 5 mod 8368159: Significant performance overhead when started with jdwp agent and unattached debugger Reviewed-by: lmesnik, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/27403 From kvn at openjdk.org Thu Sep 25 05:53:22 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 25 Sep 2025 05:53:22 GMT Subject: RFR: 8367910: Reduce warnings about unsupported classes in AOT cache creation In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 23:15:21 GMT, Ioi Lam wrote: > Currently AOT cache creation may print lots of warning (depending on the actions performed by the application's training run). Most of these warnings are harmless and are caused by JVM limitations; there's nothing that the user can do about them: > > > [1.096s][warning][aot] Skipping jdk/internal/event/Event: JFR event class > [1.096s][warning][aot] Skipping jdk/jfr/Event: JFR event class > [1.099s][warning][aot] Skipping jdk/proxy1/$Proxy14: Unsupported location > [1.100s][warning][aot] Skipping jdk/proxy1/$Proxy12: Unsupported location > [1.100s][warning][aot] Skipping jdk/proxy1/$Proxy11: Unsupported location > > > This PR moves most of these warnings to the "info" level. The only messages that are still logged in the "warning" levels are: > > - class is in an error state > - class failed verification > > These could indicate issues with the application so it's good to let the user know. Looks good ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27480#pullrequestreview-3265853657 From tanksherman27 at gmail.com Thu Sep 25 05:53:56 2025 From: tanksherman27 at gmail.com (Julian Waters) Date: Thu, 25 Sep 2025 13:53:56 +0800 Subject: Problems with LTO for HotSpot In-Reply-To: <736d1d36-bb0e-4661-987c-12bf05bebe54@oracle.com> References: <736d1d36-bb0e-4661-987c-12bf05bebe54@oracle.com> Message-ID: Might there be any indication of what callees constitute the fast paths, and which are slow paths (Or are in other compilation units) and shouldn't be inlined? I've tried to determine that myself for quite a while, but the call hierarchy is so unbelievably massive that it's impossible to manually see which ones need to avoid inlining, and all attempts to use tools to create a call graph have failed pretty badly. Maybe we could keep the flatten even with LTO if it's needed. I'd hopefully like to avoid introducing an explicit "LTO enabled" marker in autoconf and make beyond just setting the flags for LTO. But I guess I'll cross that bridge when I come to it, right now I'm not even able to get started trying to fix this issue. best regards, Julian On Thu, Sep 25, 2025 at 6:16?AM Kim Barrett wrote: > > On 9/24/25 1:08 PM, Julian Waters wrote: > > Recently I've been picking up and resuming work on making LTO viable > > for HotSpot. [...] The bigger issue is related to the flatten attribute > > on the gcc compiler. In short, some G1 code (More specifically void > > G1ParScanThreadState::trim_queue_to_threshold(uint threshold), void > > G1ParScanThreadState::steal_and_trim_queue(G1ScannerTasksQueueSet* > > task_queues) and oop > > G1ParScanThreadState::copy_to_survivor_space(G1HeapRegionAttr > > region_attr, oop old, markWord old_mark)) is marked as flatten > > The flatten attribute is being used there because the code in question has > been found to be very (performance) sensitive to compiler decisions to > sometimes not inline something. So apply the big hammer. > > (Note that some critical path stuff is conditionally noinline in debug builds, > because otherwise such builds were also running into excessive inlining, > leading to things like "conditional branch out of range" failures.) > > Using flatten is certainly leading to more inlining than actually needed. > > An alternative to using flatten would be to try to mark all the critical path > stuff always_inline. I found that pretty hard to do, and also brittle, much > like Julian is encountering with the flatten + noinline approach. > > But it might be that some judicious always_inline + noinline + either (but not > both) flatten or LTO might work. That was the direction I was going to > explore, but haven't found any spare 'tuits to allocate in that direction. > Supporting LTO just hasn't percolated up the priority list here. > From amitkumar at openjdk.org Thu Sep 25 05:58:15 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 25 Sep 2025 05:58:15 GMT Subject: RFR: 8368518: [s390x] test failure with failed: wrong size of mach node [v2] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 04:32:18 GMT, Dean Long wrote: > For the record, please describe what goes wrong and how this fixes it. Updated :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27465#issuecomment-3332290480 From stuefe at openjdk.org Thu Sep 25 05:59:59 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 25 Sep 2025 05:59:59 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v7] In-Reply-To: References: Message-ID: <4Qpoc_71yo7P8S5i7mNo-Neaia4zhQONf71WZpKqXmM=.575ac5a6-1796-4814-bdbe-e2a5091d27a1@github.com> > On Linux, ASAN only shows some internal thread designation on reports, e.g. `T49`, which is useless. > > This patch adds the ability to see the real internal JVM thread names or user-supplied Java thread names in ASAN. This makes it possible to correlate ASAN reports with hs-err file reports (if ASAN is run with `halt_on_error=0` to give us a chance to get an hs-err file) or with a thread dump done beforehand. > > Note that it can only show up to 15 characters, though. Therefore, the patch tries to be smart about names that end in digits: such numbers are preserved such that the truncation happens in the middle of the name, e.g.: > > `"MyAllocationWorkerThread#4411"` -> `"MyAllocat..4411"` > > This latter improvement now also applies to thread names in gdb, since they are subject to the same limitation. > > For a detailed analysis of why the old version, using libpthread's `pthread_setname_np`, is not sufficient for thread names in ASAN, please see the issue description. > > ----- > > Some examples from ASAN report: > > Before: > > WRITE of size 8 at 0x7b749d2d9190 thread T49 > > > Now: > > WRITE of size 8 at 0x7bfc2f0d8380 thread T49 (MyThread#0) > > > > ==593899==ERROR: AddressSanitizer: attempting free .. in thread T76 (MyAllocati..29) Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: - reorder includes - remove redundant pthread_setname call ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27395/files - new: https://git.openjdk.org/jdk/pull/27395/files/7c033ad7..e3e84970 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27395&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27395&range=05-06 Stats: 18 lines in 3 files changed: 4 ins; 13 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27395.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27395/head:pull/27395 PR: https://git.openjdk.org/jdk/pull/27395 From stuefe at openjdk.org Thu Sep 25 06:00:00 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 25 Sep 2025 06:00:00 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v6] In-Reply-To: References: Message-ID: <0FKB_8GFrZLOOyLHXTSJsQfbX9iGoEYDXtOoXKaB2xI=.2bb57f63-bf72-46fe-ac59-5994311ba3c7@github.com> On Thu, 25 Sep 2025 02:43:41 GMT, David Holmes wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> some more tests > > Simplified spot-fix looks good - thanks. > > You missed my follow up re the redundancy of `Linux::_pthread_setname_np`. @dholmes-ora Oh right, I missed that. I removed pthread_setname_np and verified that we still get thread names in /proc//task, gdb and ASAN. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27395#issuecomment-3332291693 From stuefe at openjdk.org Thu Sep 25 06:06:23 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 25 Sep 2025 06:06:23 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps [v4] In-Reply-To: References: Message-ID: <3ZOlICYzn5TDtcv98-U7TT8XWE2z7vO2DqXaYyAasrc=.a942f240-deed-4125-b5de-31ceadec80fa@github.com> On Wed, 24 Sep 2025 23:35:25 GMT, Dean Long wrote: > Actually, what I was trying to get at with my question was whether we need the callback if abort_on_error=1 is set. If abort_on_error=1 is set, it will call abort(), which should send a SIGABRT and then cause an hs_err file to get generated. We don't catch SIGABRT. Starting to do so would be a more invasive change (and add some complexities, since we ourselves use abort(3) to generate cores). It would also interfere with user SIGABRT handlers, possibly requiring them to start using libjsig etc. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27446#issuecomment-3332305635 From mhaessig at openjdk.org Thu Sep 25 06:51:09 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Thu, 25 Sep 2025 06:51:09 GMT Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3] In-Reply-To: References: <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com> Message-ID: On Wed, 24 Sep 2025 22:16:17 GMT, Dean Long wrote: >> src/hotspot/cpu/arm/frame_arm.cpp line 365: >> >>> 363: DEBUG_ONLY(verify_deopt_original_pc(sender_nm, _unextended_sp)); >>> 364: } >>> 365: } >> >> All of this could be `NOT_PRODUCT` and the method `const` if I did not miss any side effects. > > Right, there is no adjustment anymore on any platform. I think this function and verify_deopt_original_pc only ever existed to support code that is now getting removed. So I could change the name to verify_unextended_sp() and make it const, but it might make more sense to remove both this function and verify_deopt_original_pc now. What do you think? I would rather keep this code as a debug only sanity check, but I would refactor it into a single function. Then the question remains what to do with the SA code, that still does nothing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2377932365 From mbaesken at openjdk.org Thu Sep 25 07:16:36 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 25 Sep 2025 07:16:36 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v7] In-Reply-To: <4Qpoc_71yo7P8S5i7mNo-Neaia4zhQONf71WZpKqXmM=.575ac5a6-1796-4814-bdbe-e2a5091d27a1@github.com> References: <4Qpoc_71yo7P8S5i7mNo-Neaia4zhQONf71WZpKqXmM=.575ac5a6-1796-4814-bdbe-e2a5091d27a1@github.com> Message-ID: On Thu, 25 Sep 2025 05:59:59 GMT, Thomas Stuefe wrote: >> On Linux, ASAN only shows some internal thread designation on reports, e.g. `T49`, which is useless. >> >> This patch adds the ability to see the real internal JVM thread names or user-supplied Java thread names in ASAN. This makes it possible to correlate ASAN reports with hs-err file reports (if ASAN is run with `halt_on_error=0` to give us a chance to get an hs-err file) or with a thread dump done beforehand. >> >> Note that it can only show up to 15 characters, though. Therefore, the patch tries to be smart about names that end in digits: such numbers are preserved such that the truncation happens in the middle of the name, e.g.: >> >> `"MyAllocationWorkerThread#4411"` -> `"MyAllocat..4411"` >> >> This latter improvement now also applies to thread names in gdb, since they are subject to the same limitation. >> >> For a detailed analysis of why the old version, using libpthread's `pthread_setname_np`, is not sufficient for thread names in ASAN, please see the issue description. >> >> ----- >> >> Some examples from ASAN report: >> >> Before: >> >> WRITE of size 8 at 0x7b749d2d9190 thread T49 >> >> >> Now: >> >> WRITE of size 8 at 0x7bfc2f0d8380 thread T49 (MyThread#0) >> >> >> >> ==593899==ERROR: AddressSanitizer: attempting free .. in thread T76 (MyAllocati..29) > > Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: > > - reorder includes > - remove redundant pthread_setname call Marked as reviewed by mbaesken (Reviewer). Tested it on our CI runs; the thread names look like below now ; for the JLI thread we seem to have no 'good' name just 'Thread T1 created by T0 here' ... but that's what it is right now. The others show the Java/JVM thread names . ==18331==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x506000028974 at pc 0x7f50ed88327a bp 0x7f5098f44c50 sp 0x7f5098f44c48 READ of size 1 at 0x506000028974 thread T60 (Command..212m9]) #0 0x7f50ed883279 in ClassFileParser::skip_over_field_signature(char const*, bool, unsigned int, JavaThread*) const src/hotspot/share/classfile/classFileParser.cpp:4685 #1 0x7f50ed88c48b in ClassFileParser::verify_legal_method_signature(Symbol const*, Symbol const*, JavaThread*) const src/hotspot/share/classfile/classFileParser.cpp:4916 #2 0x7f50ed89c33c in ClassFileParser::parse_method(ClassFileStream const*, bool, ConstantPool const*, bool*, JavaThread*) src/hotspot/share/classfile/classFileParser.cpp:2189 #3 0x7f50ed89f7f7 in ClassFileParser::parse_methods(ClassFileStream const*, bool, bool*, bool*, bool*, JavaThread*) src/hotspot/share/classfile/classFileParser.cpp:2741 #4 0x7f50ed89f7f7 in ClassFileParser::parse_methods(ClassFileStream const*, bool, bool*, bool*, bool*, JavaThread*) src/hotspot/share/classfile/classFileParser.cpp:2717 #5 0x7f50ed8a8190 in ClassFileParser::parse_stream(ClassFileStream const*, JavaThread*) src/hotspot/share/classfile/classFileParser.cpp:5708 #6 0x7f50ed8abf05 in ClassFileParser::parse_stream(ClassFileStream const*, JavaThread*) src/hotspot/share/classfile/classFileParser.cpp:5436 #7 0x7f50ed8abf05 in ClassFileParser::ClassFileParser(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const*, ClassFileParser::Publicity, JavaThread*) src/hotspot/share/classfile/classFileParser.cpp:5433 #8 0x7f50eef01ba5 in KlassFactory::create_from_stream(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const&, JavaThread*) src/hotspot/share/classfile/klassFactory.cpp:202 #9 0x7f50f003fc92 in SystemDictionary::resolve_class_from_stream(ClassFileStream*, Symbol*, Handle, ClassLoadInfo const&, JavaThread*) src/hotspot/share/classfile/systemDictionary.cpp:874 #10 0x7f50ee9c4ef7 in jvm_define_class_common src/hotspot/share/prims/jvm.cpp:888 #11 0x7f50ee9c5dd7 in JVM_DefineClassWithSource src/hotspot/share/prims/jvm.cpp:1055 #12 0x7f50f32cb914 in Java_java_lang_ClassLoader_defineClass1 src/java.base/share/native/libjava/ClassLoader.c:139 #13 0x7f50da46c16f () 0x506000028974 is located 0 bytes after 52-byte region [0x506000028940,0x506000028974) allocated by thread T60 (Command..212m9]) here: #0 0x7f50f42f7237 in malloc (/usr/lib64/libasan.so.8+0xf7237) (BuildId: 976da020d733554aded39770c1e088dce0154259) #1 0x7f50ef5b5517 in permit_forbidden_function::malloc(unsigned long) src/hotspot/share/utilities/permitForbiddenFunctions.hpp:63 #2 0x7f50ef5b5517 in os::malloc(unsigned long, MemTag, NativeCallStack const&) src/hotspot/share/runtime/os.cpp:660 #3 0x7f50ecf0773b in AllocateHeap(unsigned long, MemTag, NativeCallStack const&, AllocFailStrategy::AllocFailEnum) src/hotspot/share/memory/allocation.cpp:39 #4 0x7f50ecf0773b in AllocateHeap(unsigned long, MemTag, AllocFailStrategy::AllocFailEnum) src/hotspot/share/memory/allocation.cpp:49 #5 0x7f50f000dc90 in SymbolTableConfig::allocate_node_impl(unsigned long, Symbol const&) src/hotspot/share/classfile/symbolTable.cpp:195 #6 0x7f50f000dc90 in SymbolTableConfig::allocate_node(void*, unsigned long, Symbol const&) src/hotspot/share/classfile/symbolTable.cpp:137 #7 0x7f50f000dc90 in ConcurrentHashTable::Node::create_node(void*, Symbol const&, ConcurrentHashTable::Node*) src/hotspot/share/utilities/concurrentHashTable.hpp:93 #8 0x7f50f000dc90 in bool ConcurrentHashTable::internal_insert_get::insert(Thread*, SymbolTableLookup&, Symbol const&, bool*, bool*)::NOP>(Thread*, SymbolTableLookup&, Symbol const&, ConcurrentHashTable::insert(Thread*, SymbolTableLookup&, Symbol const&, bool*, bool*)::NOP&, bool*, bool*) src/hotspot/share/utilities/concurrentHashTable.inline.hpp:896 #9 0x7f50f000dc90 in bool ConcurrentHashTable::insert(Thread*, SymbolTableLookup&, Symbol const&, bool*, bool*) src/hotspot/share/utilities/concurrentHashTable.hpp:471 #10 0x7f50f000dc90 in SymbolTable::do_add_if_needed(char const*, int, unsigned long, bool) src/hotspot/share/classfile/symbolTable.cpp:520 #11 0x7f50f0011c7a in SymbolTable::new_symbols(ClassLoaderData*, constantPoolHandle const&, int, char const**, int*, int*, unsigned int*) src/hotspot/share/classfile/symbolTable.cpp:498 #12 0x7f50ed8a38c0 in ClassFileParser::parse_constant_pool_entries(ClassFileStream const*, ConstantPool*, int, JavaThread*) src/hotspot/share/classfile/classFileParser.cpp:390 #13 0x7f50ed8a6b8f in ClassFileParser::parse_constant_pool(ClassFileStream const*, ConstantPool*, int, JavaThread*) src/hotspot/share/classfile/classFileParser.cpp:425 #14 0x7f50ed8a6b8f in ClassFileParser::parse_stream(ClassFileStream const*, JavaThread*) src/hotspot/share/classfile/classFileParser.cpp:5571 #15 0x7f50ed8abf05 in ClassFileParser::parse_stream(ClassFileStream const*, JavaThread*) src/hotspot/share/classfile/classFileParser.cpp:5436 #16 0x7f50ed8abf05 in ClassFileParser::ClassFileParser(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const*, ClassFileParser::Publicity, JavaThread*) src/hotspot/share/classfile/classFileParser.cpp:5433 #17 0x7f50eef01ba5 in KlassFactory::create_from_stream(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const&, JavaThread*) src/hotspot/share/classfile/klassFactory.cpp:202 #18 0x7f50f003fc92 in SystemDictionary::resolve_class_from_stream(ClassFileStream*, Symbol*, Handle, ClassLoadInfo const&, JavaThread*) src/hotspot/share/classfile/systemDictionary.cpp:874 #19 0x7f50ee9c4ef7 in jvm_define_class_common src/hotspot/share/prims/jvm.cpp:888 #20 0x7f50ee9c5dd7 in JVM_DefineClassWithSource src/hotspot/share/prims/jvm.cpp:1055 #21 0x7f50f32cb914 in Java_java_lang_ClassLoader_defineClass1 src/java.base/share/native/libjava/ClassLoader.c:139 #22 0x7f50da46c16f () #23 0x7f50da4679e1 () #24 0x7f50da4679e1 () #25 0x7f50da4679e1 () #26 0x7f50da4679e1 () #27 0x7f50d30a7c5b () #28 0x7f50da4679e1 () #29 0x7f50da4679e1 () #30 0x7f50da467847 () #31 0x7f50da467d55 () #32 0x7f50da467847 () #33 0x7f50da4606a6 () #34 0x7f50ee5bfaf7 in JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) src/hotspot/share/runtime/javaCalls.cpp:415 #35 0x7f50ee5c83a1 in JavaCalls::call(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) src/hotspot/share/runtime/javaCalls.cpp:323 #36 0x7f50ee5c83a1 in JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) src/hotspot/share/runtime/javaCalls.cpp:179 #37 0x7f50ee5c83a1 in JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) src/hotspot/share/runtime/javaCalls.cpp:185 #38 0x7f50ee97ebd8 in thread_entry src/hotspot/share/prims/jvm.cpp:2707 #39 0x7f50ee61e5c2 in JavaThread::thread_main_inner() src/hotspot/share/runtime/javaThread.cpp:775 #40 0x7f50ee633317 in JavaThread::thread_main_inner() src/hotspot/share/runtime/javaThread.cpp:755 #41 0x7f50ee633317 in JavaThread::run() src/hotspot/share/runtime/javaThread.cpp:760 Thread T60 (Command..212m9]) created by T29 (Agent0) here: #0 0x7f50f42ef0c1 in pthread_create (/usr/lib64/libasan.so.8+0xef0c1) (BuildId: 976da020d733554aded39770c1e088dce0154259) #1 0x7f50ef5d3bb0 in os::create_thread(Thread*, os::ThreadType, unsigned long) src/hotspot/os/linux/os_linux.cpp:1091 #2 0x7f50ee9c912c in JVM_StartThread src/hotspot/share/prims/jvm.cpp:2770 #3 0x7f50da46c16f () #4 0x7f50da467847 () #5 0x7f50da467847 () #6 0x7f50da4679e1 () #7 0x7f50da4679e1 () #8 0x7f50da4679e1 () #9 0x7f50da467847 () #10 0x7f50da467847 () #11 0x7f50da467847 () #12 0x7f50da467d55 () #13 0x7f50da467847 () #14 0x7f50da4606a6 () #15 0x7f50ee5bfaf7 in JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) src/hotspot/share/runtime/javaCalls.cpp:415 #16 0x7f50ee5c83a1 in JavaCalls::call(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) src/hotspot/share/runtime/javaCalls.cpp:323 #17 0x7f50ee5c83a1 in JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) src/hotspot/share/runtime/javaCalls.cpp:179 #18 0x7f50ee5c83a1 in JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) src/hotspot/share/runtime/javaCalls.cpp:185 #19 0x7f50ee97ebd8 in thread_entry src/hotspot/share/prims/jvm.cpp:2707 #20 0x7f50ee61e5c2 in JavaThread::thread_main_inner() src/hotspot/share/runtime/javaThread.cpp:775 #21 0x7f50ee633317 in JavaThread::thread_main_inner() src/hotspot/share/runtime/javaThread.cpp:755 #22 0x7f50ee633317 in JavaThread::run() src/hotspot/share/runtime/javaThread.cpp:760 #23 0x7f50f013df8f in Thread::call_run() src/hotspot/share/runtime/thread.cpp:243 #24 0x7f50ef5d0972 in thread_native_entry src/hotspot/os/linux/os_linux.cpp:898 #25 0x7f50f425eef5 (/usr/lib64/libasan.so.8+0x5eef5) (BuildId: 976da020d733554aded39770c1e088dce0154259) Thread T29 (Agent0) created by T1 here: #0 0x7f50f42ef0c1 in pthread_create (/usr/lib64/libasan.so.8+0xef0c1) (BuildId: 976da020d733554aded39770c1e088dce0154259) #1 0x7f50ef5d3bb0 in os::create_thread(Thread*, os::ThreadType, unsigned long) src/hotspot/os/linux/os_linux.cpp:1091 #2 0x7f50ee9c912c in JVM_StartThread src/hotspot/share/prims/jvm.cpp:2770 #3 0x7f50da46c16f () #4 0x7f50da467847 () #5 0x7f50da467847 () #6 0x7f50da467847 () #7 0x7f50da467847 () #8 0x7f50da467847 () #9 0x7f50da4606a6 () #10 0x7f50ee5bfaf7 in JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) src/hotspot/share/runtime/javaCalls.cpp:415 #11 0x7f50ee8dca93 in jni_invoke_static src/hotspot/share/prims/jni.cpp:881 #12 0x7f50ee8e80c9 in jni_CallStaticVoidMethod src/hotspot/share/prims/jni.cpp:1710 #13 0x7f50f41df05b in invokeStaticMainWithArgs src/java.base/share/native/libjli/java.c:392 #14 0x7f50f41e2cef in JavaMain src/java.base/share/native/libjli/java.c:640 #15 0x7f50f41e7fd8 in ThreadJavaMain src/java.base/unix/native/libjli/java_md.c:646 #16 0x7f50f425eef5 (/usr/lib64/libasan.so.8+0x5eef5) (BuildId: 976da020d733554aded39770c1e088dce0154259) Thread T1 created by T0 here: #0 0x7f50f42ef0c1 in pthread_create (/usr/lib64/libasan.so.8+0xef0c1) (BuildId: 976da020d733554aded39770c1e088dce0154259) #1 0x7f50f41e9928 in CallJavaMainInNewThread src/java.base/unix/native/libjli/java_md.c:687 #2 0x7f50f41e5580 in ContinueInNewThread src/java.base/share/native/libjli/java.c:2340 #3 0x7f50f41e6edd in JLI_Launch src/java.base/share/native/libjli/java.c:330 #4 0x55a3f79d70fc in main src/java.base/share/native/launcher/main.c:150 #5 0x7f50f3e40e6b in __libc_start_call_main (/lib64/libc.so.6+0x40e6b) (BuildId: 16dc6ffdd6165c6cb0346d683a041c90daa99730) ------------- PR Review: https://git.openjdk.org/jdk/pull/27395#pullrequestreview-3266121314 PR Comment: https://git.openjdk.org/jdk/pull/27395#issuecomment-3332494824 From mbaesken at openjdk.org Thu Sep 25 07:22:08 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 25 Sep 2025 07:22:08 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v7] In-Reply-To: <4Qpoc_71yo7P8S5i7mNo-Neaia4zhQONf71WZpKqXmM=.575ac5a6-1796-4814-bdbe-e2a5091d27a1@github.com> References: <4Qpoc_71yo7P8S5i7mNo-Neaia4zhQONf71WZpKqXmM=.575ac5a6-1796-4814-bdbe-e2a5091d27a1@github.com> Message-ID: On Thu, 25 Sep 2025 05:59:59 GMT, Thomas Stuefe wrote: >> On Linux, ASAN only shows some internal thread designation on reports, e.g. `T49`, which is useless. >> >> This patch adds the ability to see the real internal JVM thread names or user-supplied Java thread names in ASAN. This makes it possible to correlate ASAN reports with hs-err file reports (if ASAN is run with `halt_on_error=0` to give us a chance to get an hs-err file) or with a thread dump done beforehand. >> >> Note that it can only show up to 15 characters, though. Therefore, the patch tries to be smart about names that end in digits: such numbers are preserved such that the truncation happens in the middle of the name, e.g.: >> >> `"MyAllocationWorkerThread#4411"` -> `"MyAllocat..4411"` >> >> This latter improvement now also applies to thread names in gdb, since they are subject to the same limitation. >> >> For a detailed analysis of why the old version, using libpthread's `pthread_setname_np`, is not sufficient for thread names in ASAN, please see the issue description. >> >> ----- >> >> Some examples from ASAN report: >> >> Before: >> >> WRITE of size 8 at 0x7b749d2d9190 thread T49 >> >> >> Now: >> >> WRITE of size 8 at 0x7bfc2f0d8380 thread T49 (MyThread#0) >> >> >> >> ==593899==ERROR: AddressSanitizer: attempting free .. in thread T76 (MyAllocati..29) > > Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: > > - reorder includes > - remove redundant pthread_setname call Tested it on our CI runs; the thread names look good now except for the JLI thread we seem to have no 'good' name just 'Thread T1 created by T0 here' ... but that's what it is right now. The others show the Java/JVM thread names . ------------- PR Comment: https://git.openjdk.org/jdk/pull/27395#issuecomment-3332515963 From kbarrett at openjdk.org Thu Sep 25 07:29:39 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 25 Sep 2025 07:29:39 GMT Subject: RFR: 8367013: Add Atomic to package/replace idiom of volatile var plus AtomicAccess:: operations In-Reply-To: <3nRiWxbET2Bf7i1VNfWGH12omfPxcTaC6W2UhLVDDH0=.0c34542e-e08b-42e3-b35b-ae98c46abe0a@github.com> References: <3nRiWxbET2Bf7i1VNfWGH12omfPxcTaC6W2UhLVDDH0=.0c34542e-e08b-42e3-b35b-ae98c46abe0a@github.com> Message-ID: <5oQ0s1wcdNDb6roIVEsU7iAP60dySzsFWaLxzQic_CY=.ca35a43d-41db-4903-a5c9-2e23a817b2e6@github.com> On Wed, 24 Sep 2025 14:36:25 GMT, Stefan Karlsson wrote: >> Please review this change that adds the type `Atomic`, to use as the type >> of a variable that is accessed (including writes) concurrently by multiple >> threads. This is intended to replace (most) uses of the current HotSpot idiom >> of declaring a variable `volatile` and accessing that variable using functions >> from the AtomicAccess class. >> https://github.com/openjdk/jdk/blame/528f93f8cb9f1fb9c19f31ab80c8a546f47beed2/doc/hotspot-style.md#L138-L147 >> >> Testing: mach5 tier1-6, GHA sanity tests > > I tested this in my editor (Eclipse) and it doesn't seem to give any code completion because of this: > > // The Atomic type. > template > using Atomic = AtomicImpl::Selected; > > If I explicitly use AtomicImpl::AtomicInteger then I get the expected code completion. > > I wonder if this is going to be problematic with other editors or if this is just a problem with Eclipse. @stefank and I are discussing some changes that make the code more IDE friendly, which seems like a laudible goal. So I'm withdrawing this PR to avoid wasting reviewer time when there's going to be some non-trivial changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27462#issuecomment-3332538858 From kbarrett at openjdk.org Thu Sep 25 07:29:40 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 25 Sep 2025 07:29:40 GMT Subject: Withdrawn: 8367013: Add Atomic to package/replace idiom of volatile var plus AtomicAccess:: operations In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 05:32:38 GMT, Kim Barrett wrote: > Please review this change that adds the type `Atomic`, to use as the type > of a variable that is accessed (including writes) concurrently by multiple > threads. This is intended to replace (most) uses of the current HotSpot idiom > of declaring a variable `volatile` and accessing that variable using functions > from the AtomicAccess class. > https://github.com/openjdk/jdk/blame/528f93f8cb9f1fb9c19f31ab80c8a546f47beed2/doc/hotspot-style.md#L138-L147 > > Testing: mach5 tier1-6, GHA sanity tests This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27462 From jkern at openjdk.org Thu Sep 25 07:40:03 2025 From: jkern at openjdk.org (Joachim Kern) Date: Thu, 25 Sep 2025 07:40:03 GMT Subject: RFR: 8368250: [AIX] now ubsan vptr check is also possible (follow up of JDK-8354686) [v2] In-Reply-To: References: Message-ID: > After [JDK-8354686](https://bugs.openjdk.org/browse/JDK-8354686) the ubsan vptr checks still did not work. We finally found out, that they only work, if all linkage units are linked with the C++ compiler frontend as linker, especially the main executables (java, javac, ...) which are linked with the C compiler frontend. > So for a ubsan enabled build on AIX we let everything link with the C++ compiler frontend. > Background: The C++ compiler frontend inherently adds special static libraries which the C compiler does not. This results in missing symbols when trying to start a program and its shared libraries, when they were linked in mixed mode. Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: indentation and typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27468/files - new: https://git.openjdk.org/jdk/pull/27468/files/a459f293..e3f3a995 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27468&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27468&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27468.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27468/head:pull/27468 PR: https://git.openjdk.org/jdk/pull/27468 From rehn at openjdk.org Thu Sep 25 07:40:21 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 25 Sep 2025 07:40:21 GMT Subject: RFR: 8367692: RISC-V: Align post call nop In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 15:20:15 GMT, Fei Yang wrote: >> Hi please, consider. >> >> As ziccif require instructions to natural aligned to be atomic the 4 byte post call nop must be aligned. >> But I don't want to add a c.nop(2b) to align the nop(4b) which means the jal(r) must also be algined. >> As we have no utility to aligned the end of an instruction sequence the call it self is aligned and uses only 4 byte instructions. Only in the case where we could use an two c-instruction we may loose space. >> >> Thanks, Robbin > > src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 359: > >> 357: void MacroAssembler::post_call_nop() { >> 358: assert(!in_compressible_scope(), "Must be"); >> 359: assert_alignment(pc()); > > Does the first assertion make sense here? Seems to me the second one will just suffice. The code today to avoid C-instructions by: - We do not have nop -> c.nop conversion. - We use zr as destination Instead of relying of this 'trickery', I'm saying these instructions are not c-compressed and user have to turn them off before calling here. I.e. now this code will work with nop->c.nop conversion and using another register in the li32. (which is very sneaky way to get 4 byte instructions) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27467#discussion_r2378047246 From rcastanedalo at openjdk.org Thu Sep 25 07:40:20 2025 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 25 Sep 2025 07:40:20 GMT Subject: RFR: 8359378: aarch64: crash when using -XX:+UseFPUForSpilling In-Reply-To: <0MbLaZYRoz-raa9x1eZycxeHE7mvPiGJujQpg8vBdek=.e3483c47-ad65-4d09-baf5-2db9b780669d@github.com> References: <0MbLaZYRoz-raa9x1eZycxeHE7mvPiGJujQpg8vBdek=.e3483c47-ad65-4d09-baf5-2db9b780669d@github.com> Message-ID: On Wed, 17 Sep 2025 16:19:12 GMT, Boris Ulasevich wrote: > AArch64 BarrierSetAssembler path assumes only FP/vector ideal regs reach the FP spill/restore encoding. With -XX:+UseFPUForSpilling Register Allocator may allocate scalar values in FP registers. When such values (Op_RegI/Op_RegN/Op_RegL/Op_RegP) hit `BarrierSetAssembler::encode_float_vector_register_size`, we trip ShouldNotReachHere in release build and **"unexpected ideal register"** assertion in debug build. > > Fix: teach the encoder to handle scalar ideal regs when they physically live in FP regs: > - treat Op_RegI / Op_RegN as 32-bit (single slot) - same class as Op_RegF > - treat Op_RegL / Op_RegP as 64-bit (two slots) - same class as Op_RegD > > Related: > - reproduced since #19746 > - spilling logic: > - #18967 > - #17977 > > Testing: tier1-3 with javaoptions -Xcomp -Xbatch -XX:+UseFPUForSpilling on AARCH The fix and the test results look good. ------------- Marked as reviewed by rcastanedalo (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27350#pullrequestreview-3266208316 From fbredberg at openjdk.org Thu Sep 25 08:19:21 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Thu, 25 Sep 2025 08:19:21 GMT Subject: RFR: 8365191: Cleanup after removing LockingMode related code [v3] In-Reply-To: References: Message-ID: <1jgUzSlIIf8uo55h2Ai9cPZjmqQ6OyYs61j2TtgfH8w=.09872546-a1c0-44bc-afe8-d5b26fcf3889@github.com> On Wed, 24 Sep 2025 13:05:23 GMT, Fredrik Bredberg wrote: >> This is a general cleanup after removing `LockingMode` related code. >> It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261). >> It includes: >> - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking. >> - Removing or rewriting comments, arguments or functions that are related to displaced headers. >> - Remove "always true" parameter from `MonitorExitStub`. >> - Re-type/name metadata in `BasicLock`. >> >> Tier1-5 passes okay on supported platforms. >> >> All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > Fixed a mixup Thank you all for the reviews. Now let's... ------------- PR Comment: https://git.openjdk.org/jdk/pull/27448#issuecomment-3332749700 From fbredberg at openjdk.org Thu Sep 25 08:19:22 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Thu, 25 Sep 2025 08:19:22 GMT Subject: Integrated: 8365191: Cleanup after removing LockingMode related code In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 09:29:57 GMT, Fredrik Bredberg wrote: > This is a general cleanup after removing `LockingMode` related code. > It's a sub-task of [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261). > It includes: > - Removing asserts that are no longer necessary, since we removed legacy locking and monitor locking. > - Removing or rewriting comments, arguments or functions that are related to displaced headers. > - Remove "always true" parameter from `MonitorExitStub`. > - Re-type/name metadata in `BasicLock`. > > Tier1-5 passes okay on supported platforms. > > All other platforms (arm, ppc, riscv and s390) has been sanity checked using Qemu. This pull request has now been integrated. Changeset: 847b107d Author: Fredrik Bredberg URL: https://git.openjdk.org/jdk/commit/847b107df821e0c1d347383f1858d505137eb724 Stats: 169 lines in 34 files changed: 2 ins; 44 del; 123 mod 8365191: Cleanup after removing LockingMode related code Reviewed-by: coleenp, dholmes, yzheng, mdoerr, ayang, fyang, amitkumar ------------- PR: https://git.openjdk.org/jdk/pull/27448 From rehn at openjdk.org Thu Sep 25 08:35:43 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 25 Sep 2025 08:35:43 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v2] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 01:45:08 GMT, Fei Yang wrote: >> Robbin Ehn 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 three additional commits since the last revision: >> >> - Merge branch 'master' into align_post_nops >> - Review comments >> - init > > src/hotspot/cpu/riscv/assembler_riscv.hpp line 859: > >> 857: return insn; >> 858: } >> 859: > > I am not sure but is it better to place this with friends `encode_jal` and `encode_jalr` at line 928? These all return an instruction encoding instead of writing the code cache and thus are different from other assember routines. Maybe we should group them together. Fixed > src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp line 1007: > >> 1005: __ bnez(c_rarg2, call_thaw); >> 1006: >> 1007: address tr_call; > > Can you rename this to `call_pc` while you are on it? `tr_call` is named after trampoline call, but we don't have that now. Fixed > src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp line 1042: > >> 1040: __ bnez(c_rarg2, call_thaw); >> 1041: >> 1042: address tr_call; > > Similar here. Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27467#discussion_r2378234720 PR Review Comment: https://git.openjdk.org/jdk/pull/27467#discussion_r2378235050 PR Review Comment: https://git.openjdk.org/jdk/pull/27467#discussion_r2378235359 From rehn at openjdk.org Thu Sep 25 08:35:39 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 25 Sep 2025 08:35:39 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v2] In-Reply-To: References: Message-ID: > Hi please, consider. > > As ziccif require instructions to natural aligned to be atomic the 4 byte post call nop must be aligned. > But I don't want to add a c.nop(2b) to align the nop(4b) which means the jal(r) must also be algined. > As we have no utility to aligned the end of an instruction sequence the call it self is aligned and uses only 4 byte instructions. Only in the case where we could use an two c-instruction we may loose space. > > Thanks, Robbin Robbin Ehn 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 three additional commits since the last revision: - Merge branch 'master' into align_post_nops - Review comments - init ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27467/files - new: https://git.openjdk.org/jdk/pull/27467/files/409e6da1..8f2dcb6d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27467&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27467&range=00-01 Stats: 5376 lines in 152 files changed: 3227 ins; 1061 del; 1088 mod Patch: https://git.openjdk.org/jdk/pull/27467.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27467/head:pull/27467 PR: https://git.openjdk.org/jdk/pull/27467 From mli at openjdk.org Thu Sep 25 08:38:40 2025 From: mli at openjdk.org (Hamlin Li) Date: Thu, 25 Sep 2025 08:38:40 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v8] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 01:22:17 GMT, Fei Yang wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> undef macros > > src/hotspot/cpu/riscv/vm_version_riscv.hpp line 293: > >> 291: >> 292: constexpr static int element_shift_count() { >> 293: return LogBitsPerLong; > > This `element_shift_count` doesn't seem intuitive from its name and could be factored out. See my comments about its callers. make sense, will fix. > src/hotspot/cpu/riscv/vm_version_riscv.hpp line 296: > >> 294: } >> 295: >> 296: static int element_index(RVFeatureIndex feature) { > > Can we rename this as `feature_element`? This together with `feature_bit` tell us where the bit lies. I think it's better to be element_index, please check usage of it,`int idx = element_index(f);`, we are using it to find the index in the _features_bitmap, and there is another method called `element_count`, their name should be related to each other. > src/hotspot/cpu/riscv/vm_version_riscv.hpp line 297: > >> 295: >> 296: static int element_index(RVFeatureIndex feature) { >> 297: int idx = feature >> element_shift_count(); > > Suggestion: `int idx = feature / BitsPerLong;` You're right, seems there is a bug here. > src/hotspot/cpu/riscv/vm_version_riscv.hpp line 304: > >> 302: static uint64_t feature_bit(RVFeatureIndex feature) { >> 303: constexpr static uint64_t m = (1ULL << element_shift_count()) - 1; >> 304: return (1ULL << (feature & m)); > > Suggestion: `return (1ULL << (feature % BitsPerLong));` yes, it's better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2378243624 PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2378244299 PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2378242349 PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2378243210 From mli at openjdk.org Thu Sep 25 08:53:52 2025 From: mli at openjdk.org (Hamlin Li) Date: Thu, 25 Sep 2025 08:53:52 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v9] In-Reply-To: References: Message-ID: <-3Fg_hwY8rMmwq-FJqyPyo65rGMtA_J84ZLqzfRtN5I=.8669bee6-9568-4305-9dab-5ab35aa5d67a@github.com> > Hi, > Can you help to review this patch? > > Currently, the cpu features of riscv are stored in separate RVFeature subclasses. > But to support the store/restore CPU features for aot in the future, we need to store the cpu features in a continuous memory. > As the riscv extensions are introduced continuously, I think it's better to do it via an simple bitmap at the beginning. > Currently, just suppose the non-extension features will not be stored in aot image, so I also split the extension and non-extenion features. When we implement the related aot feature in the short future, we can revisit the way of splitting the features. Currently, just change the storage way of cpu features, lay the foundation for future aot. > > Thanks Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: refine ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27152/files - new: https://git.openjdk.org/jdk/pull/27152/files/3131ab70..f19196ff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27152&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27152&range=07-08 Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27152.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27152/head:pull/27152 PR: https://git.openjdk.org/jdk/pull/27152 From aph at openjdk.org Thu Sep 25 09:05:06 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 25 Sep 2025 09:05:06 GMT Subject: RFR: 8368303: AlwaysAtomicAccesses is excessively strict In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 19:32:17 GMT, Dean Long wrote: > It does seem like access_is_atomic() could be moved to platform-specific code, but which platforms would need a different implementation? None of which I'm aware. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27432#issuecomment-3332992373 From aph at openjdk.org Thu Sep 25 09:05:09 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 25 Sep 2025 09:05:09 GMT Subject: RFR: 8368303: AlwaysAtomicAccesses is excessively strict In-Reply-To: <3EIT8mAB0k4dSVjfJzJL2k6B_6rOeQNPExWGWUwXeWc=.6f94a495-ebad-4f88-b37c-86e2fcb8f7fc@github.com> References: <3EIT8mAB0k4dSVjfJzJL2k6B_6rOeQNPExWGWUwXeWc=.6f94a495-ebad-4f88-b37c-86e2fcb8f7fc@github.com> Message-ID: On Wed, 24 Sep 2025 17:36:31 GMT, Vladimir Ivanov wrote: > Why do you require `CPU_MULTI_COPY_ATOMIC`? Why can't you unconditionally treat all sub-word/word accesses (naturally aligned) as atomic instead? Isn't that what JVM already guarantees? This is about the properties of the hardware rather than the JMM, but yes, every CPU that we support in HotSpot is single-copy atomic. Perhaps I was being excessively cautious, and we can just remove `access_is_atomic()`. I was thinking about some hypothetical processor which didn't have this property. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27432#discussion_r2378345511 From stuefe at openjdk.org Thu Sep 25 09:09:23 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 25 Sep 2025 09:09:23 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v7] In-Reply-To: References: <4Qpoc_71yo7P8S5i7mNo-Neaia4zhQONf71WZpKqXmM=.575ac5a6-1796-4814-bdbe-e2a5091d27a1@github.com> Message-ID: <2Dbn0OrEedW_4cTT9DCxLCBsT9FX3P4t2sD-1dNSWFo=.7bc9a0bd-2b97-477f-99a6-64b83a04e230@github.com> On Thu, 25 Sep 2025 07:19:08 GMT, Matthias Baesken wrote: >> Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: >> >> - reorder includes >> - remove redundant pthread_setname call > > Tested it on our CI runs; the thread names look good now except for the JLI thread we seem to have no 'good' name just > 'Thread T1 created by T0 here' ... but that's what it is right now. The others show the Java/JVM thread names . @MBaesken > Tested it on our CI runs; the thread names look good now except for the JLI thread we seem to have no 'good' name just 'Thread T1 created by T0 here' ... but that's what it is right now. The others show the Java/JVM thread names . Interesting find. You hit on an old bug here; the issue is we never set the OS thread name for any attached threads, main thread or others. I opened a new bug to track that: https://bugs.openjdk.org/browse/JDK-8368621 For this PR, I'd say its out of scope. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27395#issuecomment-3333006178 From duke at openjdk.org Thu Sep 25 09:17:16 2025 From: duke at openjdk.org (erifan) Date: Thu, 25 Sep 2025 09:17:16 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v8] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 10:11:47 GMT, Jatin Bhateja wrote: >> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction. >> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails. >> >> Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java). >> >> Vector API jtreg tests pass at AVX level 2, remaining validation in progress. >> >> Performance numbers: >> >> >> System : 13th Gen Intel(R) Core(TM) i3-1315U >> >> Baseline: >> Benchmark (size) Mode Cnt Score Error Units >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 9444.444 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 10009.319 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9081.926 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 6085.825 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 6505.378 ops/ms >> VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 6204.489 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 1651.334 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 1642.784 ops/ms >> VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1474.808 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 10399.394 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 10502.894 ops/ms >> VectorSliceB... > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Update callGenerator.hpp copyright year src/hotspot/share/classfile/vmIntrinsics.hpp line 1178: > 1176: "Ljdk/internal/vm/vector/VectorSupport$Vector;" \ > 1177: "Ljdk/internal/vm/vector/VectorSupport$VectorSliceOp;)" \ > 1178: "Ljdk/internal/vm/vector/VectorSupport$Vector;") \ Seems this `` is not aligned ? src/hotspot/share/classfile/vmIntrinsics.hpp line 1179: > 1177: "Ljdk/internal/vm/vector/VectorSupport$VectorSliceOp;)" \ > 1178: "Ljdk/internal/vm/vector/VectorSupport$Vector;") \ > 1179: do_name(vector_slice_name, "sliceOp") \ ditto 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? test/hotspot/jtreg/compiler/vectorapi/TestSliceOptValueTransforms.java line 122: > 120: .intoArray(bdst, i); > 121: } > 122: } Since this optimization also benefits the slice variant with mask, could you add some tests for it as well? test/micro/org/openjdk/bench/jdk/incubator/vector/VectorSliceBenchmark.java line 59: > 57: static final VectorSpecies sspecies = ShortVector.SPECIES_PREFERRED; > 58: static final VectorSpecies ispecies = IntVector.SPECIES_PREFERRED; > 59: static final VectorSpecies lspecies = LongVector.SPECIES_PREFERRED; Ditto, no fp types ? test/micro/org/openjdk/bench/jdk/incubator/vector/VectorSliceBenchmark.java line 133: > 131: .intoArray(bdst, i); > 132: } > 133: } Ditto, add a benchmark for the slice variant with mask ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2378092410 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2378093047 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2378310217 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2378337340 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2378312763 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2378342519 From duke at openjdk.org Thu Sep 25 09:17:57 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 25 Sep 2025 09:17:57 GMT Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when running on 64-bit OSes [v11] In-Reply-To: References: Message-ID: > Hi, please consider the following changes: > > In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. > > The issue is addressed by changing the output type of all related functions to `uint64_t`. > > Tested in tiers 1 - 5. Anton Artemov has updated the pull request incrementally with two additional commits since the last revision: - 8367485: Eliminated uint64_t - 8367485: Typedef alias for uint64_t used in mem funcs. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27335/files - new: https://git.openjdk.org/jdk/pull/27335/files/b39817de..7d9c59f6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27335&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27335&range=09-10 Stats: 131 lines in 19 files changed: 3 ins; 0 del; 128 mod Patch: https://git.openjdk.org/jdk/pull/27335.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27335/head:pull/27335 PR: https://git.openjdk.org/jdk/pull/27335 From duke at openjdk.org Thu Sep 25 09:18:03 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 25 Sep 2025 09:18:03 GMT Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when running on 64-bit OSes [v10] In-Reply-To: <9vKDSge1so828VpIlmbHofhqKak_K-6WSZeON0KyByU=.c81f69d3-3238-4f9b-ad1a-7894830cb74d@github.com> References: <9vKDSge1so828VpIlmbHofhqKak_K-6WSZeON0KyByU=.c81f69d3-3238-4f9b-ad1a-7894830cb74d@github.com> Message-ID: On Thu, 25 Sep 2025 08:47:44 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. >> >> The issue is addressed by changing the output type of all related functions to `uint64_t`. >> >> Tested in tiers 1 - 5. > > Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into JDK-8367485-os-physical-memory-broken-32bit-on-64bit > - 8367485: Alignment of vars in os_windows.cpp > - 8367485: Indentation in GCInitLogger::print_memory() > - 8367485: Changed output format in GCInitLogger::print_memory() > - 8367485: Addressed reviewers' comments. > - 8367485: Indentation fix. > - 8367485: Addressed reviewer's comments. > - 8367485: Addressed reviewer's comments > - 8367485: Addressed reviewer's comments. > - 8367485: Refactoring with uint64_t > - ... and 2 more: https://git.openjdk.org/jdk/compare/45a162e9...b39817de I added a typedef as suggested as an alias for `uint64_t`. Though with "_type" ending, which makes it somewhat long. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27335#issuecomment-3333028090 From sgehwolf at openjdk.org Thu Sep 25 09:21:43 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 25 Sep 2025 09:21:43 GMT Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when running on 64-bit OSes [v11] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 09:17:57 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. >> >> The issue is addressed by changing the output type of all related functions to `uint64_t`. >> >> Tested in tiers 1 - 5. > > Anton Artemov has updated the pull request incrementally with two additional commits since the last revision: > > - 8367485: Eliminated uint64_t > - 8367485: Typedef alias for uint64_t used in mem funcs. src/hotspot/os/aix/os_aix.cpp line 2195: > 2193: > 2194: trcVerbose("processor count: %d", os::_processor_count); > 2195: trcVerbose("physical memory: " UINT64_FORMAT, Aix::_physical_memory); Should there be a `PHYS_MEM_TYPE_FORMAT` define as well. In case the format needs changing from `UINT64_FORMAT`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2378392610 From fyang at openjdk.org Thu Sep 25 09:22:47 2025 From: fyang at openjdk.org (Fei Yang) Date: Thu, 25 Sep 2025 09:22:47 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v9] In-Reply-To: <-3Fg_hwY8rMmwq-FJqyPyo65rGMtA_J84ZLqzfRtN5I=.8669bee6-9568-4305-9dab-5ab35aa5d67a@github.com> References: <-3Fg_hwY8rMmwq-FJqyPyo65rGMtA_J84ZLqzfRtN5I=.8669bee6-9568-4305-9dab-5ab35aa5d67a@github.com> Message-ID: On Thu, 25 Sep 2025 08:53:52 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> >> Currently, the cpu features of riscv are stored in separate RVFeature subclasses. >> But to support the store/restore CPU features for aot in the future, we need to store the cpu features in a continuous memory. >> As the riscv extensions are introduced continuously, I think it's better to do it via an simple bitmap at the beginning. >> Currently, just suppose the non-extension features will not be stored in aot image, so I also split the extension and non-extenion features. When we implement the related aot feature in the short future, we can revisit the way of splitting the features. Currently, just change the storage way of cpu features, lay the foundation for future aot. >> >> Thanks > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > refine LGTM. Thanks. ------------- Marked as reviewed by fyang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27152#pullrequestreview-3266680552 From fyang at openjdk.org Thu Sep 25 09:22:49 2025 From: fyang at openjdk.org (Fei Yang) Date: Thu, 25 Sep 2025 09:22:49 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v8] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 08:33:33 GMT, Hamlin Li wrote: >> src/hotspot/cpu/riscv/vm_version_riscv.hpp line 296: >> >>> 294: } >>> 295: >>> 296: static int element_index(RVFeatureIndex feature) { >> >> Can we rename this as `feature_element`? This together with `feature_bit` tell us where the bit lies. > > I think it's better to be element_index, please check usage of it,`int idx = element_index(f);`, we are using it to find the index in the _features_bitmap, and there is another method called `element_count`, their name should be related to each other. OK. That's fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2378394102 From duke at openjdk.org Thu Sep 25 09:26:07 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 25 Sep 2025 09:26:07 GMT Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when running on 64-bit OSes [v11] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 09:19:00 GMT, Severin Gehwolf wrote: >> Anton Artemov has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8367485: Eliminated uint64_t >> - 8367485: Typedef alias for uint64_t used in mem funcs. > > src/hotspot/os/aix/os_aix.cpp line 2195: > >> 2193: >> 2194: trcVerbose("processor count: %d", os::_processor_count); >> 2195: trcVerbose("physical memory: " UINT64_FORMAT, Aix::_physical_memory); > > Should there be a `PHYS_MEM_TYPE_FORMAT` define as well. In case the format needs changing from `UINT64_FORMAT`? Good catch, let me add it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2378407098 From stuefe at openjdk.org Thu Sep 25 09:33:52 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 25 Sep 2025 09:33:52 GMT Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when running on 64-bit OSes [v11] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 09:17:57 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. >> >> The issue is addressed by changing the output type of all related functions to `uint64_t`. >> >> Tested in tiers 1 - 5. > > Anton Artemov has updated the pull request incrementally with two additional commits since the last revision: > > - 8367485: Eliminated uint64_t > - 8367485: Typedef alias for uint64_t used in mem funcs. LGTM. Thanks for doing this. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27335#pullrequestreview-3266728112 From fyang at openjdk.org Thu Sep 25 09:39:28 2025 From: fyang at openjdk.org (Fei Yang) Date: Thu, 25 Sep 2025 09:39:28 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v2] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 07:36:22 GMT, Robbin Ehn wrote: >> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 359: >> >>> 357: void MacroAssembler::post_call_nop() { >>> 358: assert(!in_compressible_scope(), "Must be"); >>> 359: assert_alignment(pc()); >> >> Does the first assertion make sense here? Seems to me the second one will just suffice. > > The code today to avoid C-instructions by: > - We do not have nop -> c.nop conversion. > - We use zr as destination > > Instead of relying of this 'trickery', I'm saying these instructions are not compressed and user have to turn them off before calling here. > I.e. now this code will work with nop->c.nop conversion and using another register in the li32. (which is very sneaky way to get 4 byte instructions) Mind you that the `nop()` and `li32(zr, 0)` are the `callback` for the relocate. And this callback is invoked under a IncompressibleScope [1]. [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/assembler_riscv.hpp#L2851 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27467#discussion_r2378446658 From duke at openjdk.org Thu Sep 25 09:53:32 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 25 Sep 2025 09:53:32 GMT Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when running on 64-bit OSes [v12] In-Reply-To: References: Message-ID: > Hi, please consider the following changes: > > In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. > > The issue is addressed by changing the output type of all related functions to `physical_memory_size_type`, which is an alias to `uint64_t`. > > Tested in tiers 1 - 5. Anton Artemov has updated the pull request incrementally with two additional commits since the last revision: - 8367485: Fixed whitespace error. - 8367485: Added print formar for mem funcs vals. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27335/files - new: https://git.openjdk.org/jdk/pull/27335/files/7d9c59f6..98edbbff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27335&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27335&range=10-11 Stats: 14 lines in 7 files changed: 1 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/27335.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27335/head:pull/27335 PR: https://git.openjdk.org/jdk/pull/27335 From duke at openjdk.org Thu Sep 25 09:53:36 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 25 Sep 2025 09:53:36 GMT Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when running on 64-bit OSes [v11] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 09:23:40 GMT, Anton Artemov wrote: >> src/hotspot/os/aix/os_aix.cpp line 2195: >> >>> 2193: >>> 2194: trcVerbose("processor count: %d", os::_processor_count); >>> 2195: trcVerbose("physical memory: " UINT64_FORMAT, Aix::_physical_memory); >> >> Should there be a `PHYS_MEM_TYPE_FORMAT` define as well. In case the format needs changing from `UINT64_FORMAT`? > > Good catch, let me add it. Added. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2378474601 From sgehwolf at openjdk.org Thu Sep 25 09:59:08 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 25 Sep 2025 09:59:08 GMT Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when running on 64-bit OSes [v12] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 09:53:32 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. >> >> The issue is addressed by changing the output type of all related functions to `physical_memory_size_type`, which is an alias to `uint64_t`. >> >> Tested in tiers 1 - 5. > > Anton Artemov has updated the pull request incrementally with two additional commits since the last revision: > > - 8367485: Fixed whitespace error. > - 8367485: Added print formar for mem funcs vals. Looks good to me. ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27335#pullrequestreview-3266833425 From stefank at openjdk.org Thu Sep 25 09:59:12 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 25 Sep 2025 09:59:12 GMT Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when running on 64-bit OSes [v12] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 09:53:32 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. >> >> The issue is addressed by changing the output type of all related functions to `physical_memory_size_type`, which is an alias to `uint64_t`. >> >> Tested in tiers 1 - 5. > > Anton Artemov has updated the pull request incrementally with two additional commits since the last revision: > > - 8367485: Fixed whitespace error. > - 8367485: Added print formar for mem funcs vals. src/hotspot/share/utilities/globalDefinitions.hpp line 421: > 419: typedef unsigned int uint; NEEDS_CLEANUP > 420: > 421: //---------------------------------------------------------------------------------------------------- If you look at the file there's a bunch of sections starting with dashes. I don't think you need a new section for a single typedef Suggestion: src/hotspot/share/utilities/globalDefinitions.hpp line 422: > 420: > 421: //---------------------------------------------------------------------------------------------------- > 422: // Type defenition for memory functions There's a typo here defenition > definition. With that said, this comment mimics the comments for the sections above and below: // VM type definitions // Java type definitions but we don't need a new section, so I think we should not follow those patterns. Instead it would be good to have a motivation for having this typedef. Something that explains that the amount of physical memory doesn't necessarily fit in a 32-bit size_t for 32-bit JVMs and that we have this typedef to mark the places where we have to deal with that quirk as long as we support 32-bit JVMs. src/hotspot/share/utilities/globalDefinitions.hpp line 423: > 421: //---------------------------------------------------------------------------------------------------- > 422: // Type defenition for memory functions > 423: typedef uint64_t physical_memory_size_type; When adding code make sure have a blank line between the new code and the surrounding code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2378484837 PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2378501102 PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2378474586 From amitkumar at openjdk.org Thu Sep 25 10:02:38 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 25 Sep 2025 10:02:38 GMT Subject: RFR: 8368518: [s390x] test failure with failed: wrong size of mach node [v2] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 04:12:09 GMT, Amit Kumar wrote: >> Issue: >> >> while previous settings: >> >> (gdb) p n_size < (current_offset-instr_offset) >> $7 = true <- now we will end up on the false-assert trap and program will crash. >> (gdb) p n_size >> $8 = 104 >> (gdb) p current_offset >> $9 = 108 >> >> uint n_size = n->size(C->regalloc()); >> if (n_size < (current_offset-instr_offset)) { >> MachNode* mach = n->as_Mach(); >> ...... >> assert(false, "wrong size of mach node"); >> } >> >> >> Issue is with VEP offset. After alignment in nmethod_entry_barrier, if MachPrologNode start address is 4 byte aligned, then size will be constant. But if it's not 4 byte aligned then some `nops` will be added by `align()` method in `nmethod_entry_barrier`, after which VEP will not be at correct offset. That offset is being controlled by `InteriorEntryAlignment` and updating it 4 fixes the issue. >> >> Fixes the test failures. Tested tier1 with release and fastdebug vm. >> >> Moves one comment related to INTPRESSURE, a leftover from previous change. > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp > > Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com> Thanks for the approval and reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27465#issuecomment-3333191552 From amitkumar at openjdk.org Thu Sep 25 10:02:39 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 25 Sep 2025 10:02:39 GMT Subject: Integrated: 8368518: [s390x] test failure with failed: wrong size of mach node In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 11:11:12 GMT, Amit Kumar wrote: > Issue: > > while previous settings: > > (gdb) p n_size < (current_offset-instr_offset) > $7 = true <- now we will end up on the false-assert trap and program will crash. > (gdb) p n_size > $8 = 104 > (gdb) p current_offset > $9 = 108 > > uint n_size = n->size(C->regalloc()); > if (n_size < (current_offset-instr_offset)) { > MachNode* mach = n->as_Mach(); > ...... > assert(false, "wrong size of mach node"); > } > > > Issue is with VEP offset. After alignment in nmethod_entry_barrier, if MachPrologNode start address is 4 byte aligned, then size will be constant. But if it's not 4 byte aligned then some `nops` will be added by `align()` method in `nmethod_entry_barrier`, after which VEP will not be at correct offset. That offset is being controlled by `InteriorEntryAlignment` and updating it 4 fixes the issue. > > Fixes the test failures. Tested tier1 with release and fastdebug vm. > > Moves one comment related to INTPRESSURE, a leftover from previous change. This pull request has now been integrated. Changeset: 44cb9cad Author: Amit Kumar URL: https://git.openjdk.org/jdk/commit/44cb9cad263b4fe2749fd6c223b657d77dca5119 Stats: 6 lines in 3 files changed: 1 ins; 3 del; 2 mod 8368518: [s390x] test failure with failed: wrong size of mach node Reviewed-by: dlong, mdoerr, lucy ------------- PR: https://git.openjdk.org/jdk/pull/27465 From aph at openjdk.org Thu Sep 25 10:05:54 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 25 Sep 2025 10:05:54 GMT Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when running on 64-bit OSes [v12] In-Reply-To: References: Message-ID: <-pPbkfNbgaBiqy3efnXsRXvObg1CikHbSwnTRFAR6-Q=.3e5cdde5-7347-467c-b142-055a25e996ef@github.com> On Thu, 25 Sep 2025 09:53:32 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. >> >> The issue is addressed by changing the output type of all related functions to `physical_memory_size_type`, which is an alias to `uint64_t`. >> >> Tested in tiers 1 - 5. > > Anton Artemov has updated the pull request incrementally with two additional commits since the last revision: > > - 8367485: Fixed whitespace error. > - 8367485: Added print formar for mem funcs vals. Marked as reviewed by aph (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27335#pullrequestreview-3266866142 From kbarrett at openjdk.org Thu Sep 25 10:10:35 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 25 Sep 2025 10:10:35 GMT Subject: RFR: 8367013: Add Atomic to package/replace idiom of volatile var plus AtomicAccess:: operations In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 08:16:59 GMT, Andrew Haley wrote: >> Please review this change that adds the type `Atomic`, to use as the type >> of a variable that is accessed (including writes) concurrently by multiple >> threads. This is intended to replace (most) uses of the current HotSpot idiom >> of declaring a variable `volatile` and accessing that variable using functions >> from the AtomicAccess class. >> https://github.com/openjdk/jdk/blame/528f93f8cb9f1fb9c19f31ab80c8a546f47beed2/doc/hotspot-style.md#L138-L147 >> >> Testing: mach5 tier1-6, GHA sanity tests > > src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp line 424: > >> 422: StringDedup::Table::CleanupState* StringDedup::Table::_cleanup_state = nullptr; >> 423: bool StringDedup::Table::_need_bucket_shrinking = false; >> 424: Atomic StringDedup::Table::_dead_count{}; > > Suggestion: > > Atomic StringDedup::Table::_dead_count; > > This is not a function, is it? With the braces is a value-initialization of the variable. Without is default initialization. As it happens, because this is a static storage duration variable and the class has a default ctor, those are the same. But I'd prefer to be explicit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27462#discussion_r2378530144 From duke at openjdk.org Thu Sep 25 10:24:24 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 25 Sep 2025 10:24:24 GMT Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when running on 64-bit OSes [v13] In-Reply-To: References: Message-ID: > Hi, please consider the following changes: > > In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. > > The issue is addressed by changing the output type of all related functions to `physical_memory_size_type`, which is an alias to `uint64_t`. > > Tested in tiers 1 - 5. Anton Artemov has updated the pull request incrementally with two additional commits since the last revision: - 8367485: Fixed new line after typedef. - 8367485: Fixed comment in global definitions. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27335/files - new: https://git.openjdk.org/jdk/pull/27335/files/98edbbff..4590bdb3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27335&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27335&range=11-12 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27335.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27335/head:pull/27335 PR: https://git.openjdk.org/jdk/pull/27335 From duke at openjdk.org Thu Sep 25 10:24:27 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 25 Sep 2025 10:24:27 GMT Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when running on 64-bit OSes [v13] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 09:55:56 GMT, Stefan Karlsson wrote: >> Anton Artemov has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8367485: Fixed new line after typedef. >> - 8367485: Fixed comment in global definitions. > > src/hotspot/share/utilities/globalDefinitions.hpp line 422: > >> 420: >> 421: //---------------------------------------------------------------------------------------------------- >> 422: // Type defenition for memory functions > > There's a typo here defenition > definition. With that said, this comment mimics the comments for the sections above and below: > > // VM type definitions > // Java type definitions > > but we don't need a new section, so I think we should not follow those patterns. Instead it would be good to have a motivation for having this typedef. Something that explains that the amount of physical memory doesn't necessarily fit in a 32-bit size_t for 32-bit JVMs and that we have this typedef to mark the places where we have to deal with that quirk as long as we support 32-bit JVMs. Thanks, I addressed this by adding an extended comment. No new section added as suggested. > src/hotspot/share/utilities/globalDefinitions.hpp line 423: > >> 421: //---------------------------------------------------------------------------------------------------- >> 422: // Type defenition for memory functions >> 423: typedef uint64_t physical_memory_size_type; > > When adding code make sure have a blank line between the new code and the surrounding code. Line added. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2378568022 PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2378569525 From ayang at openjdk.org Thu Sep 25 10:55:24 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 25 Sep 2025 10:55:24 GMT Subject: RFR: 8368303: AlwaysAtomicAccesses is excessively strict In-Reply-To: <3iNJe3osexjMT-Ifr8UkuPqQ38U2gjcYzVGT4TNZALw=.a67f797c-1cab-4d38-b249-88ecef5379c1@github.com> References: <3iNJe3osexjMT-Ifr8UkuPqQ38U2gjcYzVGT4TNZALw=.a67f797c-1cab-4d38-b249-88ecef5379c1@github.com> Message-ID: On Wed, 24 Sep 2025 12:55:38 GMT, Andrew Haley wrote: > The problem is that when an access is marked as volatile... There is potentially some preexisting mixing-up btw `volatile` and `atomic`; not sure if this is intentional. if (is_atomic && !needs_patching) { gen->volatile_field_store(value, access.resolved_addr()->as_address_ptr(), access.access_emit_info()); } I thought `volatile_field_store` is just a misnomer -- should have been `atomic_field_store`, indicating that the caller requires the store to be atomic. Then underlying arch fulfills that contract one way or another. It's possible in certain cases (small types) that nothing extra than a plain store is required. However, how to satisfy the atomic-store requirement should be a callee responsibility. Just my 2c. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27432#issuecomment-3333386614 From ayang at openjdk.org Thu Sep 25 11:14:46 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 25 Sep 2025 11:14:46 GMT Subject: RFR: 8346005: Parallel: Incorrect page size calculation with UseLargePages [v6] In-Reply-To: References: Message-ID: > Refactor the heap-space and OS memory interface code to clearly separate two related but distinct concepts: `alignment` and `os-page-size`. These are now represented as two fields in `PSVirtualSpace`. > > The parallel heap consists of four spaces: old, eden, from, and to. The first belongs to the old generation, while the latter three belong to the young generation. > > The size of any space is always aligned to `alignment`, which also determines the unit for resizing. To keep the implementation simple while allowing flexible per-space commit and uncommit operations, each space must contain at least one OS page. As a result, `alignment` is always greater than or equal to `os-page-size`. > > When using explicit large pages -- which require pre-allocating large pages before the VM starts -- the actual OS page size is not known until the heap has been reserved. The additional logic in `ParallelScavengeHeap::initialize` detects the OS page size in use and adjusts `alignment` if necessary. > > Test: tier1?8 Albert Mingkun Yang 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 'master' into pgc-largepage - Merge branch 'master' into pgc-largepage - page-size - Merge branch 'master' into pgc-largepage - Merge branch 'master' into pgc-largepage - Merge branch 'master' into pgc-largepage - pgc-largepage ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26700/files - new: https://git.openjdk.org/jdk/pull/26700/files/c7254311..5c02c752 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26700&range=04-05 Stats: 141741 lines in 1307 files changed: 121570 ins; 11725 del; 8446 mod Patch: https://git.openjdk.org/jdk/pull/26700.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26700/head:pull/26700 PR: https://git.openjdk.org/jdk/pull/26700 From rehn at openjdk.org Thu Sep 25 12:10:15 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 25 Sep 2025 12:10:15 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v3] In-Reply-To: References: Message-ID: > Hi please, consider. > > As ziccif require instructions to natural aligned to be atomic the 4 byte post call nop must be aligned. > But I don't want to add a c.nop(2b) to align the nop(4b) which means the jal(r) must also be algined. > As we have no utility to aligned the end of an instruction sequence the call it self is aligned and uses only 4 byte instructions. Only in the case where we could use an two c-instruction we may loose space. > > Thanks, Robbin Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Removed relocate for post call nops ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27467/files - new: https://git.openjdk.org/jdk/pull/27467/files/8f2dcb6d..033ecd4a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27467&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27467&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27467.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27467/head:pull/27467 PR: https://git.openjdk.org/jdk/pull/27467 From rehn at openjdk.org Thu Sep 25 12:10:16 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 25 Sep 2025 12:10:16 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v3] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 09:37:10 GMT, Fei Yang wrote: >> The code today to avoid C-instructions by: >> - We do not have nop -> c.nop conversion. >> - We use zr as destination >> >> Instead of relying of this 'trickery', I'm saying these instructions are not compressed and user have to turn them off before calling here. >> I.e. now this code will work with nop->c.nop conversion and using another register in the li32. (which is very sneaky way to get 4 byte instructions) > > Mind you that the `nop()` and `li32(zr, 0)` are the `callback` for the relocate. And this callback is invoked under a IncompressibleScope [1]. > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/assembler_riscv.hpp#L2851 But that is just another hack to avoid c-instructions, as the post call nop instructions are location independent. Removed the relocation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27467#discussion_r2378857416 From rehn at openjdk.org Thu Sep 25 12:10:16 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 25 Sep 2025 12:10:16 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v3] In-Reply-To: References: Message-ID: <-pT1zmz8b5bJSxqrbKjx0lRtFYEsMpe6IMLU3AZmYWc=.dd07d932-ce37-4ff0-b86a-8889245b230a@github.com> On Thu, 25 Sep 2025 12:03:37 GMT, Robbin Ehn wrote: >> Mind you that the `nop()` and `li32(zr, 0)` are the `callback` for the relocate. And this callback is invoked under a IncompressibleScope [1]. >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/assembler_riscv.hpp#L2851 > > But that is just another hack to avoid c-instructions, as the post call nop instructions are location independent. > Removed the relocation. Oh, wait the relocation is needed to find them, right? Darn we need the relocation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27467#discussion_r2378861432 From rehn at openjdk.org Thu Sep 25 12:10:17 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 25 Sep 2025 12:10:17 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v3] In-Reply-To: <-pT1zmz8b5bJSxqrbKjx0lRtFYEsMpe6IMLU3AZmYWc=.dd07d932-ce37-4ff0-b86a-8889245b230a@github.com> References: <-pT1zmz8b5bJSxqrbKjx0lRtFYEsMpe6IMLU3AZmYWc=.dd07d932-ce37-4ff0-b86a-8889245b230a@github.com> Message-ID: On Thu, 25 Sep 2025 12:05:13 GMT, Robbin Ehn wrote: >> But that is just another hack to avoid c-instructions, as the post call nop instructions are location independent. >> Removed the relocation. > > Oh, wait the relocation is needed to find them, right? > Darn we need the relocation. Yes, we need the relocation as we use that to patch the imms to the oopmaps. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27467#discussion_r2378866526 From jsjolen at openjdk.org Thu Sep 25 12:13:32 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 25 Sep 2025 12:13:32 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 04:11:20 GMT, Serguei Spitsyn wrote: >> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/operands-again' into operands-again >> - Fix BSM naming > > src/hotspot/share/oops/constantPool.hpp line 116: > >> 114: return _argument_count; >> 115: } >> 116: int argument(int n) const { > > Q: Why was the function name changed? I think `argument_index` sounds a bit misleading, "the nth argument" makes more sense imo. Yes, I introduced the original name :-). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2378875552 From rehn at openjdk.org Thu Sep 25 12:16:06 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 25 Sep 2025 12:16:06 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v4] In-Reply-To: References: Message-ID: > Hi please, consider. > > As ziccif require instructions to natural aligned to be atomic the 4 byte post call nop must be aligned. > But I don't want to add a c.nop(2b) to align the nop(4b) which means the jal(r) must also be algined. > As we have no utility to aligned the end of an instruction sequence the call it self is aligned and uses only 4 byte instructions. Only in the case where we could use an two c-instruction we may loose space. > > Thanks, Robbin Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Revert "Removed relocate for post call nops" This reverts commit 033ecd4ab3d62c1ccc7845d8bc9e62fc6574e05d. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27467/files - new: https://git.openjdk.org/jdk/pull/27467/files/033ecd4a..304b7366 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27467&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27467&range=02-03 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27467.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27467/head:pull/27467 PR: https://git.openjdk.org/jdk/pull/27467 From jsjolen at openjdk.org Thu Sep 25 12:23:12 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 25 Sep 2025 12:23:12 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v5] In-Reply-To: References: Message-ID: On Sat, 20 Sep 2025 05:58:50 GMT, Serguei Spitsyn wrote: >> You might want @sspitsyn to review the jvmtiRedefineClasses changes since he did this work for the existing operands arrays. > >> @coleenp said: You might want @sspitsyn to review the jvmtiRedefineClasses changes since he did this work for the existing operands arrays. > > Thanks. I'm looking at this update. @sspitsyn , I applied most of your nits! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27198#issuecomment-3333668069 From jsjolen at openjdk.org Thu Sep 25 12:23:14 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 25 Sep 2025 12:23:14 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 04:30:46 GMT, Serguei Spitsyn wrote: >> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/operands-again' into operands-again >> - Fix BSM naming > > src/hotspot/share/oops/constantPool.hpp line 128: > >> 126: >> 127: // The BSMAttributeEntries stores the state of the BootstrapMethods attribute. >> 128: class BSMAttributeEntries { > > Nit: I'm thinking if it would make sense to rename it to `BSMEntries`. > Then we could rename this as well: `BSMAttributeEntry` => `BSMEntry`. > It feels like it will increase the readability as it is already clear that `BSMEntry` is about `BSM` attributes. Hmm, I don't want to go into renaming them in this PR. I think that's something that can be done separately. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2378887133 From jsjolen at openjdk.org Thu Sep 25 12:23:11 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 25 Sep 2025 12:23:11 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v8] In-Reply-To: References: Message-ID: <7NmgdmfTkUlL6XJSOOi8QoroX0B-wYYqcrKswicgNls=.2bdc9156-c580-41b7-a2d0-1f8202d52007@github.com> > Hi, > > This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array` to store the offsets in and an `Array` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`. > > We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately. > > For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc. > > On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement. > > Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Serguei's review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27198/files - new: https://git.openjdk.org/jdk/pull/27198/files/d8624f09..f96a16e5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=06-07 Stats: 15 lines in 4 files changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/27198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27198/head:pull/27198 PR: https://git.openjdk.org/jdk/pull/27198 From mli at openjdk.org Thu Sep 25 12:41:43 2025 From: mli at openjdk.org (Hamlin Li) Date: Thu, 25 Sep 2025 12:41:43 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v9] In-Reply-To: References: <-3Fg_hwY8rMmwq-FJqyPyo65rGMtA_J84ZLqzfRtN5I=.8669bee6-9568-4305-9dab-5ab35aa5d67a@github.com> Message-ID: On Thu, 25 Sep 2025 09:20:23 GMT, Fei Yang wrote: > LGTM. Thanks. Thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27152#issuecomment-3333741094 From rehn at openjdk.org Thu Sep 25 12:44:01 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 25 Sep 2025 12:44:01 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v5] In-Reply-To: References: Message-ID: > Hi please, consider. > > As ziccif require instructions to natural aligned to be atomic the 4 byte post call nop must be aligned. > But I don't want to add a c.nop(2b) to align the nop(4b) which means the jal(r) must also be algined. > As we have no utility to aligned the end of an instruction sequence the call it self is aligned and uses only 4 byte instructions. Only in the case where we could use an two c-instruction we may loose space. > > Thanks, Robbin Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Use relocation spec as marker. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27467/files - new: https://git.openjdk.org/jdk/pull/27467/files/304b7366..1438c380 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27467&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27467&range=03-04 Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27467.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27467/head:pull/27467 PR: https://git.openjdk.org/jdk/pull/27467 From rehn at openjdk.org Thu Sep 25 12:44:03 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 25 Sep 2025 12:44:03 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v5] In-Reply-To: References: <-pT1zmz8b5bJSxqrbKjx0lRtFYEsMpe6IMLU3AZmYWc=.dd07d932-ce37-4ff0-b86a-8889245b230a@github.com> Message-ID: On Thu, 25 Sep 2025 12:07:16 GMT, Robbin Ehn wrote: >> Oh, wait the relocation is needed to find them, right? >> Darn we need the relocation. > > Yes, we need the relocation as we use that to patch the imms to the oopmaps. I changed to x86/pcc style and just use it as marker. No need to relocate location indepedent instructions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27467#discussion_r2378943784 From duke at openjdk.org Thu Sep 25 12:44:33 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 25 Sep 2025 12:44:33 GMT Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v15] In-Reply-To: References: Message-ID: > This PR will consolidate fixes of the following bugs: > > https://bugs.openjdk.org/browse/JDK-8361188 > https://bugs.openjdk.org/browse/JDK-8361189 > https://bugs.openjdk.org/browse/JDK-8361190 > https://bugs.openjdk.org/browse/JDK-8361191 > https://bugs.openjdk.org/browse/JDK-8361192 > https://bugs.openjdk.org/browse/JDK-8361193 > https://bugs.openjdk.org/browse/JDK-8361195 > > This PR depends on https://github.com/openjdk/jdk/pull/25971 > > For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188) > > For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193 > > For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192 > > For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191 > > For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190 Khalid Boulanouare has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits: - Merge branch 'openjdk:master' into jdk-8360498 - Removes not needed changes - Revert "Removes not needed changes" This reverts commit e76780d50cc390e35443dccb193cfbc9a1cec1cb. - Removes not needed changes - Removes extra white lines - Merge branch 'pr/25971' into jdk-8360498 - Merge branch 'openjdk:master' into jdk-8158801 - Merge branch 'pr/25971' into jdk-8360498 - Merge branch 'openjdk:master' into jdk-8158801 - Centers missed frames in the middle of screen - ... and 64 more: https://git.openjdk.org/jdk/compare/26b5708c...e5753d14 ------------- Changes: https://git.openjdk.org/jdk/pull/26625/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=14 Stats: 185 lines in 14 files changed: 96 ins; 44 del; 45 mod Patch: https://git.openjdk.org/jdk/pull/26625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625 PR: https://git.openjdk.org/jdk/pull/26625 From mli at openjdk.org Thu Sep 25 12:45:23 2025 From: mli at openjdk.org (Hamlin Li) Date: Thu, 25 Sep 2025 12:45:23 GMT Subject: Integrated: 8367103: RISC-V: store cpu features in a bitmap In-Reply-To: References: Message-ID: On Mon, 8 Sep 2025 19:54:41 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > > Currently, the cpu features of riscv are stored in separate RVFeature subclasses. > But to support the store/restore CPU features for aot in the future, we need to store the cpu features in a continuous memory. > As the riscv extensions are introduced continuously, I think it's better to do it via an simple bitmap at the beginning. > Currently, just suppose the non-extension features will not be stored in aot image, so I also split the extension and non-extenion features. When we implement the related aot feature in the short future, we can revisit the way of splitting the features. Currently, just change the storage way of cpu features, lay the foundation for future aot. > > Thanks This pull request has now been integrated. Changeset: d1ea6ea2 Author: Hamlin Li URL: https://git.openjdk.org/jdk/commit/d1ea6ea22d49884bec53f89fad7029400fb1d7f2 Stats: 209 lines in 2 files changed: 138 ins; 4 del; 67 mod 8367103: RISC-V: store cpu features in a bitmap Reviewed-by: fyang, luhenry ------------- PR: https://git.openjdk.org/jdk/pull/27152 From mli at openjdk.org Thu Sep 25 13:03:19 2025 From: mli at openjdk.org (Hamlin Li) Date: Thu, 25 Sep 2025 13:03:19 GMT Subject: RFR: 8367253: RISC-V: refactor dependent cpu extensions [v4] In-Reply-To: References: Message-ID: > Hi, > Can you help to review this patch? > > Dependent extensions could be improved in several ways. > > Currently, the dependent cpu extensions are processed in 2 separate places: > 1. update_flag() when calling VM_Version::setup_cpu_available_features() > 2. at the end of VM_Version::common_initialize(). > > And, dependency relationship can only be expressed in (1:1) way, can not be expressed (1:N) way, but in fact some extensions can depend on several different other extensions, for example, zvfh depends on zvf and rvv. It's would be better to support this (1:N) relationship. > > So, this PR brings several benefits: > 1. VM options directly related to CPU extensions are automatically set, and they are all set in one place. > 2. keep synchronization between CPU extensions (information in RVFeatureValue) and and VM options. Previously, code in common_initialize wont' sync to RVFeatureValue, unless do it manually, which is error-prone. > 3. support to express (1:N) dependency relationship among cpu extensions and related vm options. > > Thanks! Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - merge master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'master' into refactor-dependent-cpu-extensions - Merge branch 'openjdk:master' into master - initial commit - add includes - ... and 3 more: https://git.openjdk.org/jdk/compare/d1ea6ea2...20598b77 ------------- Changes: https://git.openjdk.org/jdk/pull/27171/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27171&range=03 Stats: 138 lines in 2 files changed: 53 ins; 30 del; 55 mod Patch: https://git.openjdk.org/jdk/pull/27171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27171/head:pull/27171 PR: https://git.openjdk.org/jdk/pull/27171 From duke at openjdk.org Thu Sep 25 13:03:51 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 25 Sep 2025 13:03:51 GMT Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v16] In-Reply-To: References: Message-ID: <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com> > This PR will consolidate fixes of the following bugs: > > https://bugs.openjdk.org/browse/JDK-8361188 > https://bugs.openjdk.org/browse/JDK-8361189 > https://bugs.openjdk.org/browse/JDK-8361190 > https://bugs.openjdk.org/browse/JDK-8361191 > https://bugs.openjdk.org/browse/JDK-8361192 > https://bugs.openjdk.org/browse/JDK-8361193 > https://bugs.openjdk.org/browse/JDK-8361195 > > This PR depends on https://github.com/openjdk/jdk/pull/25971 > > For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188) > > For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193 > > For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192 > > For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191 > > For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190 Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: Resolves confict for when there is a merge with jdk-8158801 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26625/files - new: https://git.openjdk.org/jdk/pull/26625/files/e5753d14..8794db9a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=14-15 Stats: 55 lines in 1 file changed: 36 ins; 3 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/26625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625 PR: https://git.openjdk.org/jdk/pull/26625 From aph at openjdk.org Thu Sep 25 13:06:50 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 25 Sep 2025 13:06:50 GMT Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when running on 64-bit OSes [v10] In-Reply-To: <1-TdAQxYnMZgLXYbxzikqf6dxs7eCiLX7F9Q9tjt5do=.240fb307-23d6-4ed9-ac59-6ee58201c87f@github.com> References: <1-TdAQxYnMZgLXYbxzikqf6dxs7eCiLX7F9Q9tjt5do=.240fb307-23d6-4ed9-ac59-6ee58201c87f@github.com> Message-ID: On Sat, 20 Sep 2025 07:21:17 GMT, Thomas Stuefe wrote: > `size_t` carries a meaning: it is generally understood to be a measurement for a memory size, Strictly speaking, the size of the largest teoretically possible object. > We now have a distinction between reported memory size and size of memory the process can address Now? I'm old enough to remember when this was true on most PCs and minis. What goes around, comes around again. ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27335#issuecomment-3333869267 From erikj at openjdk.org Thu Sep 25 13:07:51 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 25 Sep 2025 13:07:51 GMT Subject: RFR: 8368250: [AIX] now ubsan vptr check is also possible (follow up of JDK-8354686) [v2] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 07:40:03 GMT, Joachim Kern wrote: >> After [JDK-8354686](https://bugs.openjdk.org/browse/JDK-8354686) the ubsan vptr checks still did not work. We finally found out, that they only work, if all linkage units are linked with the C++ compiler frontend as linker, especially the main executables (java, javac, ...) which are linked with the C compiler frontend. >> So for a ubsan enabled build on AIX we let everything link with the C++ compiler frontend. >> Background: The C++ compiler frontend inherently adds special static libraries which the C compiler does not. This results in missing symbols when trying to start a program and its shared libraries, when they were linked in mixed mode. > > Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: > > indentation and typo Build changes look ok. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27468#pullrequestreview-3267557349 From mli at openjdk.org Thu Sep 25 13:17:12 2025 From: mli at openjdk.org (Hamlin Li) Date: Thu, 25 Sep 2025 13:17:12 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v7] In-Reply-To: References: <6xTzmgEcZfGmJkvGt0yvg7iqc_LmuAZb4Y6m5IDUOX8=.518950d7-aadc-487a-a33d-66ba7f2209f4@github.com> Message-ID: On Wed, 24 Sep 2025 15:29:05 GMT, Ludovic Henry wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> remove explicit cpu feature index in RV_EXT_FEATURE_FLAGS > > LGTM! Hey @luhenry @RealFYang , I got another pr refactoring refactor dependent cpu extensions in VM_Version https://github.com/openjdk/jdk/pull/27171, could you please also have a look? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27152#issuecomment-3333947988 From alanb at openjdk.org Thu Sep 25 13:30:34 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 25 Sep 2025 13:30:34 GMT Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v16] In-Reply-To: <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com> References: <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com> Message-ID: On Thu, 25 Sep 2025 13:03:51 GMT, Khalid Boulanouare wrote: >> This PR will consolidate fixes of the following bugs: >> >> https://bugs.openjdk.org/browse/JDK-8361188 >> https://bugs.openjdk.org/browse/JDK-8361189 >> https://bugs.openjdk.org/browse/JDK-8361190 >> https://bugs.openjdk.org/browse/JDK-8361191 >> https://bugs.openjdk.org/browse/JDK-8361192 >> https://bugs.openjdk.org/browse/JDK-8361193 >> https://bugs.openjdk.org/browse/JDK-8361195 >> >> This PR depends on https://github.com/openjdk/jdk/pull/25971 >> >> For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188) >> >> For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193 >> >> For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192 >> >> For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191 >> >> For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190 > > Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: > > Resolves confict for when there is a merge with jdk-8158801 What is this about? The PR suggests 500+ commits and 300+ files changed but I think it's just a change to some AWT tests. Can you sync up the branch so that it only contains the changes to the AWT tests that you want to change, and remove all the labels except "client" as it will otherwise broadcast to all the mailing lists. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26625#issuecomment-3334044893 From bulasevich at openjdk.org Thu Sep 25 13:35:53 2025 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Thu, 25 Sep 2025 13:35:53 GMT Subject: RFR: 8359378: aarch64: crash when using -XX:+UseFPUForSpilling In-Reply-To: <0MbLaZYRoz-raa9x1eZycxeHE7mvPiGJujQpg8vBdek=.e3483c47-ad65-4d09-baf5-2db9b780669d@github.com> References: <0MbLaZYRoz-raa9x1eZycxeHE7mvPiGJujQpg8vBdek=.e3483c47-ad65-4d09-baf5-2db9b780669d@github.com> Message-ID: On Wed, 17 Sep 2025 16:19:12 GMT, Boris Ulasevich wrote: > AArch64 BarrierSetAssembler path assumes only FP/vector ideal regs reach the FP spill/restore encoding. With -XX:+UseFPUForSpilling Register Allocator may allocate scalar values in FP registers. When such values (Op_RegI/Op_RegN/Op_RegL/Op_RegP) hit `BarrierSetAssembler::encode_float_vector_register_size`, we trip ShouldNotReachHere in release build and **"unexpected ideal register"** assertion in debug build. > > Fix: teach the encoder to handle scalar ideal regs when they physically live in FP regs: > - treat Op_RegI / Op_RegN as 32-bit (single slot) - same class as Op_RegF > - treat Op_RegL / Op_RegP as 64-bit (two slots) - same class as Op_RegD > > Related: > - reproduced since #19746 > - spilling logic: > - #18967 > - #17977 > > Testing: tier1-3 with javaoptions -Xcomp -Xbatch -XX:+UseFPUForSpilling on AARCH Good. Thanks for reviewing! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27350#issuecomment-3334091938 From bulasevich at openjdk.org Thu Sep 25 13:38:15 2025 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Thu, 25 Sep 2025 13:38:15 GMT Subject: Integrated: 8359378: aarch64: crash when using -XX:+UseFPUForSpilling In-Reply-To: <0MbLaZYRoz-raa9x1eZycxeHE7mvPiGJujQpg8vBdek=.e3483c47-ad65-4d09-baf5-2db9b780669d@github.com> References: <0MbLaZYRoz-raa9x1eZycxeHE7mvPiGJujQpg8vBdek=.e3483c47-ad65-4d09-baf5-2db9b780669d@github.com> Message-ID: On Wed, 17 Sep 2025 16:19:12 GMT, Boris Ulasevich wrote: > AArch64 BarrierSetAssembler path assumes only FP/vector ideal regs reach the FP spill/restore encoding. With -XX:+UseFPUForSpilling Register Allocator may allocate scalar values in FP registers. When such values (Op_RegI/Op_RegN/Op_RegL/Op_RegP) hit `BarrierSetAssembler::encode_float_vector_register_size`, we trip ShouldNotReachHere in release build and **"unexpected ideal register"** assertion in debug build. > > Fix: teach the encoder to handle scalar ideal regs when they physically live in FP regs: > - treat Op_RegI / Op_RegN as 32-bit (single slot) - same class as Op_RegF > - treat Op_RegL / Op_RegP as 64-bit (two slots) - same class as Op_RegD > > Related: > - reproduced since #19746 > - spilling logic: > - #18967 > - #17977 > > Testing: tier1-3 with javaoptions -Xcomp -Xbatch -XX:+UseFPUForSpilling on AARCH This pull request has now been integrated. Changeset: 2b451131 Author: Boris Ulasevich URL: https://git.openjdk.org/jdk/commit/2b451131a57dc7080c4ccb77d6cb5a96ee24d891 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8359378: aarch64: crash when using -XX:+UseFPUForSpilling Reviewed-by: aph, rcastanedalo ------------- PR: https://git.openjdk.org/jdk/pull/27350 From mbaesken at openjdk.org Thu Sep 25 13:50:35 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 25 Sep 2025 13:50:35 GMT Subject: RFR: 8368250: [AIX] now ubsan vptr check is also possible (follow up of JDK-8354686) [v2] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 07:40:03 GMT, Joachim Kern wrote: >> After [JDK-8354686](https://bugs.openjdk.org/browse/JDK-8354686) the ubsan vptr checks still did not work. We finally found out, that they only work, if all linkage units are linked with the C++ compiler frontend as linker, especially the main executables (java, javac, ...) which are linked with the C compiler frontend. >> So for a ubsan enabled build on AIX we let everything link with the C++ compiler frontend. >> Background: The C++ compiler frontend inherently adds special static libraries which the C compiler does not. This results in missing symbols when trying to start a program and its shared libraries, when they were linked in mixed mode. > > Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: > > indentation and typo Looks like we get now ALWAYS ` -Wl,-bcdtors:mbr::s` into the AIX link flags, is that observation correct? So the change does not only touch ubsan but all linkage on this platform ? What are the pros and cons ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27468#issuecomment-3334193844 From duke at openjdk.org Thu Sep 25 14:00:08 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 25 Sep 2025 14:00:08 GMT Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v17] In-Reply-To: References: Message-ID: > This PR will consolidate fixes of the following bugs: > > https://bugs.openjdk.org/browse/JDK-8361188 > https://bugs.openjdk.org/browse/JDK-8361189 > https://bugs.openjdk.org/browse/JDK-8361190 > https://bugs.openjdk.org/browse/JDK-8361191 > https://bugs.openjdk.org/browse/JDK-8361192 > https://bugs.openjdk.org/browse/JDK-8361193 > https://bugs.openjdk.org/browse/JDK-8361195 > > This PR depends on https://github.com/openjdk/jdk/pull/25971 > > For test : java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java, the fix suggested is to return false in method isValidForPixelCheck for embedded frame, in which case the component is set to null. For more details see bug: [JDK-8361188](https://bugs.openjdk.org/browse/JDK-8361188) > > For test : test/jdk/java/awt/Mixing/AWT_Mixing/MixingPanelsResizing.java, I had to create a a tolerance color matching method for mac for the tests to pass. Also, the jbuttons needed to have different color than the color of the background frame, in order for test to pass. For more detail see bug: https://bugs.openjdk.org/browse/JDK-8361193 > > For test : test/jdk/java/awt/Mixing/AWT_Mixing/JSplitPaneOverlapping.java, it seems that color selected for lightweight component matches the background color of the frame. And this will cause the test to fail when matching colors. Choosing any color different than the background color will get the test to pass. For more details, see bug: https://bugs.openjdk.org/browse/JDK-8361192 > > For test test/jdk/java/awt/Mixing/AWT_Mixing/JPopupMenuOverlapping.java, it looks like the frame when visible, the popup test does not work properly. The frame needs to be hidden for the test to click on popup. For more details see bug: https://bugs.openjdk.org/browse/JDK-8361191 > > For test test/jdk/java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java, the test runs successfully but it times out after the default 2 minutes of jtreg. increasing the timeout to 3 minutes get the test to pass. For more details please refer to bug: https://bugs.openjdk.org/browse/JDK-8361190 Khalid Boulanouare has updated the pull request incrementally with three additional commits since the last revision: - Merge branch 'openjdk:master' into jdk-8360498 - 8359378: aarch64: crash when using -XX:+UseFPUForSpilling Reviewed-by: aph, rcastanedalo - 8367103: RISC-V: store cpu features in a bitmap Reviewed-by: fyang, luhenry ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26625/files - new: https://git.openjdk.org/jdk/pull/26625/files/8794db9a..69c087a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26625&range=15-16 Stats: 214 lines in 3 files changed: 142 ins; 4 del; 68 mod Patch: https://git.openjdk.org/jdk/pull/26625.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26625/head:pull/26625 PR: https://git.openjdk.org/jdk/pull/26625 From duke at openjdk.org Thu Sep 25 14:00:10 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Thu, 25 Sep 2025 14:00:10 GMT Subject: RFR: 8360498: [TEST_BUG] Some Mixing test continue to fail [v16] In-Reply-To: References: <5YzcczRe9VgQqc7POMiumcCnf6esXSQO6PpUbIuuxhA=.efcb29a6-3705-475d-901c-515838317bfe@github.com> Message-ID: On Thu, 25 Sep 2025 13:26:46 GMT, Alan Bateman wrote: >> Khalid Boulanouare has updated the pull request incrementally with one additional commit since the last revision: >> >> Resolves confict for when there is a merge with jdk-8158801 > > What is this about? The PR suggests 500+ commits and 300+ files changed but I think it's just a change to some AWT tests. Can you sync up the branch so that it only contains the changes to the AWT tests that you want to change, and remove all the labels except "client" as it will otherwise broadcast to all the mailing lists. @AlanBateman This PR is created based on PR https://github.com/openjdk/jdk/tree/pr/25971. My branch https://github.com/kboulanou/jdk/tree/jdk-8360498 is only 2 commits behind master. I am waiting for approval for PR https://github.com/openjdk/jdk/tree/pr/25971 for this PR to follow. Please let me know if there is anything I need to do. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26625#issuecomment-3334251324 From fyang at openjdk.org Thu Sep 25 14:03:06 2025 From: fyang at openjdk.org (Fei Yang) Date: Thu, 25 Sep 2025 14:03:06 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v5] In-Reply-To: References: Message-ID: <5ifcMDRbrAY-JWBn5zWvYVlM7fBFSQqcDJdGnMeJqpk=.a84d7061-3c19-45a6-bc45-568d5f99908b@github.com> On Thu, 25 Sep 2025 12:44:01 GMT, Robbin Ehn wrote: >> Hi please, consider. >> >> As ziccif require instructions to natural aligned to be atomic the 4 byte post call nop must be aligned. >> But I don't want to add a c.nop(2b) to align the nop(4b) which means the jal(r) must also be algined. >> As we have no utility to aligned the end of an instruction sequence the call it self is aligned and uses only 4 byte instructions. Only in the case where we could use an two c-instruction we may loose space. >> >> Thanks, Robbin > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Use relocation spec as marker. Latest version looks good. Thanks for the update. ------------- Marked as reviewed by fyang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27467#pullrequestreview-3267892811 From fyang at openjdk.org Thu Sep 25 14:03:07 2025 From: fyang at openjdk.org (Fei Yang) Date: Thu, 25 Sep 2025 14:03:07 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v5] In-Reply-To: References: <-pT1zmz8b5bJSxqrbKjx0lRtFYEsMpe6IMLU3AZmYWc=.dd07d932-ce37-4ff0-b86a-8889245b230a@github.com> Message-ID: <4zqtZqn82pIaPDPZD3H9LomYIwJtwkhtPOdJ4C8LczY=.256c50f9-e829-47f7-b5ad-7beb28262e74@github.com> On Thu, 25 Sep 2025 12:37:36 GMT, Robbin Ehn wrote: >> Yes, we need the relocation as we use that to patch the imms to the oopmaps. > > I changed to x86/pcc style and just use it as marker. No need to relocate location indepedent instructions. Yes, OK. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27467#discussion_r2379235468 From fandreuzzi at openjdk.org Thu Sep 25 14:05:35 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 25 Sep 2025 14:05:35 GMT Subject: RFR: 8368261: Serial: Use more precise nmethod scope during Full GC marking In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 11:08:39 GMT, Albert Mingkun Yang wrote: > Small patch of extracting out the nmethod-marking-scope logic in Serial full-gc. The new `NMethodMarkingScope` is placed in `nmethod.hpp` like its counterpart `ThreadsClaimTokenScope`. > > The new `struct` is almost identical to the existing `MarkScope`, so there is a planned followup PR that will address all other users of `StrongRootsScope` to use the recently introduced `ThreadsClaimTokenScope` and the new `NMethodMarkingScope` introduced in this PR, which would make it less abtract than the name `StrongRootsScope`. > > Test: tier1-3 src/hotspot/share/gc/serial/serialFullGC.cpp line 486: > 484: > 485: { > 486: StrongRootsScope srs(0); You could remove the include on `strongRootsScope.hpp` now ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27423#discussion_r2379248359 From fandreuzzi at openjdk.org Thu Sep 25 14:08:58 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 25 Sep 2025 14:08:58 GMT Subject: RFR: 8368261: Serial: Use more precise nmethod scope during Full GC marking In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 11:08:39 GMT, Albert Mingkun Yang wrote: > Small patch of extracting out the nmethod-marking-scope logic in Serial full-gc. The new `NMethodMarkingScope` is placed in `nmethod.hpp` like its counterpart `ThreadsClaimTokenScope`. > > The new `struct` is almost identical to the existing `MarkScope`, so there is a planned followup PR that will address all other users of `StrongRootsScope` to use the recently introduced `ThreadsClaimTokenScope` and the new `NMethodMarkingScope` introduced in this PR, which would make it less abtract than the name `StrongRootsScope`. > > Test: tier1-3 Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/27423#pullrequestreview-3267923670 From shade at openjdk.org Thu Sep 25 14:14:41 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 25 Sep 2025 14:14:41 GMT Subject: RFR: 8367910: Reduce warnings about unsupported classes in AOT cache creation In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 23:15:21 GMT, Ioi Lam wrote: > Currently AOT cache creation may print lots of warning (depending on the actions performed by the application's training run). Most of these warnings are harmless and are caused by JVM limitations; there's nothing that the user can do about them: > > > [1.096s][warning][aot] Skipping jdk/internal/event/Event: JFR event class > [1.096s][warning][aot] Skipping jdk/jfr/Event: JFR event class > [1.099s][warning][aot] Skipping jdk/proxy1/$Proxy14: Unsupported location > [1.100s][warning][aot] Skipping jdk/proxy1/$Proxy12: Unsupported location > [1.100s][warning][aot] Skipping jdk/proxy1/$Proxy11: Unsupported location > > > This PR moves most of these warnings to the "info" level. The only messages that are still logged in the "warning" levels are: > > - class is in an error state > - class failed verification > > These could indicate issues with the application so it's good to let the user know. Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27480#pullrequestreview-3267967579 From ayang at openjdk.org Thu Sep 25 14:18:31 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 25 Sep 2025 14:18:31 GMT Subject: RFR: 8368261: Serial: Use more precise nmethod scope during Full GC marking [v2] In-Reply-To: References: Message-ID: > Small patch of extracting out the nmethod-marking-scope logic in Serial full-gc. The new `NMethodMarkingScope` is placed in `nmethod.hpp` like its counterpart `ThreadsClaimTokenScope`. > > The new `struct` is almost identical to the existing `MarkScope`, so there is a planned followup PR that will address all other users of `StrongRootsScope` to use the recently introduced `ThreadsClaimTokenScope` and the new `NMethodMarkingScope` introduced in this PR, which would make it less abtract than the name `StrongRootsScope`. > > Test: tier1-3 Albert Mingkun Yang 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 three additional commits since the last revision: - review - Merge branch 'master' into sgc-nmethod-scope - sgc-nmethod-scope ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27423/files - new: https://git.openjdk.org/jdk/pull/27423/files/13d0772f..bd641747 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27423&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27423&range=00-01 Stats: 17512 lines in 472 files changed: 8113 ins; 6611 del; 2788 mod Patch: https://git.openjdk.org/jdk/pull/27423.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27423/head:pull/27423 PR: https://git.openjdk.org/jdk/pull/27423 From ayang at openjdk.org Thu Sep 25 14:18:32 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 25 Sep 2025 14:18:32 GMT Subject: RFR: 8368261: Serial: Use more precise nmethod scope during Full GC marking [v2] In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 13:42:32 GMT, Albert Mingkun Yang wrote: > Do you think it would be good to get rid of the scope starting at line 485. I have added a timer in that scope. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27423#issuecomment-3334368385 From stuefe at openjdk.org Thu Sep 25 14:45:19 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 25 Sep 2025 14:45:19 GMT Subject: RFR: 8368250: [AIX] now ubsan vptr check is also possible (follow up of JDK-8354686) [v2] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 07:40:03 GMT, Joachim Kern wrote: >> After [JDK-8354686](https://bugs.openjdk.org/browse/JDK-8354686) the ubsan vptr checks still did not work. We finally found out, that they only work, if all linkage units are linked with the C++ compiler frontend as linker, especially the main executables (java, javac, ...) which are linked with the C compiler frontend. >> So for a ubsan enabled build on AIX we let everything link with the C++ compiler frontend. >> Background: The C++ compiler frontend inherently adds special static libraries which the C compiler does not. This results in missing symbols when trying to start a program and its shared libraries, when they were linked in mixed mode. > > Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: > > indentation and typo Good! Ah, I missed @MBaesken s remark. Up to you, but I would do this only for ubsan. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27468#pullrequestreview-3268141835 From rehn at openjdk.org Thu Sep 25 14:45:19 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 25 Sep 2025 14:45:19 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v5] In-Reply-To: <5ifcMDRbrAY-JWBn5zWvYVlM7fBFSQqcDJdGnMeJqpk=.a84d7061-3c19-45a6-bc45-568d5f99908b@github.com> References: <5ifcMDRbrAY-JWBn5zWvYVlM7fBFSQqcDJdGnMeJqpk=.a84d7061-3c19-45a6-bc45-568d5f99908b@github.com> Message-ID: On Thu, 25 Sep 2025 14:00:53 GMT, Fei Yang wrote: > Latest version looks good. Thanks for the update. Thank you ! I did run tier1_loom, skynet and codecache/stress on latest. I'll start something for overnight! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27467#issuecomment-3334514923 From jsjolen at openjdk.org Thu Sep 25 14:50:04 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 25 Sep 2025 14:50:04 GMT Subject: RFR: 8340297: Use-after-free recognition for metaspace and class space [v7] In-Reply-To: References: Message-ID: On Tue, 26 Aug 2025 06:31:24 GMT, Thomas Stuefe wrote: >> This patch will give us use-after-free recognition for Metaspace and Class space. >> >> Currently, checks for Klass validity typically only perform a variation of `Metaspace::contains` and some other basic tests. These checks won't find cases where the Klass had been prematurely freed (e.g., after class redefinition), nor cases of unloaded classes if the underlying metaspace chunks have not been uncommitted, which is quite common. >> >> The patch also provides us with improved analysis methods in case we encounter problems. E.g., answering whether the Klass had been redefined or unloaded. >> >> The implementation aims to be simple, fast, and safe against false positives. There is a small but non-null chance that we could get false negatives, but that cannot be avoided. >> >> How this works: >> >> - In `class Metadata`, we introduce a 32-bit token that holds the type of the object (1). It replaces the old "is_valid" field of the same size. That one was of limited use since any non-null garbage in those four bytes would be read as valid. >> - To check a Metadata for validity, the token is checked. Checks are done with SafeFetch, so they can be done with questionable pointers (e.g. into uncommitted metaspace after class unloading) >> - When metaspace is freed (bulk free after class unloading), the released chunks are zapped, destroying all tokens in the area. >> - When metaspace is freed (prematurely, e.g., after class redefinition), the released blocks are zapped. >> - The new checks replace Metadata::is_valid and supplement some other metadata checks done in GCs >> >> Testing: The patch has been extensively tested manually, at Oracle, and SAP. Tests were thorough to not only catch errors in the patch, but also to see if the patch would uncover a lot of existing sleeper bugs. So far, we only found a single bug in Shenandoah. >> >> Note: I did not yet hook up the new test to c1/c2 compiled code (there are already unimplemented functions for that). That is possible, but left for a later RFE. > > Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Feedback Johan, Axel > - Merge branch 'master' into JDK-8340297-Metaspace-API-for-checking-if-address-is-in-use > - remove stray macro > - feedback Caspar > - Merge branch 'master' into JDK-8340297-Metaspace-API-for-checking-if-address-is-in-use > - Feedback Johan > - Merge branch 'openjdk:master' into JDK-8340297-Metaspace-API-for-checking-if-address-is-in-use > - merge master > - copyrights > - fix big-endian problem on AIX > - ... and 7 more: https://git.openjdk.org/jdk/compare/e5ec4641...72954f87 This seems fine to me. I was hoping to see if someone else would chime in and be happy that this is being implemented. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25891#issuecomment-3334551653 From jsikstro at openjdk.org Thu Sep 25 14:58:38 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Thu, 25 Sep 2025 14:58:38 GMT Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when running on 64-bit OSes [v13] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 10:24:24 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. >> >> The issue is addressed by changing the output type of all related functions to `physical_memory_size_type`, which is an alias to `uint64_t`. >> >> Tested in tiers 1 - 5. > > Anton Artemov has updated the pull request incrementally with two additional commits since the last revision: > > - 8367485: Fixed new line after typedef. > - 8367485: Fixed comment in global definitions. I'm not a huge fan of the verbosity the long typename brings with it but I think this is a good compromise. src/hotspot/share/utilities/globalDefinitions.hpp line 423: > 421: // This typedef is to address the issue of running a 32-bit VM on a 64-bit platform. In this case > 422: // the amount of physical memory may not fit in size_t, so we have to have a larger type. Once 32-bit > 423: // is depricated, one can use size_t. It's not only 32-bit VM on a 64-bit platform, it's 32-bit VM in general, since we can have an issue on both: 1) a 64-bit platform, and 2) a 32-bit (ARM) platform with LPAE enabled. ------------- Marked as reviewed by jsikstro (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27335#pullrequestreview-3268169759 PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2379430634 From stuefe at openjdk.org Thu Sep 25 15:01:53 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 25 Sep 2025 15:01:53 GMT Subject: RFR: 8340297: Use-after-free recognition for metaspace and class space [v8] In-Reply-To: References: Message-ID: > This patch will give us use-after-free recognition for Metaspace and Class space. > > Currently, checks for Klass validity typically only perform a variation of `Metaspace::contains` and some other basic tests. These checks won't find cases where the Klass had been prematurely freed (e.g., after class redefinition), nor cases of unloaded classes if the underlying metaspace chunks have not been uncommitted, which is quite common. > > The patch also provides us with improved analysis methods in case we encounter problems. E.g., answering whether the Klass had been redefined or unloaded. > > The implementation aims to be simple, fast, and safe against false positives. There is a small but non-null chance that we could get false negatives, but that cannot be avoided. > > How this works: > > - In `class Metadata`, we introduce a 32-bit token that holds the type of the object (1). It replaces the old "is_valid" field of the same size. That one was of limited use since any non-null garbage in those four bytes would be read as valid. > - To check a Metadata for validity, the token is checked. Checks are done with SafeFetch, so they can be done with questionable pointers (e.g. into uncommitted metaspace after class unloading) > - When metaspace is freed (bulk free after class unloading), the released chunks are zapped, destroying all tokens in the area. > - When metaspace is freed (prematurely, e.g., after class redefinition), the released blocks are zapped. > - The new checks replace Metadata::is_valid and supplement some other metadata checks done in GCs > > Testing: The patch has been extensively tested manually, at Oracle, and SAP. Tests were thorough to not only catch errors in the patch, but also to see if the patch would uncover a lot of existing sleeper bugs. So far, we only found a single bug in Shenandoah. > > Note: I did not yet hook up the new test to c1/c2 compiled code (there are already unimplemented functions for that). That is possible, but left for a later RFE. Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - Merge master - Feedback Johan, Axel - Merge branch 'master' into JDK-8340297-Metaspace-API-for-checking-if-address-is-in-use - remove stray macro - feedback Caspar - Merge branch 'master' into JDK-8340297-Metaspace-API-for-checking-if-address-is-in-use - Feedback Johan - Merge branch 'openjdk:master' into JDK-8340297-Metaspace-API-for-checking-if-address-is-in-use - merge master - copyrights - ... and 8 more: https://git.openjdk.org/jdk/compare/569e7808...b957115c ------------- Changes: https://git.openjdk.org/jdk/pull/25891/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25891&range=07 Stats: 483 lines in 26 files changed: 399 ins; 27 del; 57 mod Patch: https://git.openjdk.org/jdk/pull/25891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25891/head:pull/25891 PR: https://git.openjdk.org/jdk/pull/25891 From stuefe at openjdk.org Thu Sep 25 15:01:57 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 25 Sep 2025 15:01:57 GMT Subject: RFR: 8340297: Use-after-free recognition for metaspace and class space [v7] In-Reply-To: References: Message-ID: <2oaWclzgGFStrUXu78vtrdOZxt0ilCTuQ93EHZ_zuH4=.661624db-b481-4ed2-bfef-76a7b269ef65@github.com> On Thu, 25 Sep 2025 14:47:38 GMT, Johan Sj?len wrote: > This seems fine to me. I was hoping to see if someone else would chime in and be happy that this is being implemented. Thank you, Johan! I am gone for a longer vacation next month and won't integrate anything before that. But I'd be still happy for reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25891#issuecomment-3334590912 From vaivanov at openjdk.org Thu Sep 25 15:05:31 2025 From: vaivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 25 Sep 2025 15:05:31 GMT Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays [v7] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 15:41:48 GMT, Vladimir Ivanov wrote: >> On the SRF platform after PR https://github.com/openjdk/jdk/pull/26974 the fill intrinsics used by default. >> For some types/ sizes scores for the ArrayFill test reports ~2x drop due to a lot of the 'MEM_UOPS_RETIRED.SPLIT_STORES' events. For example, the 'good' case for the ArraysFill.testCharFill with size=8195 reports numbers like >> MEM_UOPS_RETIRED.SPLIT_LOADS | 22.6711 >> MEM_UOPS_RETIRED.SPLIT_STORES | 4.0859 >> while for 'bad' case these metrics are >> MEM_UOPS_RETIRED.SPLIT_LOADS | 69.1785 >> MEM_UOPS_RETIRED.SPLIT_STORES | 259200.3659 >> >> With alignment for the cache line size no score drops due to split_stores but small reduction may be reported for 'good' cases due to extra instructions in the intrinsic. The default options set was used for testing with '-XX:-OptimizeFill' for compiled code and with '-XX:+OptimizeFill' to force intrinsic. >> SRF 6740E | Size | compiled code| patched intrinsic| patched/compiled >> -- | -- | -- | -- | -- >> ArraysFill.testByteFill | 16 | 152031.2 | 157001.2 | 1.03 >> ArraysFill.testByteFill | 31 | 125795.9 | 177399.2 | 1.41 >> ArraysFill.testByteFill | 250 | 57961.69 | 120981.9 | 2.09 >> ArraysFill.testByteFill | 266 | 44900.15 | 147893.8 | 3.29 >> ArraysFill.testByteFill | 511 | 61908.17 | 129830.1 | 2.10 >> ArraysFill.testByteFill | 2047 | 32255.51 | 41986.6 | 1.30 >> ArraysFill.testByteFill | 2048 | 31928.97 | 42154.3 | 1.32 >> ArraysFill.testByteFill | 8195 | 10690.15 | 11036.3 | 1.03 >> ArraysFill.testIntFill | 16 | 145030.7 | 318796.9 | 2.20 >> ArraysFill.testIntFill | 31 | 134138.4 | 212487 | 1.58 >> ArraysFill.testIntFill | 250 | 74179.23 | 79522.66 | 1.07 >> ArraysFill.testIntFill | 266 | 68112.72 | 60116.49 | 0.88 >> ArraysFill.testIntFill | 511 | 39693.28 | 36225.09 | 0.91 >> ArraysFill.testIntFill | 2047 | 11504.14 | 10616.91 | 0.92 >> ArraysFill.testIntFill | 2048 | 11244.71 | 10969.14 | 0.98 >> ArraysFill.testIntFill | 8195 | 2751.289 | 2692.216 | 0.98 >> ArraysFill.testLongFill | 16 | 212532.5 | 212526 | 1.00 >> ArraysFill.testLongFill | 31 | 137432.4 | 137283.3 | 1.00 >> ArraysFill.testLongFill | 250 | 43185 | 43159.78 | 1.00 >> ArraysFill.testLongFill | 266 | 42172.22 | 42170.5 | 1.00 >> ArraysFill.testLongFill | 511 | 23370.15 | 23370.86 | 1.00 >> ArraysFill.testLongFill | 2047 | 6123.008 | 6122.73 | 1.00 >> ArraysFill.testLongFill | 2048 | 5793.722 | 5792.855 | 1.00 >> ArraysFill.testLongFill | 8195 | 616.552 | 616.585 | 1.00 >> ArraysFill.testShortFill | 16 | 152088.6 | 265646.1 | 1.75 >> ArraysFill.testShortFill | 31 | 1... > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays Thanks for your review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26747#issuecomment-3334617498 From duke at openjdk.org Thu Sep 25 15:05:32 2025 From: duke at openjdk.org (duke) Date: Thu, 25 Sep 2025 15:05:32 GMT Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays [v7] In-Reply-To: References: Message-ID: <1ly-tCIdPUVIOThw_p9DMe89VlfWhopr2bXla08PceA=.8ac6cc87-b04d-49da-ad05-9bd74c1991a8@github.com> On Wed, 24 Sep 2025 15:41:48 GMT, Vladimir Ivanov wrote: >> On the SRF platform after PR https://github.com/openjdk/jdk/pull/26974 the fill intrinsics used by default. >> For some types/ sizes scores for the ArrayFill test reports ~2x drop due to a lot of the 'MEM_UOPS_RETIRED.SPLIT_STORES' events. For example, the 'good' case for the ArraysFill.testCharFill with size=8195 reports numbers like >> MEM_UOPS_RETIRED.SPLIT_LOADS | 22.6711 >> MEM_UOPS_RETIRED.SPLIT_STORES | 4.0859 >> while for 'bad' case these metrics are >> MEM_UOPS_RETIRED.SPLIT_LOADS | 69.1785 >> MEM_UOPS_RETIRED.SPLIT_STORES | 259200.3659 >> >> With alignment for the cache line size no score drops due to split_stores but small reduction may be reported for 'good' cases due to extra instructions in the intrinsic. The default options set was used for testing with '-XX:-OptimizeFill' for compiled code and with '-XX:+OptimizeFill' to force intrinsic. >> SRF 6740E | Size | compiled code| patched intrinsic| patched/compiled >> -- | -- | -- | -- | -- >> ArraysFill.testByteFill | 16 | 152031.2 | 157001.2 | 1.03 >> ArraysFill.testByteFill | 31 | 125795.9 | 177399.2 | 1.41 >> ArraysFill.testByteFill | 250 | 57961.69 | 120981.9 | 2.09 >> ArraysFill.testByteFill | 266 | 44900.15 | 147893.8 | 3.29 >> ArraysFill.testByteFill | 511 | 61908.17 | 129830.1 | 2.10 >> ArraysFill.testByteFill | 2047 | 32255.51 | 41986.6 | 1.30 >> ArraysFill.testByteFill | 2048 | 31928.97 | 42154.3 | 1.32 >> ArraysFill.testByteFill | 8195 | 10690.15 | 11036.3 | 1.03 >> ArraysFill.testIntFill | 16 | 145030.7 | 318796.9 | 2.20 >> ArraysFill.testIntFill | 31 | 134138.4 | 212487 | 1.58 >> ArraysFill.testIntFill | 250 | 74179.23 | 79522.66 | 1.07 >> ArraysFill.testIntFill | 266 | 68112.72 | 60116.49 | 0.88 >> ArraysFill.testIntFill | 511 | 39693.28 | 36225.09 | 0.91 >> ArraysFill.testIntFill | 2047 | 11504.14 | 10616.91 | 0.92 >> ArraysFill.testIntFill | 2048 | 11244.71 | 10969.14 | 0.98 >> ArraysFill.testIntFill | 8195 | 2751.289 | 2692.216 | 0.98 >> ArraysFill.testLongFill | 16 | 212532.5 | 212526 | 1.00 >> ArraysFill.testLongFill | 31 | 137432.4 | 137283.3 | 1.00 >> ArraysFill.testLongFill | 250 | 43185 | 43159.78 | 1.00 >> ArraysFill.testLongFill | 266 | 42172.22 | 42170.5 | 1.00 >> ArraysFill.testLongFill | 511 | 23370.15 | 23370.86 | 1.00 >> ArraysFill.testLongFill | 2047 | 6123.008 | 6122.73 | 1.00 >> ArraysFill.testLongFill | 2048 | 5793.722 | 5792.855 | 1.00 >> ArraysFill.testLongFill | 8195 | 616.552 | 616.585 | 1.00 >> ArraysFill.testShortFill | 16 | 152088.6 | 265646.1 | 1.75 >> ArraysFill.testShortFill | 31 | 1... > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays @IvaVladimir Your change (at version 3957771b4550647a02a0e6eebe9c9c6fa14d7f3e) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26747#issuecomment-3334623901 From ayang at openjdk.org Thu Sep 25 15:40:59 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 25 Sep 2025 15:40:59 GMT Subject: RFR: 8368261: Serial: Use more precise nmethod scope during Full GC marking [v3] In-Reply-To: References: Message-ID: > Small patch of extracting out the nmethod-marking-scope logic in Serial full-gc. The new `NMethodMarkingScope` is placed in `nmethod.hpp` like its counterpart `ThreadsClaimTokenScope`. > > The new `struct` is almost identical to the existing `MarkScope`, so there is a planned followup PR that will address all other users of `StrongRootsScope` to use the recently introduced `ThreadsClaimTokenScope` and the new `NMethodMarkingScope` introduced in this PR, which would make it less abtract than the name `StrongRootsScope`. > > Test: tier1-3 Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27423/files - new: https://git.openjdk.org/jdk/pull/27423/files/bd641747..599c5049 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27423&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27423&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27423.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27423/head:pull/27423 PR: https://git.openjdk.org/jdk/pull/27423 From ayang at openjdk.org Thu Sep 25 15:41:00 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 25 Sep 2025 15:41:00 GMT Subject: RFR: 8368261: Serial: Use more precise nmethod scope during Full GC marking [v3] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 14:13:59 GMT, Albert Mingkun Yang wrote: > > Do you think it would be good to get rid of the scope starting at line 485. > > I have added a timer in that scope. Reverted it to be done in another PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27423#issuecomment-3334740825 From stefank at openjdk.org Thu Sep 25 15:40:59 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 25 Sep 2025 15:40:59 GMT Subject: RFR: 8368261: Serial: Use more precise nmethod scope during Full GC marking [v3] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 15:37:29 GMT, Albert Mingkun Yang wrote: >> Small patch of extracting out the nmethod-marking-scope logic in Serial full-gc. The new `NMethodMarkingScope` is placed in `nmethod.hpp` like its counterpart `ThreadsClaimTokenScope`. >> >> The new `struct` is almost identical to the existing `MarkScope`, so there is a planned followup PR that will address all other users of `StrongRootsScope` to use the recently introduced `ThreadsClaimTokenScope` and the new `NMethodMarkingScope` introduced in this PR, which would make it less abtract than the name `StrongRootsScope`. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27423#pullrequestreview-3268374553 From fandreuzzi at openjdk.org Thu Sep 25 15:43:27 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Thu, 25 Sep 2025 15:43:27 GMT Subject: RFR: 8368261: Serial: Use more precise nmethod scope during Full GC marking [v3] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 15:40:59 GMT, Albert Mingkun Yang wrote: >> Small patch of extracting out the nmethod-marking-scope logic in Serial full-gc. The new `NMethodMarkingScope` is placed in `nmethod.hpp` like its counterpart `ThreadsClaimTokenScope`. >> >> The new `struct` is almost identical to the existing `MarkScope`, so there is a planned followup PR that will address all other users of `StrongRootsScope` to use the recently introduced `ThreadsClaimTokenScope` and the new `NMethodMarkingScope` introduced in this PR, which would make it less abtract than the name `StrongRootsScope`. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/27423#pullrequestreview-3268405335 From jkern at openjdk.org Thu Sep 25 15:45:31 2025 From: jkern at openjdk.org (Joachim Kern) Date: Thu, 25 Sep 2025 15:45:31 GMT Subject: RFR: 8368250: [AIX] now ubsan vptr check is also possible (follow up of JDK-8354686) [v2] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 13:48:22 GMT, Matthias Baesken wrote: > Looks like we get now ALWAYS ` -Wl,-bcdtors:mbr::s` into the AIX link flags, is that observation correct? So the change does not only touch ubsan but all linkage on this platform ? What are the pros and cons ? I got the advice from IBM, that we should use this link flag in any case. We just missed it in the initial porting to the new clang based Compiler. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27468#issuecomment-3334805925 From fjiang at openjdk.org Thu Sep 25 15:46:35 2025 From: fjiang at openjdk.org (Feilong Jiang) Date: Thu, 25 Sep 2025 15:46:35 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v5] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 12:44:01 GMT, Robbin Ehn wrote: >> Hi please, consider. >> >> As ziccif require instructions to natural aligned to be atomic the 4 byte post call nop must be aligned. >> But I don't want to add a c.nop(2b) to align the nop(4b) which means the jal(r) must also be algined. >> As we have no utility to aligned the end of an instruction sequence the call it self is aligned and uses only 4 byte instructions. Only in the case where we could use an two c-instruction we may loose space. >> >> Thanks, Robbin > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Use relocation spec as marker. Thanks! ------------- Marked as reviewed by fjiang (Committer). PR Review: https://git.openjdk.org/jdk/pull/27467#pullrequestreview-3268415500 From ayang at openjdk.org Thu Sep 25 15:52:53 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 25 Sep 2025 15:52:53 GMT Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when running on 64-bit OSes [v13] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 14:47:34 GMT, Joel Sikstr?m wrote: >> Anton Artemov has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8367485: Fixed new line after typedef. >> - 8367485: Fixed comment in global definitions. > > src/hotspot/share/utilities/globalDefinitions.hpp line 423: > >> 421: // This typedef is to address the issue of running a 32-bit VM on a 64-bit platform. In this case >> 422: // the amount of physical memory may not fit in size_t, so we have to have a larger type. Once 32-bit >> 423: // is depricated, one can use size_t. > > It's not only 32-bit VM on a 64-bit platform, it's 32-bit VM in general, since we can have an issue on both: 1) a 64-bit platform, and 2) a 32-bit (ARM) platform with LPAE enabled. Typo: "depricated". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2379615341 From ayang at openjdk.org Thu Sep 25 16:50:42 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 25 Sep 2025 16:50:42 GMT Subject: Integrated: 8368261: Serial: Use more precise nmethod scope during Full GC marking In-Reply-To: References: Message-ID: On Mon, 22 Sep 2025 11:08:39 GMT, Albert Mingkun Yang wrote: > Small patch of extracting out the nmethod-marking-scope logic in Serial full-gc. The new `NMethodMarkingScope` is placed in `nmethod.hpp` like its counterpart `ThreadsClaimTokenScope`. > > The new `struct` is almost identical to the existing `MarkScope`, so there is a planned followup PR that will address all other users of `StrongRootsScope` to use the recently introduced `ThreadsClaimTokenScope` and the new `NMethodMarkingScope` introduced in this PR, which would make it less abtract than the name `StrongRootsScope`. > > Test: tier1-3 This pull request has now been integrated. Changeset: 74122198 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/741221988e03d1710d3a73ab9c7764991f216fae Stats: 21 lines in 2 files changed: 14 ins; 5 del; 2 mod 8368261: Serial: Use more precise nmethod scope during Full GC marking Reviewed-by: stefank, fandreuzzi ------------- PR: https://git.openjdk.org/jdk/pull/27423 From ayang at openjdk.org Thu Sep 25 16:50:41 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 25 Sep 2025 16:50:41 GMT Subject: RFR: 8368261: Serial: Use more precise nmethod scope during Full GC marking [v3] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 15:40:59 GMT, Albert Mingkun Yang wrote: >> Small patch of extracting out the nmethod-marking-scope logic in Serial full-gc. The new `NMethodMarkingScope` is placed in `nmethod.hpp` like its counterpart `ThreadsClaimTokenScope`. >> >> The new `struct` is almost identical to the existing `MarkScope`, so there is a planned followup PR that will address all other users of `StrongRootsScope` to use the recently introduced `ThreadsClaimTokenScope` and the new `NMethodMarkingScope` introduced in this PR, which would make it less abtract than the name `StrongRootsScope`. >> >> Test: tier1-3 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27423#issuecomment-3335044813 From luhenry at openjdk.org Thu Sep 25 17:20:12 2025 From: luhenry at openjdk.org (Ludovic Henry) Date: Thu, 25 Sep 2025 17:20:12 GMT Subject: RFR: 8367253: RISC-V: refactor dependent cpu extensions [v4] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 13:03:19 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> >> Dependent extensions could be improved in several ways. >> >> Currently, the dependent cpu extensions are processed in 2 separate places: >> 1. update_flag() when calling VM_Version::setup_cpu_available_features() >> 2. at the end of VM_Version::common_initialize(). >> >> And, dependency relationship can only be expressed in (1:1) way, can not be expressed (1:N) way, but in fact some extensions can depend on several different other extensions, for example, zvfh depends on zvf and rvv. It's would be better to support this (1:N) relationship. >> >> So, this PR brings several benefits: >> 1. VM options directly related to CPU extensions are automatically set, and they are all set in one place. >> 2. keep synchronization between CPU extensions (information in RVFeatureValue) and and VM options. Previously, code in common_initialize wont' sync to RVFeatureValue, unless do it manually, which is error-prone. >> 3. support to express (1:N) dependency relationship among cpu extensions and related vm options. >> >> Thanks! >> >> >> ## Test >> >> >> $TEST_JDK/bin/java -XX:+UnlockExperimentalVMOptions -XX:-UseRVV -XX:+PrintFlagsFinal -version | grep -e UseRVV -e UseZvbc -e UseZvfh -e UseZvkn >> OpenJDK 64-Bit Server VM warning: Cannot enable UseZvbb on cpu without any of the supports: v (disabled) >> OpenJDK 64-Bit Server VM warning: Cannot enable UseZvbc on cpu without any of the supports: v (disabled) >> OpenJDK 64-Bit Server VM warning: Cannot enable UseZvfh on cpu without any of the supports: v (disabled), Zfh (enabled) >> bool UseRVV = false {ARCH diagnostic} {command line} >> bool UseZvbc = false {ARCH experimental} {default} >> bool UseZvfh = false {ARCH diagnostic} {default} >> bool UseZvkn = false {ARCH experimental} {default} >> >> >> >> $TEST_JDK/bin/java -XX:+UnlockExperimentalVMOptions -XX:-UseZfh -XX:+PrintFlagsFinal -version | grep -e UseRVV -e UseZvbc -e UseZvfh -e UseZvkn >> OpenJDK 64-Bit Server VM warning: Cannot enable UseZvfh on cpu without any of the supports: v (enabled), Zfh (disabled) >> bool UseRVV = true {ARCH diagnostic} {default} >> bool UseZvbc = true ... > > Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - merge master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'master' into refactor-dependent-cpu-extensions > - Merge branch 'openjdk:master' into master > - initial commit > - add includes > - ... and 3 more: https://git.openjdk.org/jdk/compare/d1ea6ea2...20598b77 Changes requested by luhenry (Committer). src/hotspot/cpu/riscv/vm_version_riscv.hpp line 141: > 139: stringStream ss; \ > 140: deps_string(ss, dep0, ##__VA_ARGS__); \ > 141: warning("Cannot enable " #flag " on cpu without any of the supports: %s", ss.as_string(true)); \ Suggestion: warning("Cannot enable " #flag ", it's missing dependent extension(s) %s", ss.as_string(true)); \ ------------- PR Review: https://git.openjdk.org/jdk/pull/27171#pullrequestreview-3268751253 PR Review Comment: https://git.openjdk.org/jdk/pull/27171#discussion_r2379820859 From jbhateja at openjdk.org Thu Sep 25 17:48:14 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 25 Sep 2025 17:48:14 GMT Subject: RFR: 8367780: Enable UseAPX on Intel CPUs only when both APX_F and APX_NCI_NDD_NF cpuid features are present [v4] In-Reply-To: References: <-cYOL5wwp8oSisK5utj0B7mHi0D_Ne0i_N_RI-bsbLk=.87c1bc5f-a6a3-4d4e-9530-fc91e676656f@github.com> Message-ID: On Thu, 25 Sep 2025 00:45:37 GMT, Srinivas Vamsi Parasa wrote: > > EMR>sde64 -dmr -ptr_raise -- java -XX:+PrintFlagsFinal -XX:+UnlockExperimentalVMOptions -XX:+UseAPX --version | grep APX > > OpenJDK 64-Bit Server VM warning: UseAPX is not supported on this CPU, setting it to false > > Hi Jatin, > > Thank for informing about this issue! Sorry about the SDE issue. Will inform you once the public version of SDE which supports this feature is avalible. > > Thanks, Vamsi Thanks @vamsi-parasa, BTW, there should not be any urgency to push a patch for future enhancement in the absence of software emulation :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27320#issuecomment-3335233685 From iklam at openjdk.org Thu Sep 25 20:02:58 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 25 Sep 2025 20:02:58 GMT Subject: RFR: 8367910: Reduce warnings about unsupported classes in AOT cache creation In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 02:30:53 GMT, David Holmes wrote: >> Currently AOT cache creation may print lots of warning (depending on the actions performed by the application's training run). Most of these warnings are harmless and are caused by JVM limitations; there's nothing that the user can do about them: >> >> >> [1.096s][warning][aot] Skipping jdk/internal/event/Event: JFR event class >> [1.096s][warning][aot] Skipping jdk/jfr/Event: JFR event class >> [1.099s][warning][aot] Skipping jdk/proxy1/$Proxy14: Unsupported location >> [1.100s][warning][aot] Skipping jdk/proxy1/$Proxy12: Unsupported location >> [1.100s][warning][aot] Skipping jdk/proxy1/$Proxy11: Unsupported location >> >> >> This PR moves most of these warnings to the "info" level. The only messages that are still logged in the "warning" levels are: >> >> - class is in an error state >> - class failed verification >> >> These could indicate issues with the application so it's good to let the user know. > > Seems reasonable. > > Thanks Thanks @dholmes-ora @vnkozlov @shipilev for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/27480#issuecomment-3335740737 From iklam at openjdk.org Thu Sep 25 20:02:59 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 25 Sep 2025 20:02:59 GMT Subject: Integrated: 8367910: Reduce warnings about unsupported classes in AOT cache creation In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 23:15:21 GMT, Ioi Lam wrote: > Currently AOT cache creation may print lots of warning (depending on the actions performed by the application's training run). Most of these warnings are harmless and are caused by JVM limitations; there's nothing that the user can do about them: > > > [1.096s][warning][aot] Skipping jdk/internal/event/Event: JFR event class > [1.096s][warning][aot] Skipping jdk/jfr/Event: JFR event class > [1.099s][warning][aot] Skipping jdk/proxy1/$Proxy14: Unsupported location > [1.100s][warning][aot] Skipping jdk/proxy1/$Proxy12: Unsupported location > [1.100s][warning][aot] Skipping jdk/proxy1/$Proxy11: Unsupported location > > > This PR moves most of these warnings to the "info" level. The only messages that are still logged in the "warning" levels are: > > - class is in an error state > - class failed verification > > These could indicate issues with the application so it's good to let the user know. This pull request has now been integrated. Changeset: 52e77784 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/52e777845f0a09b4c285131f1eff02dfbffa0d1f Stats: 50 lines in 8 files changed: 18 ins; 5 del; 27 mod 8367910: Reduce warnings about unsupported classes in AOT cache creation Reviewed-by: dholmes, kvn, shade ------------- PR: https://git.openjdk.org/jdk/pull/27480 From asmehra at openjdk.org Thu Sep 25 21:06:23 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Thu, 25 Sep 2025 21:06:23 GMT Subject: RFR: 8368693: Duplicate methods in vmClasses Message-ID: This patch removes some duplicate methods that check if a class is loaded in vmClasses. These methods are already present in the class (generated by the `_VM_CLASS_DECLARE` macro). ------------- Commit messages: - 8368693: Remove duplicate methods in vmClasses Changes: https://git.openjdk.org/jdk/pull/27503/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27503&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368693 Stats: 16 lines in 8 files changed: 0 ins; 6 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/27503.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27503/head:pull/27503 PR: https://git.openjdk.org/jdk/pull/27503 From coleenp at openjdk.org Thu Sep 25 21:19:43 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 25 Sep 2025 21:19:43 GMT Subject: RFR: 8368693: Duplicate methods in vmClasses In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 21:00:22 GMT, Ashutosh Mehra wrote: > This patch removes some duplicate methods that check if a class is loaded in vmClasses. These methods are already present in the class (generated by the `_VM_CLASS_DECLARE` macro). Looks good. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27503#pullrequestreview-3269493259 From liach at openjdk.org Thu Sep 25 21:37:00 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 25 Sep 2025 21:37:00 GMT Subject: RFR: 8368693: Duplicate methods in vmClasses In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 21:00:22 GMT, Ashutosh Mehra wrote: > This patch removes some duplicate methods that check if a class is loaded in vmClasses. These methods are already present in the class (generated by the `_VM_CLASS_DECLARE` macro). src/hotspot/share/memory/universe.cpp line 507: > 505: // ordinary object arrays, _objectArrayKlass will be loaded when > 506: // SystemDictionary::initialize(CHECK); is run. See the extra check > 507: // for Object_klass_is_loaded in objArrayKlassKlass::allocate_objArray_klass_impl. Should this comment update the outdated reference to be: Suggestion: // for Object_klass_is_loaded in ObjArrayKlass::allocate_objArray_klass. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27503#discussion_r2380378763 From dholmes at openjdk.org Thu Sep 25 21:47:31 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 25 Sep 2025 21:47:31 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v7] In-Reply-To: <4Qpoc_71yo7P8S5i7mNo-Neaia4zhQONf71WZpKqXmM=.575ac5a6-1796-4814-bdbe-e2a5091d27a1@github.com> References: <4Qpoc_71yo7P8S5i7mNo-Neaia4zhQONf71WZpKqXmM=.575ac5a6-1796-4814-bdbe-e2a5091d27a1@github.com> Message-ID: On Thu, 25 Sep 2025 05:59:59 GMT, Thomas Stuefe wrote: >> On Linux, ASAN only shows some internal thread designation on reports, e.g. `T49`, which is useless. >> >> This patch adds the ability to see the real internal JVM thread names or user-supplied Java thread names in ASAN. This makes it possible to correlate ASAN reports with hs-err file reports (if ASAN is run with `halt_on_error=0` to give us a chance to get an hs-err file) or with a thread dump done beforehand. >> >> Note that it can only show up to 15 characters, though. Therefore, the patch tries to be smart about names that end in digits: such numbers are preserved such that the truncation happens in the middle of the name, e.g.: >> >> `"MyAllocationWorkerThread#4411"` -> `"MyAllocat..4411"` >> >> This latter improvement now also applies to thread names in gdb, since they are subject to the same limitation. >> >> For a detailed analysis of why the old version, using libpthread's `pthread_setname_np`, is not sufficient for thread names in ASAN, please see the issue description. >> >> ----- >> >> Some examples from ASAN report: >> >> Before: >> >> WRITE of size 8 at 0x7b749d2d9190 thread T49 >> >> >> Now: >> >> WRITE of size 8 at 0x7bfc2f0d8380 thread T49 (MyThread#0) >> >> >> >> ==593899==ERROR: AddressSanitizer: attempting free .. in thread T76 (MyAllocati..29) > > Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: > > - reorder includes > - remove redundant pthread_setname call Looks good. Thanks for the updates. I just remembered something - will this work on Alpine Linux with Musl-C? src/hotspot/os/linux/os_linux.cpp line 4869: > 4867: // since this is the only way to make ASAN aware of our thread names. Even > 4868: // though ASAN intercepts both prctl and pthread_setname_np, it only processes > 4869: // the thread name given to the former. Suggestion: // the thread name given to the former. The two are equivalent when we only set // the name of the current thread, which is the case here. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27395#pullrequestreview-3269551455 PR Comment: https://git.openjdk.org/jdk/pull/27395#issuecomment-3336040943 PR Review Comment: https://git.openjdk.org/jdk/pull/27395#discussion_r2380390874 From dlong at openjdk.org Thu Sep 25 22:08:00 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 25 Sep 2025 22:08:00 GMT Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3] In-Reply-To: References: <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com> Message-ID: On Thu, 25 Sep 2025 06:48:52 GMT, Manuel H?ssig wrote: > I would rather keep this code as a debug only sanity check, but I would refactor it into a single function. Then the question remains what to do with the SA code, that still does nothing. I think we can do even better and get rid of adjust_unextended_sp, moving the debug check into get_deopt_original_pc. This moves the SA changes into shared code, and fixes the anomaly that s390 never called adjust_unextended_sp and thus never called the debug code to do the sanity check. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2380422777 From dlong at openjdk.org Fri Sep 26 00:23:28 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 26 Sep 2025 00:23:28 GMT Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v7] In-Reply-To: References: Message-ID: > 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: more cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27059/files - new: https://git.openjdk.org/jdk/pull/27059/files/10668bd7..814693fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=05-06 Stats: 361 lines in 18 files changed: 21 ins; 338 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27059.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27059/head:pull/27059 PR: https://git.openjdk.org/jdk/pull/27059 From dlong at openjdk.org Fri Sep 26 01:22:50 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 26 Sep 2025 01:22:50 GMT Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v8] In-Reply-To: References: Message-ID: > 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: copyright year update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27059/files - new: https://git.openjdk.org/jdk/pull/27059/files/814693fa..6a1062c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=06-07 Stats: 8 lines in 8 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/27059.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27059/head:pull/27059 PR: https://git.openjdk.org/jdk/pull/27059 From dzhang at openjdk.org Fri Sep 26 01:53:25 2025 From: dzhang at openjdk.org (Dingli Zhang) Date: Fri, 26 Sep 2025 01:53:25 GMT Subject: RFR: 8368722: Several vector load/store tests fail on riscv without support for misaligned vector access Message-ID: Hi, Can you help to review this patch? Thanks! In `*VectorLoadStoreTests.java`, `loadMemorySegmentMaskIOOBE` and `storeMemorySegmentMaskIOOBE` may fail because `int index = fi.apply((int) a.byteSize())` can generate random indices that result in misaligned addresses, leading to SIGBUS on hardware that disallows misaligned vector accesses. Some RISC-V hardware supports fast misaligned scalar accesses but not vector ones, which causes SIGBUS when executing these tests with misaligned vector memory operations. So we should adjusted index to align with the element byte size in these tests. ### Test (fastdebug) - [x] Run jdk_vector on k1 - [x] Run jdk_vector on x86_64 and ARM64 ------------- Commit messages: - 8368722: RISC-V: Several vector load/store tests fail on riscv without support for misaligned vector access Changes: https://git.openjdk.org/jdk/pull/27506/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27506&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368722 Stats: 62 lines in 31 files changed: 0 ins; 0 del; 62 mod Patch: https://git.openjdk.org/jdk/pull/27506.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27506/head:pull/27506 PR: https://git.openjdk.org/jdk/pull/27506 From duke at openjdk.org Fri Sep 26 03:13:52 2025 From: duke at openjdk.org (erifan) Date: Fri, 26 Sep 2025 03:13:52 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v8] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 10:11:47 GMT, Jatin Bhateja wrote: >> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction. >> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails. >> >> Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java). >> >> Vector API jtreg tests pass at AVX level 2, remaining validation in progress. >> >> Performance numbers: >> >> >> System : 13th Gen Intel(R) Core(TM) i3-1315U >> >> Baseline: >> Benchmark (size) Mode Cnt Score Error Units >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 9444.444 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 10009.319 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9081.926 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 6085.825 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 6505.378 ops/ms >> VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 6204.489 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 1651.334 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 1642.784 ops/ms >> VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1474.808 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 10399.394 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 10502.894 ops/ms >> VectorSliceB... > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Update callGenerator.hpp copyright year test/micro/org/openjdk/bench/jdk/incubator/vector/VectorSliceBenchmark.java line 137: > 135: @Benchmark > 136: public void shortVectorSliceWithConstantIndex1() { > 137: for (int i = 0; i < sspecies.loopBound(sdst.length); i += bspecies.length()) { Typo ? `bspecies` -> `sspecies` and the following cases. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2380745327 From wenanjian at openjdk.org Fri Sep 26 03:48:56 2025 From: wenanjian at openjdk.org (Anjian Wen) Date: Fri, 26 Sep 2025 03:48:56 GMT Subject: RFR: 8368724: RISC-V: Check if unaligned_access is enabled before use Message-ID: we can notice that the `unaligned_access.value()` can only be used when the `unaligned_access.enabled()` is true, so we add the check here before use Manually checked the result on platforms w/wo fast misaligned accesses by running: $java -XX:+PrintFlagsFinal -version | grep AvoidUnalignedAccess ------------- Commit messages: - RISC-V: Add unaligned access check Changes: https://git.openjdk.org/jdk/pull/27510/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27510&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368724 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27510.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27510/head:pull/27510 PR: https://git.openjdk.org/jdk/pull/27510 From fyang at openjdk.org Fri Sep 26 04:24:16 2025 From: fyang at openjdk.org (Fei Yang) Date: Fri, 26 Sep 2025 04:24:16 GMT Subject: RFR: 8368724: RISC-V: Check if unaligned_access is enabled before use In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 03:36:50 GMT, Anjian Wen wrote: > we can notice that the `unaligned_access.value()` can only be used when the `unaligned_access.enabled()` is true, so we add the check here before use > > Manually checked the result on platforms w/wo fast misaligned accesses by running: $java -XX:+PrintFlagsFinal -version | grep AvoidUnalignedAccess Looks reasonable. Thanks. ------------- Marked as reviewed by fyang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27510#pullrequestreview-3270088455 From dholmes at openjdk.org Fri Sep 26 04:49:14 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 26 Sep 2025 04:49:14 GMT Subject: RFR: 8368693: Duplicate methods in vmClasses In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 21:00:22 GMT, Ashutosh Mehra wrote: > This patch removes some duplicate methods that check if a class is loaded in vmClasses. These methods are already present in the class (generated by the `_VM_CLASS_DECLARE` macro). Good catch! LGTM. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27503#pullrequestreview-3270124049 From stuefe at openjdk.org Fri Sep 26 05:45:16 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 26 Sep 2025 05:45:16 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v7] In-Reply-To: References: <4Qpoc_71yo7P8S5i7mNo-Neaia4zhQONf71WZpKqXmM=.575ac5a6-1796-4814-bdbe-e2a5091d27a1@github.com> Message-ID: On Thu, 25 Sep 2025 21:45:01 GMT, David Holmes wrote: > I just remembered something - will this work on Alpine Linux with Musl-C? Should not matter, since prctl is a system call. But let me check quickly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27395#issuecomment-3336853379 From stuefe at openjdk.org Fri Sep 26 06:17:29 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 26 Sep 2025 06:17:29 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v7] In-Reply-To: References: <4Qpoc_71yo7P8S5i7mNo-Neaia4zhQONf71WZpKqXmM=.575ac5a6-1796-4814-bdbe-e2a5091d27a1@github.com> Message-ID: On Thu, 25 Sep 2025 21:45:01 GMT, David Holmes wrote: >> Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: >> >> - reorder includes >> - remove redundant pthread_setname call > > I just remembered something - will this work on Alpine Linux with Musl-C? @dholmes-ora yes, Alpine works. Thanks all for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27395#issuecomment-3336917255 From stuefe at openjdk.org Fri Sep 26 06:17:31 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 26 Sep 2025 06:17:31 GMT Subject: Integrated: 8368124: Show useful thread names in ASAN reports In-Reply-To: References: Message-ID: On Fri, 19 Sep 2025 18:00:43 GMT, Thomas Stuefe wrote: > On Linux, ASAN only shows some internal thread designation on reports, e.g. `T49`, which is useless. > > This patch adds the ability to see the real internal JVM thread names or user-supplied Java thread names in ASAN. This makes it possible to correlate ASAN reports with hs-err file reports (if ASAN is run with `halt_on_error=0` to give us a chance to get an hs-err file) or with a thread dump done beforehand. > > Note that it can only show up to 15 characters, though. Therefore, the patch tries to be smart about names that end in digits: such numbers are preserved such that the truncation happens in the middle of the name, e.g.: > > `"MyAllocationWorkerThread#4411"` -> `"MyAllocat..4411"` > > This latter improvement now also applies to thread names in gdb, since they are subject to the same limitation. > > For a detailed analysis of why the old version, using libpthread's `pthread_setname_np`, is not sufficient for thread names in ASAN, please see the issue description. > > ----- > > Some examples from ASAN report: > > Before: > > WRITE of size 8 at 0x7b749d2d9190 thread T49 > > > Now: > > WRITE of size 8 at 0x7bfc2f0d8380 thread T49 (MyThread#0) > > > > ==593899==ERROR: AddressSanitizer: attempting free .. in thread T76 (MyAllocati..29) This pull request has now been integrated. Changeset: a6638121 Author: Thomas Stuefe URL: https://git.openjdk.org/jdk/commit/a6638121211afd688a9e25b5cbadf2f1441b1e65 Stats: 50 lines in 5 files changed: 35 ins; 6 del; 9 mod 8368124: Show useful thread names in ASAN reports Reviewed-by: dholmes, mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/27395 From iklam at openjdk.org Fri Sep 26 06:22:55 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 26 Sep 2025 06:22:55 GMT Subject: RFR: 8368727: CDS custom loader support causes asserts during class unloading Message-ID: When loading a class `k` from the CDS archive on behalf of a custom class loader, we were calling `loader_data->add_class(k)` too early. If the loading of `k` fails, it may be in `loader_data->_klasses`, but `k->init_state()` will remain `allocated`. This causes an assert during class unloading: # assert(ik->is_loaded()) failed: class should be loaded 0x000000000b518eb8 V [libjvm.so+0xfa6bd5] InstanceKlass::unload_class(InstanceKlass*)+0x555 (instanceKlass.cpp:2870) V [libjvm.so+0xa790e3] ClassLoaderData::classes_do(void (*)(InstanceKlass*))+0xc3 (classLoaderData.cpp:441 The fix is to move the `loader_data->add_class(k)` call to `k->Klass::restore_unshareable_info()`. This is the same location as if `k` were loaded by the 3 built-in class loaders. This was discovered when running some JCK tests in AOT mode. I've added a reproducer as a jtreg test case. ------------- Commit messages: - fixed whitespaces - 8368727: CDS custom loader support causes asserts during class unloading Changes: https://git.openjdk.org/jdk/pull/27511/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27511&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368727 Stats: 66 lines in 5 files changed: 54 ins; 5 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27511.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27511/head:pull/27511 PR: https://git.openjdk.org/jdk/pull/27511 From fyang at openjdk.org Fri Sep 26 06:38:54 2025 From: fyang at openjdk.org (Fei Yang) Date: Fri, 26 Sep 2025 06:38:54 GMT Subject: RFR: 8368732: RISC-V: Detect support for misaligned vector access via hwprobe Message-ID: Hi, this is a followup change after [JDK-8368366](https://bugs.openjdk.org/browse/JDK-8368366). According to the latest RISC-V linux hardware probing syscall [1], the performance of misaligned memory accesses has been divided into two cases: `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` and `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` for scalar and vector respectively. This aligns `AlignVector` with `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF`. That is if the misaligned vector access is fast, we set `AlignVector` to false in the hope that it will save instructions handling address alignment thus improves performance. This choose to keep the use of `RISCV_HWPROBE_KEY_CPUPERF_0` which is now deprecated and returns similar values to `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` for backward compatibility with old linux kernels. Manually checked the result on platforms w/wo fast misaligned vector accesses by running: `$java -XX:+PrintFlagsFinal -version | grep AlignVector` [1] https://docs.kernel.org/arch/riscv/hwprobe.html ------------- Commit messages: - RISC-V: Detect support for misaligned vector access via hwprobe Changes: https://git.openjdk.org/jdk/pull/27512/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27512&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368732 Stats: 38 lines in 4 files changed: 28 ins; 1 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/27512.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27512/head:pull/27512 PR: https://git.openjdk.org/jdk/pull/27512 From mbaesken at openjdk.org Fri Sep 26 07:14:17 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 26 Sep 2025 07:14:17 GMT Subject: RFR: 8368250: [AIX] now ubsan vptr check is also possible (follow up of JDK-8354686) [v2] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 15:42:58 GMT, Joachim Kern wrote: > > Looks like we get now ALWAYS ` -Wl,-bcdtors:mbr::s` into the AIX link flags, is that observation correct? So the change does not only touch ubsan but all linkage on this platform ? What are the pros and cons ? > > I got the advice from IBM, that we should use this link flag in any case. We just missed it in the initial porting to the new clang based Compiler. So what does the added flag (especially in the 'normal' non-sanitizer enabled builds) and what's the benefit we get from it (so far we lived happily without it). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27468#issuecomment-3337085584 From mhaessig at openjdk.org Fri Sep 26 07:17:20 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Fri, 26 Sep 2025 07:17:20 GMT Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v8] In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 01:22:50 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: > > copyright year update I have one last nit below. Otherwise, this looks good to me. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Frame.java line 85: > 83: > 84: protected void adjustForDeopt() { > 85: if ( pc != null) { Suggestion: if (pc != null) { ------------- Marked as reviewed by mhaessig (Committer). PR Review: https://git.openjdk.org/jdk/pull/27059#pullrequestreview-3270357612 PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2381017332 From mhaessig at openjdk.org Fri Sep 26 07:17:21 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Fri, 26 Sep 2025 07:17:21 GMT Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v3] In-Reply-To: References: <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com> Message-ID: On Thu, 25 Sep 2025 22:05:10 GMT, Dean Long wrote: >> I would rather keep this code as a debug only sanity check, but I would refactor it into a single function. Then the question remains what to do with the SA code, that still does nothing. > >> I would rather keep this code as a debug only sanity check, but I would refactor it into a single function. Then the question remains what to do with the SA code, that still does nothing. > > I think we can do even better and get rid of adjust_unextended_sp, moving the debug check into get_deopt_original_pc. This moves the SA changes into shared code, and fixes the anomaly that s390 never called adjust_unextended_sp and thus never called the debug code to do the sanity check. That is indeed even better. Nice. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27059#discussion_r2381117772 From stuefe at openjdk.org Fri Sep 26 07:24:37 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 26 Sep 2025 07:24:37 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v7] In-Reply-To: References: <4Qpoc_71yo7P8S5i7mNo-Neaia4zhQONf71WZpKqXmM=.575ac5a6-1796-4814-bdbe-e2a5091d27a1@github.com> Message-ID: On Thu, 25 Sep 2025 21:45:01 GMT, David Holmes wrote: >> Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: >> >> - reorder includes >> - remove redundant pthread_setname call > > I just remembered something - will this work on Alpine Linux with Musl-C? @dholmes-ora sorry, I missed you comment change suggestion. Should I do that in a follow-up patch? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27395#issuecomment-3337120105 From sspitsyn at openjdk.org Fri Sep 26 07:26:31 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 26 Sep 2025 07:26:31 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 12:15:42 GMT, Johan Sj?len wrote: >> src/hotspot/share/oops/constantPool.hpp line 128: >> >>> 126: >>> 127: // The BSMAttributeEntries stores the state of the BootstrapMethods attribute. >>> 128: class BSMAttributeEntries { >> >> Nit: I'm thinking if it would make sense to rename it to `BSMEntries`. >> Then we could rename this as well: `BSMAttributeEntry` => `BSMEntry`. >> It feels like it will increase the readability as it is already clear that `BSMEntry` is about `BSM` attributes. > > Hmm, I don't want to go into renaming them in this PR. I think that's something that can be done separately. Why not? This PR is introducing these two classes. It is better to do in a simplified form. :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2381144985 From duke at openjdk.org Fri Sep 26 07:32:42 2025 From: duke at openjdk.org (Anton Artemov) Date: Fri, 26 Sep 2025 07:32:42 GMT Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when running on 64-bit OSes [v14] In-Reply-To: References: Message-ID: <3wQZ3ZsNCsP6GYOGSv83Y_ZuhyW6zsUaFkQjeiEtc8I=.5788cb9d-1633-428a-98d0-af37611ca052@github.com> > Hi, please consider the following changes: > > In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. > > The issue is addressed by changing the output type of all related functions to `physical_memory_size_type`, which is an alias to `uint64_t`. > > Tested in tiers 1 - 5. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8367485: Fixed typos in the comment. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27335/files - new: https://git.openjdk.org/jdk/pull/27335/files/4590bdb3..8601871e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27335&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27335&range=12-13 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27335.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27335/head:pull/27335 PR: https://git.openjdk.org/jdk/pull/27335 From duke at openjdk.org Fri Sep 26 07:32:44 2025 From: duke at openjdk.org (Anton Artemov) Date: Fri, 26 Sep 2025 07:32:44 GMT Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when running on 64-bit OSes [v13] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 15:50:23 GMT, Albert Mingkun Yang wrote: >> src/hotspot/share/utilities/globalDefinitions.hpp line 423: >> >>> 421: // This typedef is to address the issue of running a 32-bit VM on a 64-bit platform. In this case >>> 422: // the amount of physical memory may not fit in size_t, so we have to have a larger type. Once 32-bit >>> 423: // is depricated, one can use size_t. >> >> It's not only 32-bit VM on a 64-bit platform, it's 32-bit VM in general, since we can have an issue on both: 1) a 64-bit platform, and 2) a 32-bit (ARM) platform with LPAE enabled. > > Typo: "depricated". Fixed the comment, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27335#discussion_r2381153984 From sspitsyn at openjdk.org Fri Sep 26 07:58:41 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 26 Sep 2025 07:58:41 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v5] In-Reply-To: References: Message-ID: <2JW3Vh4F955tssSaTblMWKVVizigJPzftJIPyWnICKk=.b1ebe02a-38fc-4965-a46a-30b8a13c8a83@github.com> On Sat, 20 Sep 2025 05:58:50 GMT, Serguei Spitsyn wrote: >> You might want @sspitsyn to review the jvmtiRedefineClasses changes since he did this work for the existing operands arrays. > >> @coleenp said: You might want @sspitsyn to review the jvmtiRedefineClasses changes since he did this work for the existing operands arrays. > > Thanks. I'm looking at this update. > @sspitsyn , I applied most of your nits! Thanks! In fact, I like your refactoring but it'd be nice to make names right and consistent. :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27198#issuecomment-3337225511 From fyang at openjdk.org Fri Sep 26 08:11:11 2025 From: fyang at openjdk.org (Fei Yang) Date: Fri, 26 Sep 2025 08:11:11 GMT Subject: RFR: 8368732: RISC-V: Detect support for misaligned vector access via hwprobe [v2] In-Reply-To: References: Message-ID: > Hi, this is a followup change after [JDK-8368366](https://bugs.openjdk.org/browse/JDK-8368366). > > According to the latest RISC-V linux hardware probing syscall [1], the performance of misaligned memory accesses has been divided into two cases: `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` and `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` for scalar and vector respectively. > > This aligns `AlignVector` with `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF`. That is if the misaligned vector access is fast, we set `AlignVector` to false in the hope that it will save instructions handling address alignment thus improves performance. > > This choose to keep the use of `RISCV_HWPROBE_KEY_CPUPERF_0` which is now deprecated and returns similar values > to `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` for backward compatibility with old linux kernels. > > Manually checked the result on platforms w/wo fast misaligned vector accesses by running: > `$java -XX:+PrintFlagsFinal -version | grep AlignVector` > > [1] https://docs.kernel.org/arch/riscv/hwprobe.html Fei Yang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains three new commits since the last revision: - More white spaces - White spaces - 8368732: RISC-V: Detect support for misaligned vector access via hwprobe ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27512/files - new: https://git.openjdk.org/jdk/pull/27512/files/0777aa3f..45cbcd9e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27512&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27512&range=00-01 Stats: 15 lines in 1 file changed: 14 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27512.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27512/head:pull/27512 PR: https://git.openjdk.org/jdk/pull/27512 From mli at openjdk.org Fri Sep 26 08:19:32 2025 From: mli at openjdk.org (Hamlin Li) Date: Fri, 26 Sep 2025 08:19:32 GMT Subject: RFR: 8367253: RISC-V: refactor dependent cpu extensions [v5] In-Reply-To: References: Message-ID: > Hi, > Can you help to review this patch? > > Dependent extensions could be improved in several ways. > > Currently, the dependent cpu extensions are processed in 2 separate places: > 1. update_flag() when calling VM_Version::setup_cpu_available_features() > 2. at the end of VM_Version::common_initialize(). > > And, dependency relationship can only be expressed in (1:1) way, can not be expressed (1:N) way, but in fact some extensions can depend on several different other extensions, for example, zvfh depends on zvf and rvv. It's would be better to support this (1:N) relationship. > > So, this PR brings several benefits: > 1. VM options directly related to CPU extensions are automatically set, and they are all set in one place. > 2. keep synchronization between CPU extensions (information in RVFeatureValue) and and VM options. Previously, code in common_initialize wont' sync to RVFeatureValue, unless do it manually, which is error-prone. > 3. support to express (1:N) dependency relationship among cpu extensions and related vm options. > > Thanks! > > > ## Test > > > $TEST_JDK/bin/java -XX:+UnlockExperimentalVMOptions -XX:-UseRVV -XX:+PrintFlagsFinal -version | grep -e UseRVV -e UseZvbc -e UseZvfh -e UseZvkn > OpenJDK 64-Bit Server VM warning: Cannot enable UseZvbb on cpu without any of the supports: v (disabled) > OpenJDK 64-Bit Server VM warning: Cannot enable UseZvbc on cpu without any of the supports: v (disabled) > OpenJDK 64-Bit Server VM warning: Cannot enable UseZvfh on cpu without any of the supports: v (disabled), Zfh (enabled) > bool UseRVV = false {ARCH diagnostic} {command line} > bool UseZvbc = false {ARCH experimental} {default} > bool UseZvfh = false {ARCH diagnostic} {default} > bool UseZvkn = false {ARCH experimental} {default} > > > > $TEST_JDK/bin/java -XX:+UnlockExperimentalVMOptions -XX:-UseZfh -XX:+PrintFlagsFinal -version | grep -e UseRVV -e UseZvbc -e UseZvfh -e UseZvkn > OpenJDK 64-Bit Server VM warning: Cannot enable UseZvfh on cpu without any of the supports: v (enabled), Zfh (disabled) > bool UseRVV = true {ARCH diagnostic} {default} > bool UseZvbc = true {ARCH experimental} {default} > bool UseZvfh ... Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: minor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27171/files - new: https://git.openjdk.org/jdk/pull/27171/files/20598b77..0dd9f9c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27171&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27171&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27171/head:pull/27171 PR: https://git.openjdk.org/jdk/pull/27171 From mli at openjdk.org Fri Sep 26 08:19:36 2025 From: mli at openjdk.org (Hamlin Li) Date: Fri, 26 Sep 2025 08:19:36 GMT Subject: RFR: 8367253: RISC-V: refactor dependent cpu extensions [v4] In-Reply-To: References: Message-ID: <60VxpEdK8AsmkaP9x1OaiAJBouquuCg3u5nuZ7Es0d4=.0995b831-260a-4ef0-a28b-54a2f0b025f0@github.com> On Thu, 25 Sep 2025 17:15:38 GMT, Ludovic Henry wrote: >> Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: >> >> - merge master >> - Merge branch 'openjdk:master' into master >> - Merge branch 'openjdk:master' into master >> - Merge branch 'openjdk:master' into master >> - Merge branch 'openjdk:master' into master >> - Merge branch 'openjdk:master' into master >> - Merge branch 'master' into refactor-dependent-cpu-extensions >> - Merge branch 'openjdk:master' into master >> - initial commit >> - add includes >> - ... and 3 more: https://git.openjdk.org/jdk/compare/d1ea6ea2...20598b77 > > src/hotspot/cpu/riscv/vm_version_riscv.hpp line 141: > >> 139: stringStream ss; \ >> 140: deps_string(ss, dep0, ##__VA_ARGS__); \ >> 141: warning("Cannot enable " #flag " on cpu without any of the supports: %s", ss.as_string(true)); \ > > Suggestion: > > warning("Cannot enable " #flag ", it's missing dependent extension(s) %s", ss.as_string(true)); \ fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27171#discussion_r2381317140 From sgehwolf at openjdk.org Fri Sep 26 08:31:30 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 26 Sep 2025 08:31:30 GMT Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when running on 64-bit OSes [v14] In-Reply-To: <3wQZ3ZsNCsP6GYOGSv83Y_ZuhyW6zsUaFkQjeiEtc8I=.5788cb9d-1633-428a-98d0-af37611ca052@github.com> References: <3wQZ3ZsNCsP6GYOGSv83Y_ZuhyW6zsUaFkQjeiEtc8I=.5788cb9d-1633-428a-98d0-af37611ca052@github.com> Message-ID: On Fri, 26 Sep 2025 07:32:42 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. >> >> The issue is addressed by changing the output type of all related functions to `physical_memory_size_type`, which is an alias to `uint64_t`. >> >> Tested in tiers 1 - 5. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8367485: Fixed typos in the comment. Marked as reviewed by sgehwolf (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27335#pullrequestreview-3270831576 From jsikstro at openjdk.org Fri Sep 26 08:31:31 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Fri, 26 Sep 2025 08:31:31 GMT Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when running on 64-bit OSes [v14] In-Reply-To: <3wQZ3ZsNCsP6GYOGSv83Y_ZuhyW6zsUaFkQjeiEtc8I=.5788cb9d-1633-428a-98d0-af37611ca052@github.com> References: <3wQZ3ZsNCsP6GYOGSv83Y_ZuhyW6zsUaFkQjeiEtc8I=.5788cb9d-1633-428a-98d0-af37611ca052@github.com> Message-ID: On Fri, 26 Sep 2025 07:32:42 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. >> >> The issue is addressed by changing the output type of all related functions to `physical_memory_size_type`, which is an alias to `uint64_t`. >> >> Tested in tiers 1 - 5. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8367485: Fixed typos in the comment. Marked as reviewed by jsikstro (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27335#pullrequestreview-3270842326 From mli at openjdk.org Fri Sep 26 08:33:25 2025 From: mli at openjdk.org (Hamlin Li) Date: Fri, 26 Sep 2025 08:33:25 GMT Subject: RFR: 8368724: RISC-V: Check if unaligned_access is enabled before use In-Reply-To: References: Message-ID: <1Um6PaMwVL_OB6ZMfl2HEc7r7-0xuwTR4prgFKeepfo=.26d2deac-ad80-4e68-b4e3-b04a047261f6@github.com> On Fri, 26 Sep 2025 03:36:50 GMT, Anjian Wen wrote: > we can notice that the `unaligned_access.value()` can only be used when the `unaligned_access.enabled()` is true, so we add the check here before use > > Manually checked the result on platforms w/wo fast misaligned accesses by running: $java -XX:+PrintFlagsFinal -version | grep AvoidUnalignedAccess I think we're going to remove the `AvoidUnalignedAccesses`? And if `unaligned_access` is not enabled, then its value can not be `MISALIGNED_FAST`? If both above are true, then seems this check is not necessary? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27510#issuecomment-3337362224 From mli at openjdk.org Fri Sep 26 08:35:23 2025 From: mli at openjdk.org (Hamlin Li) Date: Fri, 26 Sep 2025 08:35:23 GMT Subject: RFR: 8368722: Several vector load/store tests fail on riscv without support for misaligned vector access In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 01:44:19 GMT, Dingli Zhang wrote: > Hi, > Can you help to review this patch? Thanks! > > In `*VectorLoadStoreTests.java`, `loadMemorySegmentMaskIOOBE` and `storeMemorySegmentMaskIOOBE` may fail because `int index = fi.apply((int) a.byteSize())` can generate random indices that result in misaligned addresses, leading to SIGBUS on hardware that disallows misaligned vector accesses. > > Some RISC-V hardware supports fast misaligned scalar accesses but not vector ones, which causes SIGBUS when executing these tests with misaligned vector memory operations. > > So we should adjusted index to align with the element byte size in these tests. > > ### Test > - [x] Run jdk_vector on k1 > - [x] Run jdk_vector on x86_64 and ARM64 Hey, not check the pr yet. It's better to have a `RISC-V: ` prefix in the issue's subject. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27506#issuecomment-3337368103 From mli at openjdk.org Fri Sep 26 08:39:26 2025 From: mli at openjdk.org (Hamlin Li) Date: Fri, 26 Sep 2025 08:39:26 GMT Subject: RFR: 8368732: RISC-V: Detect support for misaligned vector access via hwprobe [v2] In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 08:11:11 GMT, Fei Yang wrote: >> Hi, this is a followup change after [JDK-8368366](https://bugs.openjdk.org/browse/JDK-8368366). >> >> According to the latest RISC-V linux hardware probing syscall [1], the performance of misaligned memory accesses has been divided into two cases: `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` and `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` for scalar and vector respectively. >> >> This aligns `AlignVector` with `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF`. That is if the misaligned vector access is fast, we set `AlignVector` to false in the hope that it will save instructions handling address alignment thus improves performance. >> >> This choose to keep the use of `RISCV_HWPROBE_KEY_CPUPERF_0` which is now deprecated and returns similar values >> to `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` for backward compatibility with old linux kernels. >> >> Manually checked the result on platforms w/wo fast misaligned vector accesses by running: >> `$java -XX:+PrintFlagsFinal -version | grep AlignVector` >> >> [1] https://docs.kernel.org/arch/riscv/hwprobe.html > > Fei Yang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains three new commits since the last revision: > > - More white spaces > - White spaces > - 8368732: RISC-V: Detect support for misaligned vector access via hwprobe src/hotspot/cpu/riscv/vm_version_riscv.cpp line 181: > 179: } > 180: > 181: if (FLAG_IS_DEFAULT(AlignVector) && unaligned_vector.enabled()) { Seems this `unaligned_vector.enabled` is not necessary? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27512#discussion_r2381389978 From duke at openjdk.org Fri Sep 26 09:15:16 2025 From: duke at openjdk.org (Anton Artemov) Date: Fri, 26 Sep 2025 09:15:16 GMT Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when running on 64-bit OSes [v14] In-Reply-To: <3wQZ3ZsNCsP6GYOGSv83Y_ZuhyW6zsUaFkQjeiEtc8I=.5788cb9d-1633-428a-98d0-af37611ca052@github.com> References: <3wQZ3ZsNCsP6GYOGSv83Y_ZuhyW6zsUaFkQjeiEtc8I=.5788cb9d-1633-428a-98d0-af37611ca052@github.com> Message-ID: On Fri, 26 Sep 2025 07:32:42 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. >> >> The issue is addressed by changing the output type of all related functions to `physical_memory_size_type`, which is an alias to `uint64_t`. >> >> Tested in tiers 1 - 5. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8367485: Fixed typos in the comment. Thanks for reviews, I will integrate it on Monday. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27335#issuecomment-3337543328 From aboldtch at openjdk.org Fri Sep 26 09:18:50 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 26 Sep 2025 09:18:50 GMT Subject: RFR: 8367149: Add convenient construction for creating ad-hoc VMErrorCallback [v4] In-Reply-To: References: Message-ID: <2iAr1HxcBjhEHnEEjPkIn2j7B_kqtKX60WHhlTFsvSs=.d845ec08-41f9-420e-beba-9a52c56b9b6c@github.com> > Add a class OnVMError which uses the VMErrorCallback mechanism which is a convenient construction for creating ad-hoc VMErrorCallback which automatically calls the provided invocable f if a VM crash occurs within its lifetime. Can be used to instrument a build for more detailed contextual information gathering. Especially useful when hunting down intermittent bugs, or issues only reproducible in environments where access to a debugger is not readily available. Example use: > ```C++ > { > // Note the lambda is invoked after an error occurs within this thread, > // and during on_error's lifetime. If state prior to the crash is required, > // capture a copy of it first. > auto important_value = get_the_value(); > > OnVMError on_error([&](outputStream* st) { > // Dump the important bits. > st->print("Prior value: "); > important_value.print_on(st); > st->print("During crash: ") > get_the_value().print_on(st); > // Dump whole the whole state. > this->print_on(st); > }); > > // Sometimes doing a thing will crash the VM. > do_a_thing(); > } > > > C++17 class template argument deduction finally makes these sort of constructions ergonomic to use without the need for auto and helper construction methods. Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge tag 'jdk-26+17' into JDK-8367149 Added tag jdk-26+17 for changeset 2aafda19 - Replace ergonomic with convenient - Add a comment explaining the deduction rules - Skip multiple inheritance and allow more than lambda like callables. - Update doc example - 8367149: Add ergonomic construction for creating ad-hoc VMErrorCallback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27159/files - new: https://git.openjdk.org/jdk/pull/27159/files/c6e6ce91..f2f3a1c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27159&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27159&range=02-03 Stats: 164284 lines in 1828 files changed: 133911 ins; 19090 del; 11283 mod Patch: https://git.openjdk.org/jdk/pull/27159.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27159/head:pull/27159 PR: https://git.openjdk.org/jdk/pull/27159 From aph at openjdk.org Fri Sep 26 09:41:07 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 26 Sep 2025 09:41:07 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v9] In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: <3lS-ZY4HxoaCq9XlW3MT9Zkq1sqJnsgPSNIznkeCzSw=.3af36d30-5ca8-4d1c-9185-01a3c2f59aef@github.com> > In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. > > Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. > > This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. > > The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. > > We mark all sites that we know will write to code memory with > `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. > > We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. > > It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. > > One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ... Andrew Haley has updated the pull request incrementally with six additional commits since the last revision: - More - Fix test - Review comments - Review commwnts - Test - More ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26562/files - new: https://git.openjdk.org/jdk/pull/26562/files/c25fbefa..6a379f10 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=07-08 Stats: 93 lines in 12 files changed: 54 ins; 9 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/26562.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26562/head:pull/26562 PR: https://git.openjdk.org/jdk/pull/26562 From aph at openjdk.org Fri Sep 26 09:41:07 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 26 Sep 2025 09:41:07 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v4] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Thu, 21 Aug 2025 17:36:28 GMT, Andrew Haley wrote: >>> We change mode when we're _all but certain_ that we need to. That seems right to me. If the mode doesn't need changing because it's already set, that's OK. Why do you think this might be a problem? >> >> My concern is that if we have code that needs a specific mode, but it is not obvious at that piece of code that this is the case, then things will work fine if somewhere on the path to that code we set the right mode. But if we introduce a new path to that code that might not be the case and so we will introduce a new place where we switch modes. That can lead to redundancy. The whole thing (as it has from day one) seems ad-hoc. >> >> But if the proposed scheme performs better in general, and is not obviously "worse" from the ad-hoc perspective then ... > >> My concern is that if we have code that needs a specific mode, but it is not obvious at that piece of code that this is the case, then things will work fine if somewhere on the path to that code we set the right mode. > > The places where transition markers are placed may appear arbitrary, but that's not so. > > The process for determining the right place to put them goes as follows: > > Find a point where there is a write into the code cache which causes a trap. In the control-flow graph, this is a node in the dominator tree. > Walk up the dominator tree (i.e. walk up the stack in GDB) towards the root until you find the highest node _N_ such that the majority of nodes dominated by _N_ also write into the code cache. Place a write-enable marker at the start of the function. > Repeat this process until there are no more traps. > > "The majority" is a judgement call, but it's not difficult in most cases. For example, any function constructing an instance of `Assembler` is almost certain to dominate a write to the code cache, and likewise any function that patches code. > > While this process doesn't guarantee an optimal solution, in practice it works pretty well, and removes 99% of W^X mode switches. > @theRealAph Thank you so much for taking care of this! The combination of "healing" and "markers" could be the most optimal way to implement W^X transitions, it's great to see it implemented. On the start-up time, do you see the combination of healing+markers outperforms just healing? Not really, no, but a lot of people are working on reducing startup time, so I'm loath to add an y more. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26562#issuecomment-3334949924 From aph at openjdk.org Fri Sep 26 09:41:09 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 26 Sep 2025 09:41:09 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v3] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> <8p7nn5ImdqZ4Wj-Ca5zw6TqyGD_Xmj0GREl7dkhQCHM=.04538a99-7043-4811-b39c-5b1913523e1c@github.com> Message-ID: On Tue, 19 Aug 2025 14:35:23 GMT, Andrew Haley wrote: >> Yes, we should do that. As you say, we do this on Windows already. >> >> The only slight problem is that dladdr does not give me the end of the last mappings belonging to libjvm.so, only the base address. We also have multiple mappings. I only ever saw them being loaded adjacent to each other, but am not sure if that is guaranteed. > >> Yes, we should do that. As you say, we do this on Windows already. > > Where is that Windows code? > To make it safe to call from a signal handler, we could take a snapshot of the boundaries during startup, something like what os::get_loaded_modules_info() does. Unfortunately there is no way to get the end address of a [dll](https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/dyld.3.html) The only way to do it, I think, would be to get all of the libraries at startup, and find the successor of libjvm.dll. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2379720558 From aph at openjdk.org Fri Sep 26 09:41:10 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 26 Sep 2025 09:41:10 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v9] In-Reply-To: <3lS-ZY4HxoaCq9XlW3MT9Zkq1sqJnsgPSNIznkeCzSw=.3af36d30-5ca8-4d1c-9185-01a3c2f59aef@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <3lS-ZY4HxoaCq9XlW3MT9Zkq1sqJnsgPSNIznkeCzSw=.3af36d30-5ca8-4d1c-9185-01a3c2f59aef@github.com> Message-ID: On Fri, 26 Sep 2025 09:38:30 GMT, Andrew Haley wrote: >> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. >> >> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. >> >> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. >> >> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. >> >> We mark all sites that we know will write to code memory with >> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. >> >> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. >> >> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. >> >> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude... > > Andrew Haley has updated the pull request incrementally with six additional commits since the last revision: > > - More > - Fix test > - Review comments > - Review commwnts > - Test > - More src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 255: > 253: && pc != info->si_addr > 254: && CodeCache::contains(info->si_addr) > 255: && os::address_is_in_vm(pc)) { This call to `os::address_is_in_vm()` is not really allowed in a signal handler, but it does work. It's not necessary for correct healing, but it is defence in depth. The healing stress test is in tier1, so we may detect any crash due to `os::address_is_in_vm()` returning a false negative. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2379736319 From dlong at openjdk.org Fri Sep 26 09:41:11 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 26 Sep 2025 09:41:11 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v2] In-Reply-To: <5Y5h568Saz4vj6uzfH09a1bgtsZ-4LSHFm2gfu8Eb-Q=.121bc2d4-e044-40ec-9347-736fb5c79456@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <5Y5h568Saz4vj6uzfH09a1bgtsZ-4LSHFm2gfu8Eb-Q=.121bc2d4-e044-40ec-9347-736fb5c79456@github.com> Message-ID: On Tue, 23 Sep 2025 10:59:59 GMT, Andrew Haley wrote: >> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 265: >> >>> 263: // is called by the signal handler at arbitrary point of >>> 264: // execution. >>> 265: ThreadWXEnable wx(WXWrite, thread); >> >> I'm not sure this ThreadWXEnable needs to use WXWrite. I had changed it to WXExec in my experiments. > > If it can be WXWrite or WXExec, then we don't need to set it at all, I suppose. There may be cases where code that we call from the signal handler changes the state, so we would need to protect against that by saving and restoring the state. Maybe this should be ThreadWXEnable wx(thread->get_wx_state(), thread); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2373418294 From aph at openjdk.org Fri Sep 26 09:41:14 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 26 Sep 2025 09:41:14 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v4] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Tue, 19 Aug 2025 07:28:54 GMT, David Holmes wrote: >> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: >> >> Tmp > > src/hotspot/share/utilities/macros.hpp line 560: > >> 558: #define MACOS_AARCH64_ONLY(x) MACOS_ONLY(AARCH64_ONLY(x)) >> 559: #if defined(__APPLE__) && defined(AARCH64) >> 560: #define MACOS_W_XOR_X 1 > > This is just an alias for `MACOS_AARCH64_ONLY` - do we really need it? Especially when, in shared code, we lose the fact that it is AARCH64 only. I've renamed it to `MACOS_AARCH64`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2379707307 From dlong at openjdk.org Fri Sep 26 09:41:15 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 26 Sep 2025 09:41:15 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v9] In-Reply-To: <3lS-ZY4HxoaCq9XlW3MT9Zkq1sqJnsgPSNIznkeCzSw=.3af36d30-5ca8-4d1c-9185-01a3c2f59aef@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <3lS-ZY4HxoaCq9XlW3MT9Zkq1sqJnsgPSNIznkeCzSw=.3af36d30-5ca8-4d1c-9185-01a3c2f59aef@github.com> Message-ID: On Fri, 26 Sep 2025 09:38:30 GMT, Andrew Haley wrote: >> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. >> >> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. >> >> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. >> >> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. >> >> We mark all sites that we know will write to code memory with >> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. >> >> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. >> >> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. >> >> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude... > > Andrew Haley has updated the pull request incrementally with six additional commits since the last revision: > > - More > - Fix test > - Review comments > - Review commwnts > - Test > - More test/hotspot/jtreg/runtime/os/TestWXHealing.java line 44: > 42: JavaShellToolBuilder > 43: .builder() > 44: .start(); Should we count "Healing WXMode" output lines to make sure healing is happening? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2380354261 From aph at openjdk.org Fri Sep 26 09:41:15 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 26 Sep 2025 09:41:15 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v9] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <3lS-ZY4HxoaCq9XlW3MT9Zkq1sqJnsgPSNIznkeCzSw=.3af36d30-5ca8-4d1c-9185-01a3c2f59aef@github.com> Message-ID: On Thu, 25 Sep 2025 21:21:47 GMT, Dean Long wrote: > Should we count "Healing WXMode" output lines to make sure healing is happening? I don't think that's essential. Sure, it would make sure that `StressWXHealing` does something, but then would we also need to check that the "Healing WXMode" counters also worked? You have to stop somewhere. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2381588438 From luhenry at openjdk.org Fri Sep 26 09:46:47 2025 From: luhenry at openjdk.org (Ludovic Henry) Date: Fri, 26 Sep 2025 09:46:47 GMT Subject: RFR: 8367253: RISC-V: refactor dependent cpu extensions [v5] In-Reply-To: References: Message-ID: <31FZaw0zbFoLr_PS6GnboLR6kIZpEdbki6FZDbuEaAg=.8607f376-49f5-4047-8b52-a5f41bd60ea5@github.com> On Fri, 26 Sep 2025 08:19:32 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> >> Dependent extensions could be improved in several ways. >> >> Currently, the dependent cpu extensions are processed in 2 separate places: >> 1. update_flag() when calling VM_Version::setup_cpu_available_features() >> 2. at the end of VM_Version::common_initialize(). >> >> And, dependency relationship can only be expressed in (1:1) way, can not be expressed (1:N) way, but in fact some extensions can depend on several different other extensions, for example, zvfh depends on zvf and rvv. It's would be better to support this (1:N) relationship. >> >> So, this PR brings several benefits: >> 1. VM options directly related to CPU extensions are automatically set, and they are all set in one place. >> 2. keep synchronization between CPU extensions (information in RVFeatureValue) and and VM options. Previously, code in common_initialize wont' sync to RVFeatureValue, unless do it manually, which is error-prone. >> 3. support to express (1:N) dependency relationship among cpu extensions and related vm options. >> >> Thanks! >> >> >> ## Test >> >> >> $TEST_JDK/bin/java -XX:+UnlockExperimentalVMOptions -XX:-UseRVV -XX:+PrintFlagsFinal -version | grep -e UseRVV -e UseZvbc -e UseZvfh -e UseZvkn >> OpenJDK 64-Bit Server VM warning: Cannot enable UseZvbb on cpu without any of the supports: v (disabled) >> OpenJDK 64-Bit Server VM warning: Cannot enable UseZvbc on cpu without any of the supports: v (disabled) >> OpenJDK 64-Bit Server VM warning: Cannot enable UseZvfh on cpu without any of the supports: v (disabled), Zfh (enabled) >> bool UseRVV = false {ARCH diagnostic} {command line} >> bool UseZvbc = false {ARCH experimental} {default} >> bool UseZvfh = false {ARCH diagnostic} {default} >> bool UseZvkn = false {ARCH experimental} {default} >> >> >> >> $TEST_JDK/bin/java -XX:+UnlockExperimentalVMOptions -XX:-UseZfh -XX:+PrintFlagsFinal -version | grep -e UseRVV -e UseZvbc -e UseZvfh -e UseZvkn >> OpenJDK 64-Bit Server VM warning: Cannot enable UseZvfh on cpu without any of the supports: v (enabled), Zfh (disabled) >> bool UseRVV = true {ARCH diagnostic} {default} >> bool UseZvbc = true ... > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > minor Marked as reviewed by luhenry (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27171#pullrequestreview-3271266711 From wenanjian at openjdk.org Fri Sep 26 09:56:43 2025 From: wenanjian at openjdk.org (Anjian Wen) Date: Fri, 26 Sep 2025 09:56:43 GMT Subject: RFR: 8368724: RISC-V: Check if unaligned_access is enabled before use In-Reply-To: <1Um6PaMwVL_OB6ZMfl2HEc7r7-0xuwTR4prgFKeepfo=.26d2deac-ad80-4e68-b4e3-b04a047261f6@github.com> References: <1Um6PaMwVL_OB6ZMfl2HEc7r7-0xuwTR4prgFKeepfo=.26d2deac-ad80-4e68-b4e3-b04a047261f6@github.com> Message-ID: On Fri, 26 Sep 2025 08:31:05 GMT, Hamlin Li wrote: > I think we're going to remove the `AvoidUnalignedAccesses`? And if `unaligned_access` is not enabled, then its value can not be `MISALIGNED_FAST`? If both above are true, then seems this check is not necessary? @Hamlin-Li Thanks for your review. According to the current use of `unaligned_access.value`, if it is not enabled, then using value will depend on the default value `-1`. This change is to try to make the use of `unaligned_access.value` more reasonable. Maybe we can keep this judgment and consider removing the Avoid flag latter? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27510#issuecomment-3337787821 From rcastanedalo at openjdk.org Fri Sep 26 10:14:42 2025 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Fri, 26 Sep 2025 10:14:42 GMT Subject: RFR: 8359378: aarch64: crash when using -XX:+UseFPUForSpilling In-Reply-To: <0MbLaZYRoz-raa9x1eZycxeHE7mvPiGJujQpg8vBdek=.e3483c47-ad65-4d09-baf5-2db9b780669d@github.com> References: <0MbLaZYRoz-raa9x1eZycxeHE7mvPiGJujQpg8vBdek=.e3483c47-ad65-4d09-baf5-2db9b780669d@github.com> Message-ID: On Wed, 17 Sep 2025 16:19:12 GMT, Boris Ulasevich wrote: > AArch64 BarrierSetAssembler path assumes only FP/vector ideal regs reach the FP spill/restore encoding. With -XX:+UseFPUForSpilling Register Allocator may allocate scalar values in FP registers. When such values (Op_RegI/Op_RegN/Op_RegL/Op_RegP) hit `BarrierSetAssembler::encode_float_vector_register_size`, we trip ShouldNotReachHere in release build and **"unexpected ideal register"** assertion in debug build. > > Fix: teach the encoder to handle scalar ideal regs when they physically live in FP regs: > - treat Op_RegI / Op_RegN as 32-bit (single slot) - same class as Op_RegF > - treat Op_RegL / Op_RegP as 64-bit (two slots) - same class as Op_RegD > > Related: > - reproduced since #19746 > - spilling logic: > - #18967 > - #17977 > > Testing: tier1-3 with javaoptions -Xcomp -Xbatch -XX:+UseFPUForSpilling on AARCH > I suggest handling this in two steps: > > * In JDK 25 we fix the crash when UseFPUForSpilling is enabled. > * In the next release we prohibit the option softly: if it is set on the command line, the VM prints a warning and resets it to false. Proposed change for the latter: > > ```diff > diff --git a/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp b/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp > index 308deeaf5e2..7702988c11c 100644 > --- a/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp > +++ b/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp > @@ -621,4 +621,9 @@ void VM_Version::initialize() { > FLAG_SET_DEFAULT(UseVectorizedHashCodeIntrinsic, true); > } > + > + if (UseFPUForSpilling) { > + warning("UseFPUForSpilling is known to degrade performance on this platform and will be ignored."); > + FLAG_SET_DEFAULT(UseFPUForSpilling, false); > + } > #endif > > ``` This seems reasonable to me as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27350#issuecomment-3337898957 From jsjolen at openjdk.org Fri Sep 26 10:20:48 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 26 Sep 2025 10:20:48 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7] In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 07:23:32 GMT, Serguei Spitsyn wrote: >> Hmm, I don't want to go into renaming them in this PR. I think that's something that can be done separately. > > Why not? This PR is introducing these two classes. It is better to do in a simplified form. :) It's only introducing the BSMAttributeEntries class, the other one is pre-existing. I don't want the PR to get stuck on whether or not to do a rename of something previously determined to be fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2381835382 From mli at openjdk.org Fri Sep 26 10:33:51 2025 From: mli at openjdk.org (Hamlin Li) Date: Fri, 26 Sep 2025 10:33:51 GMT Subject: RFR: 8368724: RISC-V: Check if unaligned_access is enabled before use In-Reply-To: <1Um6PaMwVL_OB6ZMfl2HEc7r7-0xuwTR4prgFKeepfo=.26d2deac-ad80-4e68-b4e3-b04a047261f6@github.com> References: <1Um6PaMwVL_OB6ZMfl2HEc7r7-0xuwTR4prgFKeepfo=.26d2deac-ad80-4e68-b4e3-b04a047261f6@github.com> Message-ID: On Fri, 26 Sep 2025 08:31:05 GMT, Hamlin Li wrote: >> we can notice that the `unaligned_access.value()` can only be used when the `unaligned_access.enabled()` is true, so we add the check here before use >> >> Manually checked the result on platforms w/wo fast misaligned accesses by running: $java -XX:+PrintFlagsFinal -version | grep AvoidUnalignedAccess > > I think we're going to remove the `AvoidUnalignedAccesses`? And if `unaligned_access` is not enabled, then its value can not be `MISALIGNED_FAST`? > If both above are true, then seems this check is not necessary? > @Hamlin-Li Thanks for your review. According to the current use of `unaligned_access.value`, if it is not enabled, then using value will depend on the default value `-1`. This change is to try to make the use of `unaligned_access.value` more reasonable. Maybe we can keep this judgment and consider removing the Avoid flag latter? If the default value is `-1`, then `unaligned_access.value() == MISALIGNED_FAST` can only be true when it's enabled, so that makes the extra check added in this pr unnecessary for `UseUnalignedAccesses`. As for `AvoidUnalignedAccesses`, there is a discussion here to remove `AvoidUnalignedAccesses`: https://github.com/openjdk/jdk/pull/27445#pullrequestreview-3257314698. So my suggestion is to just remove `AvoidUnalignedAccesses` in riscv, how do you think about it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27510#issuecomment-3338014373 From mli at openjdk.org Fri Sep 26 10:53:23 2025 From: mli at openjdk.org (Hamlin Li) Date: Fri, 26 Sep 2025 10:53:23 GMT Subject: RFR: 8368724: RISC-V: Check if unaligned_access is enabled before use In-Reply-To: References: <1Um6PaMwVL_OB6ZMfl2HEc7r7-0xuwTR4prgFKeepfo=.26d2deac-ad80-4e68-b4e3-b04a047261f6@github.com> Message-ID: On Fri, 26 Sep 2025 10:31:37 GMT, Hamlin Li wrote: > So my suggestion is to just remove `AvoidUnalignedAccesses` in riscv, how do you think about it? I guess no one's already working it? Maybe you could take it if you are available. :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27510#issuecomment-3338108627 From mli at openjdk.org Fri Sep 26 11:15:49 2025 From: mli at openjdk.org (Hamlin Li) Date: Fri, 26 Sep 2025 11:15:49 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v5] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 12:44:01 GMT, Robbin Ehn wrote: >> Hi please, consider. >> >> As ziccif require instructions to natural aligned to be atomic the 4 byte post call nop must be aligned. >> But I don't want to add a c.nop(2b) to align the nop(4b) which means the jal(r) must also be algined. >> As we have no utility to aligned the end of an instruction sequence the call it self is aligned and uses only 4 byte instructions. Only in the case where we could use an two c-instruction we may loose space. >> >> Thanks, Robbin > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Use relocation spec as marker. src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 358: > 356: > 357: void MacroAssembler::post_call_nop() { > 358: assert(!in_compressible_scope(), "Must be"); Maybe `do_compress` is better? All other places use `do_compress`. Similar suggestion as below. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27467#discussion_r2382034698 From jkern at openjdk.org Fri Sep 26 12:01:46 2025 From: jkern at openjdk.org (Joachim Kern) Date: Fri, 26 Sep 2025 12:01:46 GMT Subject: RFR: 8368250: [AIX] now ubsan vptr check is also possible (follow up of JDK-8354686) [v2] In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 07:11:44 GMT, Matthias Baesken wrote: > > > Looks like we get now ALWAYS ` -Wl,-bcdtors:mbr::s` into the AIX link flags, is that observation correct? So the change does not only touch ubsan but all linkage on this platform ? What are the pros and cons ? > > > > > > I got the advice from IBM, that we should use this link flag in any case. We just missed it in the initial porting to the new clang based Compiler. > > So what does the added flag (especially in the 'normal' non-sanitizer enabled builds) and what's the benefit we get from it (so far we lived happily without it). This linker flag maintains the well-established order of initialization of static constructors, as known from the former xlC. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27468#issuecomment-3338331863 From mbaesken at openjdk.org Fri Sep 26 12:06:49 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 26 Sep 2025 12:06:49 GMT Subject: RFR: 8368250: [AIX] now ubsan vptr check is also possible (follow up of JDK-8354686) [v2] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 07:40:03 GMT, Joachim Kern wrote: >> After [JDK-8354686](https://bugs.openjdk.org/browse/JDK-8354686) the ubsan vptr checks still did not work. We finally found out, that they only work, if all linkage units are linked with the C++ compiler frontend as linker, especially the main executables (java, javac, ...) which are linked with the C compiler frontend. >> So for a ubsan enabled build on AIX we let everything link with the C++ compiler frontend. >> Background: The C++ compiler frontend inherently adds special static libraries which the C compiler does not. This results in missing symbols when trying to start a program and its shared libraries, when they were linked in mixed mode. > > Joachim Kern has updated the pull request incrementally with one additional commit since the last revision: > > indentation and typo Marked as reviewed by mbaesken (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27468#pullrequestreview-3271944238 From duke at openjdk.org Fri Sep 26 12:16:24 2025 From: duke at openjdk.org (Ruben) Date: Fri, 26 Sep 2025 12:16:24 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v5] In-Reply-To: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: > The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. > > According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. Ruben has updated the pull request incrementally with two additional commits since the last revision: - Address review comments - The patch is contributed by @TheRealMDoerr ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26678/files - new: https://git.openjdk.org/jdk/pull/26678/files/47178248..5107d025 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26678&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26678&range=03-04 Stats: 88 lines in 18 files changed: 48 ins; 17 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/26678.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26678/head:pull/26678 PR: https://git.openjdk.org/jdk/pull/26678 From jkern at openjdk.org Fri Sep 26 12:18:28 2025 From: jkern at openjdk.org (Joachim Kern) Date: Fri, 26 Sep 2025 12:18:28 GMT Subject: Integrated: 8368250: [AIX] now ubsan vptr check is also possible (follow up of JDK-8354686) In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 13:23:00 GMT, Joachim Kern wrote: > After [JDK-8354686](https://bugs.openjdk.org/browse/JDK-8354686) the ubsan vptr checks still did not work. We finally found out, that they only work, if all linkage units are linked with the C++ compiler frontend as linker, especially the main executables (java, javac, ...) which are linked with the C compiler frontend. > So for a ubsan enabled build on AIX we let everything link with the C++ compiler frontend. > Background: The C++ compiler frontend inherently adds special static libraries which the C compiler does not. This results in missing symbols when trying to start a program and its shared libraries, when they were linked in mixed mode. This pull request has now been integrated. Changeset: f0e1078c Author: Joachim Kern URL: https://git.openjdk.org/jdk/commit/f0e1078c7175b3f930502a6079feff86aa53b669 Stats: 9 lines in 3 files changed: 5 ins; 0 del; 4 mod 8368250: [AIX] now ubsan vptr check is also possible (follow up of JDK-8354686) Reviewed-by: erikj, stuefe, mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/27468 From duke at openjdk.org Fri Sep 26 12:19:29 2025 From: duke at openjdk.org (Ruben) Date: Fri, 26 Sep 2025 12:19:29 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v5] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Fri, 26 Sep 2025 12:16:24 GMT, Ruben wrote: >> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. >> >> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. > > Ruben has updated the pull request incrementally with two additional commits since the last revision: > > - Address review comments > - The patch is contributed by @TheRealMDoerr src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp line 278: > 276: __ b(start); > 277: > 278: guarantee(code_offset() - offset <= deopt_handler_size(), "overflow"); @TheRealMDoerr , I think this has to ensure there will be enough space for all of the stub code, not just the part starting from the entry point. Does this look correct from your perspective? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26678#discussion_r2382237148 From rehn at openjdk.org Fri Sep 26 12:39:57 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 26 Sep 2025 12:39:57 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v5] In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 11:13:27 GMT, Hamlin Li wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Use relocation spec as marker. > > src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 358: > >> 356: >> 357: void MacroAssembler::post_call_nop() { >> 358: assert(!in_compressible_scope(), "Must be"); > > Maybe `do_compress` is better? All other places use `do_compress`. > Similar suggestion as below. There is a semantic difference: in_compressible_scope() only check if caller turned off c-instruction. While do_compressed() also consider what ISA we are using in runtime. Regardless of ISA : caller of post_call_nop() should have turned C off is what I want to assert. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27467#discussion_r2382284606 From mdoerr at openjdk.org Fri Sep 26 12:40:01 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 26 Sep 2025 12:40:01 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v5] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Fri, 26 Sep 2025 12:16:17 GMT, Ruben wrote: >> Ruben has updated the pull request incrementally with two additional commits since the last revision: >> >> - Address review comments >> - The patch is contributed by @TheRealMDoerr > > src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp line 278: > >> 276: __ b(start); >> 277: >> 278: guarantee(code_offset() - offset <= deopt_handler_size(), "overflow"); > > @TheRealMDoerr , I think this has to ensure there will be enough space for all of the stub code, not just the part starting from the entry point. Does this look correct from your perspective? Good catch! Yeah, we should keep using `offset`, here. My mistake. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26678#discussion_r2382285446 From mdoerr at openjdk.org Fri Sep 26 12:59:37 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 26 Sep 2025 12:59:37 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v5] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Fri, 26 Sep 2025 12:16:24 GMT, Ruben wrote: >> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. >> >> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. > > Ruben has updated the pull request incrementally with two additional commits since the last revision: > > - Address review comments > - The patch is contributed by @TheRealMDoerr Thank you so much for doing the work for all platforms! It looks correct to me. Should we rename `entry_point` to `entry_offset` in the deopt handlers to emphasize that it's an offset and not a pointer? src/hotspot/share/ci/ciEnv.cpp line 3: > 1: /* > 2: * Copyright (c) 1999, 2025, Oracle and/or its affiliates. All rights reserved. > 3: * Copyright 2025 Arm Limited and/or its affiliates. This Copyright addition looks a bit disproportionate. I wouldn't call the assertion adaptation a major contribution to this file. src/hotspot/share/code/nmethod.cpp line 3: > 1: /* > 2: * Copyright (c) 1997, 2025, Oracle and/or its affiliates. All rights reserved. > 3: * Copyright 2025 Arm Limited and/or its affiliates. Still questionable, here. Do we have clear guidelines? ------------- PR Review: https://git.openjdk.org/jdk/pull/26678#pullrequestreview-3272133194 PR Review Comment: https://git.openjdk.org/jdk/pull/26678#discussion_r2382338233 PR Review Comment: https://git.openjdk.org/jdk/pull/26678#discussion_r2382339599 From mli at openjdk.org Fri Sep 26 13:28:05 2025 From: mli at openjdk.org (Hamlin Li) Date: Fri, 26 Sep 2025 13:28:05 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v5] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 12:44:01 GMT, Robbin Ehn wrote: >> Hi please, consider. >> >> As ziccif require instructions to natural aligned to be atomic the 4 byte post call nop must be aligned. >> But I don't want to add a c.nop(2b) to align the nop(4b) which means the jal(r) must also be algined. >> As we have no utility to aligned the end of an instruction sequence the call it self is aligned and uses only 4 byte instructions. Only in the case where we could use an two c-instruction we may loose space. >> >> Thanks, Robbin > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Use relocation spec as marker. src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp line 1353: > 1351: > 1352: void LIR_Assembler::call(LIR_OpJavaCall* op, relocInfo::relocType rtype) { > 1353: Assembler::IncompressibleScope scope(_masm); Is an alignment needed here? src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp line 1364: > 1362: > 1363: void LIR_Assembler::ic_call(LIR_OpJavaCall* op) { > 1364: Assembler::IncompressibleScope scope(_masm); Is an alignment needed here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27467#discussion_r2382427866 PR Review Comment: https://git.openjdk.org/jdk/pull/27467#discussion_r2382428132 From mli at openjdk.org Fri Sep 26 13:32:24 2025 From: mli at openjdk.org (Hamlin Li) Date: Fri, 26 Sep 2025 13:32:24 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v5] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 12:44:01 GMT, Robbin Ehn wrote: >> Hi please, consider. >> >> As ziccif require instructions to natural aligned to be atomic the 4 byte post call nop must be aligned. >> But I don't want to add a c.nop(2b) to align the nop(4b) which means the jal(r) must also be algined. >> As we have no utility to aligned the end of an instruction sequence the call it self is aligned and uses only 4 byte instructions. Only in the case where we could use an two c-instruction we may loose space. >> >> Thanks, Robbin > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Use relocation spec as marker. There is an assert here: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp#L4998 if (entry.rspec().type() != relocInfo::runtime_call_type) { assert_alignment(call_pc); } It's only asserted if it's not `runtime_call_type`, should this condition be adjusted/removed? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27467#issuecomment-3338741225 From asmehra at openjdk.org Fri Sep 26 13:32:02 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 26 Sep 2025 13:32:02 GMT Subject: RFR: 8368693: Duplicate methods in vmClasses [v2] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 21:34:42 GMT, Chen Liang wrote: >> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: >> >> Update comment >> >> Signed-off-by: Ashutosh Mehra > > src/hotspot/share/memory/universe.cpp line 507: > >> 505: // ordinary object arrays, _objectArrayKlass will be loaded when >> 506: // SystemDictionary::initialize(CHECK); is run. See the extra check >> 507: // for Object_klass_is_loaded in objArrayKlassKlass::allocate_objArray_klass_impl. > > Should this comment update the outdated reference to be: > Suggestion: > > // for Object_klass_is_loaded in ObjArrayKlass::allocate_objArray_klass. Done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27503#discussion_r2382433294 From asmehra at openjdk.org Fri Sep 26 13:32:01 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 26 Sep 2025 13:32:01 GMT Subject: RFR: 8368693: Duplicate methods in vmClasses [v2] In-Reply-To: References: Message-ID: <2YObl1iENj5g0CuPpXc5URoUws70G8sEprCYou1LB-s=.34647a05-9525-4e1e-ad7b-0619a7198095@github.com> > This patch removes some duplicate methods that check if a class is loaded in vmClasses. These methods are already present in the class (generated by the `_VM_CLASS_DECLARE` macro). Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: Update comment Signed-off-by: Ashutosh Mehra ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27503/files - new: https://git.openjdk.org/jdk/pull/27503/files/619d75a8..567313f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27503&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27503&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27503.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27503/head:pull/27503 PR: https://git.openjdk.org/jdk/pull/27503 From asmehra at openjdk.org Fri Sep 26 13:34:27 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 26 Sep 2025 13:34:27 GMT Subject: RFR: 8368693: Duplicate methods in vmClasses [v2] In-Reply-To: <2YObl1iENj5g0CuPpXc5URoUws70G8sEprCYou1LB-s=.34647a05-9525-4e1e-ad7b-0619a7198095@github.com> References: <2YObl1iENj5g0CuPpXc5URoUws70G8sEprCYou1LB-s=.34647a05-9525-4e1e-ad7b-0619a7198095@github.com> Message-ID: On Fri, 26 Sep 2025 13:32:01 GMT, Ashutosh Mehra wrote: >> This patch removes some duplicate methods that check if a class is loaded in vmClasses. These methods are already present in the class (generated by the `_VM_CLASS_DECLARE` macro). > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Update comment > > Signed-off-by: Ashutosh Mehra Last commit was just an update to an outdated comment. I don't think it needs new approval. Integrating it now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27503#issuecomment-3338749757 From asmehra at openjdk.org Fri Sep 26 13:34:28 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 26 Sep 2025 13:34:28 GMT Subject: RFR: 8368693: Duplicate methods in vmClasses [v2] In-Reply-To: References: Message-ID: <8fSb_KbGYlz7n6E-N8Ty7Bt7Iu5ho2nK44iUQ_PYbIY=.24c70d75-69ef-4400-8bd1-ad068847466c@github.com> On Thu, 25 Sep 2025 21:16:50 GMT, Coleen Phillimore wrote: >> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: >> >> Update comment >> >> Signed-off-by: Ashutosh Mehra > > Looks good. thanks @coleenp @dholmes-ora @liach for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27503#issuecomment-3338750763 From liach at openjdk.org Fri Sep 26 14:00:59 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 26 Sep 2025 14:00:59 GMT Subject: RFR: 8368693: Duplicate methods in vmClasses [v2] In-Reply-To: <2YObl1iENj5g0CuPpXc5URoUws70G8sEprCYou1LB-s=.34647a05-9525-4e1e-ad7b-0619a7198095@github.com> References: <2YObl1iENj5g0CuPpXc5URoUws70G8sEprCYou1LB-s=.34647a05-9525-4e1e-ad7b-0619a7198095@github.com> Message-ID: On Fri, 26 Sep 2025 13:32:01 GMT, Ashutosh Mehra wrote: >> This patch removes some duplicate methods that check if a class is loaded in vmClasses. These methods are already present in the class (generated by the `_VM_CLASS_DECLARE` macro). > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Update comment > > Signed-off-by: Ashutosh Mehra Thanks for the comment update. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27503#pullrequestreview-3272417832 From jwaters at openjdk.org Fri Sep 26 14:13:17 2025 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 26 Sep 2025 14:13:17 GMT Subject: RFR: 8368693: Duplicate methods in vmClasses [v2] In-Reply-To: References: <2YObl1iENj5g0CuPpXc5URoUws70G8sEprCYou1LB-s=.34647a05-9525-4e1e-ad7b-0619a7198095@github.com> Message-ID: <05U6lJMvJ7MsE79zKixi5o0s1AybxD_NF9xYuScoI4E=.9eef8821-3103-4e68-a159-243f864e73de@github.com> On Fri, 26 Sep 2025 13:32:05 GMT, Ashutosh Mehra wrote: > Last commit was just an update to an outdated comment. I don't think it needs new approval. Integrating it now. Skara has changed some time ago; You can't integrate if all reviews are stale ------------- PR Comment: https://git.openjdk.org/jdk/pull/27503#issuecomment-3338912460 From vlivanov at openjdk.org Fri Sep 26 14:39:40 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 26 Sep 2025 14:39:40 GMT Subject: RFR: 8368722: Several vector load/store tests fail on riscv without support for misaligned vector access In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 01:44:19 GMT, Dingli Zhang wrote: > Hi, > Can you help to review this patch? Thanks! > > In `*VectorLoadStoreTests.java`, `loadMemorySegmentMaskIOOBE` and `storeMemorySegmentMaskIOOBE` may fail because `int index = fi.apply((int) a.byteSize())` can generate random indices that result in misaligned addresses, leading to SIGBUS on hardware that disallows misaligned vector accesses. > > Some RISC-V hardware supports fast misaligned scalar accesses but not vector ones, which causes SIGBUS when executing these tests with misaligned vector memory operations. > > So we should adjusted index to align with the element byte size in these tests. > > ### Test > - [x] Run jdk_vector on k1 > - [x] Run jdk_vector on x86_64 and ARM64 It's not a test bug, but a product one. The Vector API deliberately doesn't require vector accesses to be naturally aligned. If a platform doesn't support misaligned vector accesses it has to either properly emulate them or fail to intrinsify corresponding vector intrinsics. ------------- Changes requested by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27506#pullrequestreview-3272573609 From sgehwolf at openjdk.org Fri Sep 26 14:48:42 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 26 Sep 2025 14:48:42 GMT Subject: RFR: 8365606: Container code should not be using jlong/julong In-Reply-To: References: Message-ID: On Fri, 5 Sep 2025 17:24:58 GMT, Severin Gehwolf wrote: > Please review this refactoring to the container code in Hotspot to no longer use `jlong` and `julong`. Instead this patch proposes to move to `size_t` and `ssize_t` types. In a similar manner as was done with the `os::xxx` APIs in [JDK-8357086](https://bugs.openjdk.org/browse/JDK-8357086). With this patch the use of `OSCONTAINER_ERROR` (`-2`) is largely gone. It's not terribly useful to have to warrant the many special cases throughout the code. > > In this patch failure handling is being done by returning a boolean for success/failure of reading a value from the interface files. The notion of "not supported" is being folded into `-1` (unlimited for limit values, not supported for usage values). Note that the code already treated `-1` and `-2` similarly. The few cases where `-2` was actually used was in `VM.info` output or `hserr` files. Where `-2` was being treated as "not supported". However, file-reading errors would also fall into the `-2` bucket making the "not supported" case not 100% distinguishable either. The simplification here proposes to do away with `-2` (other than in traces) and fold it into the `-1` (unlimited) bucket as that's how the code has been handling those values (even prior to this patch). > > Testing: > - [x] GHA (tier1) > - [x] cgroup gtests and hotspot container tests on cgroup v1 and cgroup v2 (no regressions noted). > > Thoughts? I'm closing this PR and will create a new one once JDK-8367485 is pushed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27125#issuecomment-3339026693 From sgehwolf at openjdk.org Fri Sep 26 14:48:43 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 26 Sep 2025 14:48:43 GMT Subject: Withdrawn: 8365606: Container code should not be using jlong/julong In-Reply-To: References: Message-ID: <1ks5YoHGGPRK9PUlnjUCqoX-JH9BZ3QBy0GTcN8OO2I=.3b7770e6-2156-487e-bff2-154bcef9978d@github.com> On Fri, 5 Sep 2025 17:24:58 GMT, Severin Gehwolf wrote: > Please review this refactoring to the container code in Hotspot to no longer use `jlong` and `julong`. Instead this patch proposes to move to `size_t` and `ssize_t` types. In a similar manner as was done with the `os::xxx` APIs in [JDK-8357086](https://bugs.openjdk.org/browse/JDK-8357086). With this patch the use of `OSCONTAINER_ERROR` (`-2`) is largely gone. It's not terribly useful to have to warrant the many special cases throughout the code. > > In this patch failure handling is being done by returning a boolean for success/failure of reading a value from the interface files. The notion of "not supported" is being folded into `-1` (unlimited for limit values, not supported for usage values). Note that the code already treated `-1` and `-2` similarly. The few cases where `-2` was actually used was in `VM.info` output or `hserr` files. Where `-2` was being treated as "not supported". However, file-reading errors would also fall into the `-2` bucket making the "not supported" case not 100% distinguishable either. The simplification here proposes to do away with `-2` (other than in traces) and fold it into the `-1` (unlimited) bucket as that's how the code has been handling those values (even prior to this patch). > > Testing: > - [x] GHA (tier1) > - [x] cgroup gtests and hotspot container tests on cgroup v1 and cgroup v2 (no regressions noted). > > Thoughts? This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27125 From asmehra at openjdk.org Fri Sep 26 14:54:39 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 26 Sep 2025 14:54:39 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps [v4] In-Reply-To: References: Message-ID: <4pvCey3FdUMcF29111jhrh2whmwECHBtSvi58ioedc8=.c9f6ff76-292c-4515-a148-6c027c66403e@github.com> On Wed, 24 Sep 2025 14:23:45 GMT, Thomas Stuefe wrote: >> When we run with ASAN enabled and ASAN catches an error, it reports, then stops the JVM. hs-err files and crash dumps at that point would be incredibly useful, though. The ASAN error report itself is seldom enlightening since it only contains native stacks. >> >> After this patch, the JVM will always produce hs-err files when an ASAN-report happens. It will *only* produce core files if ASAN_OPTIONS `disable_coredump=0` and `abort_on_error=1` and the JVM option `CreateCoredumpOnCrash` had not been disabled (and the limit for core file size is high enough etc, all the usual restrictions on OS level still apply). >> >> This means that ASAN builds, by default, will continue to *not* generate cores, since ASAN default options inhibit that. See detail in the comments below. >> >> --- >> >> Tested on Fedora 42 and Debian 12, both manually and by running the new companion jtreg test. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > fix This looks good to me. I have a couple of questions/points: 1. Is `__asan_set_error_report_callback` the documented way for applications to install callback? I couldn't find information about this. It would be good to add a link to the doc, if there is one, as a comment in the code. 2. Should there be a test for `abort_on_error=1:disable_coredump=0` case where the JVM is expected to generate a core file. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27446#issuecomment-3339046947 From asmehra at openjdk.org Fri Sep 26 15:01:02 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 26 Sep 2025 15:01:02 GMT Subject: RFR: 8368693: Duplicate methods in vmClasses [v2] In-Reply-To: <05U6lJMvJ7MsE79zKixi5o0s1AybxD_NF9xYuScoI4E=.9eef8821-3103-4e68-a159-243f864e73de@github.com> References: <2YObl1iENj5g0CuPpXc5URoUws70G8sEprCYou1LB-s=.34647a05-9525-4e1e-ad7b-0619a7198095@github.com> <05U6lJMvJ7MsE79zKixi5o0s1AybxD_NF9xYuScoI4E=.9eef8821-3103-4e68-a159-243f864e73de@github.com> Message-ID: On Fri, 26 Sep 2025 14:10:21 GMT, Julian Waters wrote: > Skara has changed some time ago; You can't integrate if all reviews are stale Okay. @coleenp or @dholmes-ora can you please approve it again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27503#issuecomment-3339052153 From asmehra at openjdk.org Fri Sep 26 15:01:04 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 26 Sep 2025 15:01:04 GMT Subject: RFR: 8368693: Duplicate methods in vmClasses [v2] In-Reply-To: References: <2YObl1iENj5g0CuPpXc5URoUws70G8sEprCYou1LB-s=.34647a05-9525-4e1e-ad7b-0619a7198095@github.com> Message-ID: On Fri, 26 Sep 2025 13:58:02 GMT, Chen Liang wrote: >> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: >> >> Update comment >> >> Signed-off-by: Ashutosh Mehra > > Thanks for the comment update. I see @liach approved after my last commit. So that should be sufficient. Let me try to integrate again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27503#issuecomment-3339056006 From asmehra at openjdk.org Fri Sep 26 15:01:05 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 26 Sep 2025 15:01:05 GMT Subject: RFR: 8368693: Duplicate methods in vmClasses [v2] In-Reply-To: References: Message-ID: <2r_SON_j79qrACzq5G7UlyefYijZwdx5UoGZa3keTQY=.1483e7c0-b5fd-4c3b-83dd-0bfb9d12cc7a@github.com> On Thu, 25 Sep 2025 21:16:50 GMT, Coleen Phillimore wrote: >> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: >> >> Update comment >> >> Signed-off-by: Ashutosh Mehra > > Looks good. > Okay. @coleenp or @dholmes-ora can you please approve it again. It went through. Please discard the above request. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27503#issuecomment-3339068542 From asmehra at openjdk.org Fri Sep 26 15:01:06 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 26 Sep 2025 15:01:06 GMT Subject: Integrated: 8368693: Duplicate methods in vmClasses In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 21:00:22 GMT, Ashutosh Mehra wrote: > This patch removes some duplicate methods that check if a class is loaded in vmClasses. These methods are already present in the class (generated by the `_VM_CLASS_DECLARE` macro). This pull request has now been integrated. Changeset: aa6ff450 Author: Ashutosh Mehra URL: https://git.openjdk.org/jdk/commit/aa6ff45052516f5383fb7e62cfb469cbade0c42e Stats: 16 lines in 8 files changed: 0 ins; 6 del; 10 mod 8368693: Duplicate methods in vmClasses Reviewed-by: liach, coleenp, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/27503 From rehn at openjdk.org Fri Sep 26 16:06:03 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 26 Sep 2025 16:06:03 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v5] In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 13:25:14 GMT, Hamlin Li wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Use relocation spec as marker. > > src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp line 1353: > >> 1351: >> 1352: void LIR_Assembler::call(LIR_OpJavaCall* op, relocInfo::relocType rtype) { >> 1353: Assembler::IncompressibleScope scope(_masm); > > Is an alignment needed here? It's aligned: void LIR_Assembler::emit_call(LIR_OpJavaCall* op) { verify_oop_map(op->info()); // must align calls sites, otherwise they can't be updated atomically align_call(op->code()); > src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp line 1364: > >> 1362: >> 1363: void LIR_Assembler::ic_call(LIR_OpJavaCall* op) { >> 1364: Assembler::IncompressibleScope scope(_masm); > > Is an alignment needed here? It's aligned: void LIR_Assembler::emit_call(LIR_OpJavaCall* op) { verify_oop_map(op->info()); // must align calls sites, otherwise they can't be updated atomically align_call(op->code()); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27467#discussion_r2382839036 PR Review Comment: https://git.openjdk.org/jdk/pull/27467#discussion_r2382839132 From rehn at openjdk.org Fri Sep 26 16:15:45 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 26 Sep 2025 16:15:45 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v5] In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 13:29:47 GMT, Hamlin Li wrote: > There is an assert here: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp#L4998 > > ``` > if (entry.rspec().type() != relocInfo::runtime_call_type) { > assert_alignment(call_pc); > } > ``` > > It's only asserted if it's not `runtime_call_type`, should this condition be adjusted/removed? Runtime calls don't have an interrupt point and used for calling stub and such. E.g. C2_MacroAssembler::string_compare calls StubRoutines::riscv::compare_long_string_LL. There is not post_call_nops as we can't deoptimize the caller while running this stub. So it's still true that they don't need to be aligned. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27467#issuecomment-3339413948 From aph at openjdk.org Fri Sep 26 16:35:33 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 26 Sep 2025 16:35:33 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v10] In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: <7xKi-PmjgqzFEFVIRFOP_ngaoj1oERzZLzVKBaM5PU8=.114814f7-7b66-4fc2-ad25-92ca252d2039@github.com> > In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. > > Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. > > This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. > > The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. > > We mark all sites that we know will write to code memory with > `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. > > We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. > > It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. > > One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ... Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26562/files - new: https://git.openjdk.org/jdk/pull/26562/files/6a379f10..5e1833a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=08-09 Stats: 68 lines in 2 files changed: 61 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/26562.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26562/head:pull/26562 PR: https://git.openjdk.org/jdk/pull/26562 From aph at openjdk.org Fri Sep 26 16:39:14 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 26 Sep 2025 16:39:14 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v11] In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: > In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. > > Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. > > This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. > > The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. > > We mark all sites that we know will write to code memory with > `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. > > We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. > > It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. > > One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ... Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Review feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26562/files - new: https://git.openjdk.org/jdk/pull/26562/files/5e1833a7..083daded Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26562.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26562/head:pull/26562 PR: https://git.openjdk.org/jdk/pull/26562 From aph at openjdk.org Fri Sep 26 16:39:16 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 26 Sep 2025 16:39:16 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v11] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <3lS-ZY4HxoaCq9XlW3MT9Zkq1sqJnsgPSNIznkeCzSw=.3af36d30-5ca8-4d1c-9185-01a3c2f59aef@github.com> Message-ID: On Fri, 26 Sep 2025 09:22:56 GMT, Andrew Haley wrote: >> test/hotspot/jtreg/runtime/os/TestWXHealing.java line 44: >> >>> 42: JavaShellToolBuilder >>> 43: .builder() >>> 44: .start(); >> >> Should we count "Healing WXMode" output lines to make sure healing is happening? > >> Should we count "Healing WXMode" output lines to make sure healing is happening? > > I don't think that's essential. Sure, it would make sure that `StressWXHealing` does something, but then would we also need to check that the "Healing WXMode" counters also worked? You have to stop somewhere. Never mind, I've done it now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2382904135 From aph at openjdk.org Fri Sep 26 16:57:33 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 26 Sep 2025 16:57:33 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v12] In-Reply-To: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: > In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. > > Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. > > This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. > > The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. > > We mark all sites that we know will write to code memory with > `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. > > We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. > > It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. > > One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude, and it's better to be able to ... Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26562/files - new: https://git.openjdk.org/jdk/pull/26562/files/083daded..20855d98 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26562&range=10-11 Stats: 5 lines in 2 files changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26562.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26562/head:pull/26562 PR: https://git.openjdk.org/jdk/pull/26562 From coleenp at openjdk.org Fri Sep 26 17:35:02 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 26 Sep 2025 17:35:02 GMT Subject: RFR: 8368727: CDS custom loader support causes asserts during class unloading In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 06:11:54 GMT, Ioi Lam wrote: > When loading a class `k` from the CDS archive on behalf of a custom class loader, we were calling `loader_data->add_class(k)` too early. If the loading of `k` fails, it may be in `loader_data->_klasses`, but `k->init_state()` will remain `allocated`. This causes an assert during class unloading: > > > # assert(ik->is_loaded()) failed: class should be loaded 0x000000000b518eb8 > V [libjvm.so+0xfa6bd5] InstanceKlass::unload_class(InstanceKlass*)+0x555 (instanceKlass.cpp:2870) > V [libjvm.so+0xa790e3] ClassLoaderData::classes_do(void (*)(InstanceKlass*))+0xc3 (classLoaderData.cpp:441 > > > The fix is to move the `loader_data->add_class(k)` call to `k->Klass::restore_unshareable_info()`. This is the same location as if `k` were loaded by the 3 built-in class loaders. > > This was discovered when running some JCK tests in AOT mode. I've added a reproducer as a jtreg test case. Looks good. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27511#pullrequestreview-3273188959 From stuefe at openjdk.org Fri Sep 26 19:06:21 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 26 Sep 2025 19:06:21 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps [v4] In-Reply-To: <4pvCey3FdUMcF29111jhrh2whmwECHBtSvi58ioedc8=.c9f6ff76-292c-4515-a148-6c027c66403e@github.com> References: <4pvCey3FdUMcF29111jhrh2whmwECHBtSvi58ioedc8=.c9f6ff76-292c-4515-a148-6c027c66403e@github.com> Message-ID: On Fri, 26 Sep 2025 14:51:44 GMT, Ashutosh Mehra wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> fix > > This looks good to me. I have a couple of questions/points: > 1. Is `__asan_set_error_report_callback` the documented way for applications to install callback? I couldn't find information about this. It would be good to add a link to the doc, if there is one, as a comment in the code. > 2. Should there be a test for `abort_on_error=1:disable_coredump=0` case where the JVM is expected to generate a core file. Thank you, @ashu-mehra . > This looks good to me. I have a couple of questions/points: > > 1. Is `__asan_set_error_report_callback` the documented way for applications to install callback? I couldn't find information about this. It would be good to add a link to the doc, if there is one, as a comment in the code. Documentation for Asan is sparse in general, but it is documented in the header file. I don't know if it was ever not supported - the dlsym'ing I did out of an abundance of caution in case there are older Asan versions around without that functionality. > > 2. Should there be a test for `abort_on_error=1:disable_coredump=0` case where the JVM is expected to generate a core file. I thought about that too, but testing for core files is tricky. For one, there are many ways core file dumping could fail. Prediction of the core file path is difficult (with systemd, you'd need to interpret the sysctl kernel.core-pattern value - we don't even manage to do that correctly in hotspot when displaying the core file dumping message). And with Asan, core file size is a bit unpredictable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27446#issuecomment-3340090888 From dlong at openjdk.org Fri Sep 26 20:07:36 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 26 Sep 2025 20:07:36 GMT Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v9] In-Reply-To: References: Message-ID: > 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 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27059/files - new: https://git.openjdk.org/jdk/pull/27059/files/6a1062c3..d25872bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27059&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27059.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27059/head:pull/27059 PR: https://git.openjdk.org/jdk/pull/27059 From dlong at openjdk.org Fri Sep 26 20:07:38 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 26 Sep 2025 20:07:38 GMT Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v8] In-Reply-To: References: Message-ID: <1CWxUjvyzz0_hlfrZW59H39VziO7_AyhCw4ZfIyUZbA=.1b88957c-2a85-4082-b210-c193340b2e9b@github.com> On Fri, 26 Sep 2025 07:14:08 GMT, Manuel H?ssig wrote: >> Dean Long has updated the pull request incrementally with one additional commit since the last revision: >> >> copyright year update > > I have one last nit below. Otherwise, this looks good to me. Thanks @mhaessig for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27059#issuecomment-3340311259 From asmehra at openjdk.org Fri Sep 26 20:22:18 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Fri, 26 Sep 2025 20:22:18 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps [v4] In-Reply-To: References: <4pvCey3FdUMcF29111jhrh2whmwECHBtSvi58ioedc8=.c9f6ff76-292c-4515-a148-6c027c66403e@github.com> Message-ID: On Fri, 26 Sep 2025 19:03:44 GMT, Thomas Stuefe wrote: > Documentation for Asan is sparse in general, but it is documented in the header file. I don't know if it was ever not supported - the dlsym'ing I did out of an abundance of caution in case there are older Asan versions around without that functionality. okay, I see it in the header file here https://github.com/llvm/llvm-project/blob/d2c189bc739c86bea28e9d603f8973f68869a772/compiler-rt/include/sanitizer/asan_interface.h#L270 If there is no official doc, perhaps just add a reference to this header file in the code where this symbol is referenced. > Prediction of the core file path is difficult (with systemd, you'd need to interpret the sysctl kernel.core-pattern value - we don't even manage to do that correctly in hotspot when displaying the core file dumping message). And with Asan, core file size is a bit unpredictable. Right, that comes with its own challenges. Scratch that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27446#issuecomment-3340385615 From dlong at openjdk.org Fri Sep 26 20:47:19 2025 From: dlong at openjdk.org (Dean Long) Date: Fri, 26 Sep 2025 20:47:19 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v12] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> Message-ID: On Fri, 26 Sep 2025 16:57:33 GMT, Andrew Haley wrote: >> In MacOS/AArch64 HotSpot, we have to deal with the fact that a thread must be in one of two modes: it either may write to code cache memory or it may execute (and read) code or data in it. A system call `pthread_jit_write_protect_np(int enabled)` changes from one to the other. >> >> Today, we change mode whenever making a transition from interpreter to VM. This means that we change mode a lot: experiments have shown that during `jshell` startup we change mode 4 million times. Other experiments have shown that we only needed to change mode 45 thousand times. >> >> This "eager" mode switching is perhaps too eager, and we'd be better off switching lazily. While the system call that changes mode is very fast, mode switching still amounts to about 100ms of startup time. Switching eagerly also means that some native calls (e.g. to do arithmetic) are disproportionately expensive, given that they have no need of mode switching at all. >> >> The approach in this PR is to defer transitioning from exec-but-don't-write mode (`WXExec`) to write-but-don't-exec mode (`WXWrite`) until we need to write. Instead of enabling `WXWrite` immediately, we switch to a mode called `WXArmedForWrite`. When in this mode, when we need to write into code memory we call `os_bsd_jit_exec_enabled(false)` to enable writing and then set the current mode to `WXWrite`. >> >> We mark all sites that we know will write to code memory with >> `MACOS_AARCH64_ONLY(os::thread_wx_enable_write());` Judicious placement of these markers, such as when entering patching code, means that we have a fairly small number of these. >> >> We also keep track (in thread-local storage) of the current state of `pthread_jit_write_protect_np` in order to avoid making the system call unnecessarily. >> >> It is possible that we have missed some sites where we do need to make a transition from write-protected to -enabled. While we haven't seen any in testing, we have a fallback path. An attempt to write into code memory triggers a `SIGILL` signal. A signal handler detects this, and if the current mode `WXArmedForWrite` it changes mode to write-enabled and returns. In addition, the handler "heals" the VM entry point so that next time the same point is entered (and for the rest of the lifetime of the VM) it will immediately transition to `WXWrite`. >> >> One other possibility remains: we could omit all of the `wx_enable_write` markers and use healing instead. We've experimented with this. It works well enough, but is rather crude... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Test Nice job, Andrew! I think this is good to go. ------------- Marked as reviewed by dlong (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26562#pullrequestreview-3273909407 From vpaprotski at openjdk.org Fri Sep 26 23:01:30 2025 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Fri, 26 Sep 2025 23:01:30 GMT Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays [v7] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 15:41:48 GMT, Vladimir Ivanov wrote: >> On the SRF platform after PR https://github.com/openjdk/jdk/pull/26974 the fill intrinsics used by default. >> For some types/ sizes scores for the ArrayFill test reports ~2x drop due to a lot of the 'MEM_UOPS_RETIRED.SPLIT_STORES' events. For example, the 'good' case for the ArraysFill.testCharFill with size=8195 reports numbers like >> MEM_UOPS_RETIRED.SPLIT_LOADS | 22.6711 >> MEM_UOPS_RETIRED.SPLIT_STORES | 4.0859 >> while for 'bad' case these metrics are >> MEM_UOPS_RETIRED.SPLIT_LOADS | 69.1785 >> MEM_UOPS_RETIRED.SPLIT_STORES | 259200.3659 >> >> With alignment for the cache line size no score drops due to split_stores but small reduction may be reported for 'good' cases due to extra instructions in the intrinsic. The default options set was used for testing with '-XX:-OptimizeFill' for compiled code and with '-XX:+OptimizeFill' to force intrinsic. >> SRF 6740E | Size | compiled code| patched intrinsic| patched/compiled >> -- | -- | -- | -- | -- >> ArraysFill.testByteFill | 16 | 152031.2 | 157001.2 | 1.03 >> ArraysFill.testByteFill | 31 | 125795.9 | 177399.2 | 1.41 >> ArraysFill.testByteFill | 250 | 57961.69 | 120981.9 | 2.09 >> ArraysFill.testByteFill | 266 | 44900.15 | 147893.8 | 3.29 >> ArraysFill.testByteFill | 511 | 61908.17 | 129830.1 | 2.10 >> ArraysFill.testByteFill | 2047 | 32255.51 | 41986.6 | 1.30 >> ArraysFill.testByteFill | 2048 | 31928.97 | 42154.3 | 1.32 >> ArraysFill.testByteFill | 8195 | 10690.15 | 11036.3 | 1.03 >> ArraysFill.testIntFill | 16 | 145030.7 | 318796.9 | 2.20 >> ArraysFill.testIntFill | 31 | 134138.4 | 212487 | 1.58 >> ArraysFill.testIntFill | 250 | 74179.23 | 79522.66 | 1.07 >> ArraysFill.testIntFill | 266 | 68112.72 | 60116.49 | 0.88 >> ArraysFill.testIntFill | 511 | 39693.28 | 36225.09 | 0.91 >> ArraysFill.testIntFill | 2047 | 11504.14 | 10616.91 | 0.92 >> ArraysFill.testIntFill | 2048 | 11244.71 | 10969.14 | 0.98 >> ArraysFill.testIntFill | 8195 | 2751.289 | 2692.216 | 0.98 >> ArraysFill.testLongFill | 16 | 212532.5 | 212526 | 1.00 >> ArraysFill.testLongFill | 31 | 137432.4 | 137283.3 | 1.00 >> ArraysFill.testLongFill | 250 | 43185 | 43159.78 | 1.00 >> ArraysFill.testLongFill | 266 | 42172.22 | 42170.5 | 1.00 >> ArraysFill.testLongFill | 511 | 23370.15 | 23370.86 | 1.00 >> ArraysFill.testLongFill | 2047 | 6123.008 | 6122.73 | 1.00 >> ArraysFill.testLongFill | 2048 | 5793.722 | 5792.855 | 1.00 >> ArraysFill.testLongFill | 8195 | 616.552 | 616.585 | 1.00 >> ArraysFill.testShortFill | 16 | 152088.6 | 265646.1 | 1.75 >> ArraysFill.testShortFill | 31 | 1... > > Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays I've spent some time staring at the assembler, everything looks correct to me, so adding my checkmark.. My only "complaint" is that I wish for a wider-scope fix? But thats clearly out-of-scope here. Though it sounds like that is what @eme64 is indeed already thinking about... (This is quite the multi-dimensional optimization problem... arch, size, type, code-size, callsite-constants... etc?) With that realization, I am just fine with an incremental fix just for 'EnableX86ECoreOpts' models. ------------- Marked as reviewed by vpaprotski (Committer). PR Review: https://git.openjdk.org/jdk/pull/26747#pullrequestreview-3274154812 From lmesnik at openjdk.org Sat Sep 27 03:43:56 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 27 Sep 2025 03:43:56 GMT Subject: RFR: 8355631: The events might be generated after VM_DEATH event Message-ID: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com> The JVMTI spec says: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#VMDeath `The VM death event notifies the agent of the termination of the VM. No events will occur after the VMDeath event.` However, current implementation changes state and only after this start disabling events. It might be not a conformance issue, because there is no way to get thread state in the very beginning of event. The main practical issue is that currently certain events are generated when VM is becoming dead. So any function in event should check error against JVMTI_PHASE_DEAD. We can easily trigger it by running tests with enabled https://bugs.openjdk.org/browse/JDK-8352654 The proposed fix to disable all event generation and then post the last (VMDeath) event. After this event is completed change VM phase to death. It's guaranteed that no any events are generated after VMDeath completion. After this fix the VMDeath callback also can't generate any events. The alternative is to disable events posting after VMDeath completion and before changing VM state. However, seems it is still a gap between vm death event completion and disabling events. So user can see events after VMDeath completion. It might be still possible also to wait while all currently executing events are completed. It is not required be specification, might add unneeded complexity. So I want to apply this fix first and then to check if we still any problems. Then, I plan to wait with timeout until all current (and queued) jvmti events are completed with some reasonable timeout. Currently, I haven't seen problems with this fix and https://bugs.openjdk.org/browse/JDK-8352654. ------------- Commit messages: - 8355631: The events might be generated after VM_DEATH event Changes: https://git.openjdk.org/jdk/pull/27504/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27504&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355631 Stats: 17 lines in 2 files changed: 14 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27504.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27504/head:pull/27504 PR: https://git.openjdk.org/jdk/pull/27504 From lmesnik at openjdk.org Sat Sep 27 03:48:20 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 27 Sep 2025 03:48:20 GMT Subject: RFR: 8355631: The events might be generated after VM_DEATH event In-Reply-To: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com> References: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com> Message-ID: <6IQFYfD6ppX24q8JU6tEu1X1CC6slKqkyKRRbbKIr-M=.64213037-af7b-4546-a3d3-4ca078c32b17@github.com> On Thu, 25 Sep 2025 21:43:46 GMT, Leonid Mesnik wrote: > The JVMTI spec says: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#VMDeath > `The VM death event notifies the agent of the termination of the VM. No events will occur after the VMDeath event.` > > However, current implementation changes state and only after this start disabling events. > > It might be not a conformance issue, because there is no way to get thread state in the very beginning of event. > The main practical issue is that currently certain events are generated when VM is becoming dead. So any function in event should check error against JVMTI_PHASE_DEAD. We can easily trigger it by running tests with enabled https://bugs.openjdk.org/browse/JDK-8352654 > > The proposed fix to disable all event generation and then post the last (VMDeath) event. After this event is completed change VM phase to death. It's guaranteed that no any events are generated after VMDeath completion. > > After this fix the VMDeath callback also can't generate any events. > The alternative is to disable events posting after VMDeath completion and before changing VM state. However, seems it is still a gap between vm death event completion and disabling events. So user can see events after VMDeath completion. > > It might be still possible also to wait while all currently executing events are completed. It is not required be specification, might add unneeded complexity. So I want to apply this fix first and then to check if we still any problems. > Then, I plan to wait with timeout until all current (and queued) jvmti events are completed with some reasonable timeout. > Currently, I haven't seen problems with this fix and https://bugs.openjdk.org/browse/JDK-8352654. Note, the `_execution_finished ` is updated with `JvmtiThreadState_lock`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27504#issuecomment-3341119379 From stuefe at openjdk.org Sat Sep 27 06:48:36 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 27 Sep 2025 06:48:36 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps [v5] In-Reply-To: References: Message-ID: > When we run with ASAN enabled and ASAN catches an error, it reports, then stops the JVM. hs-err files and crash dumps at that point would be incredibly useful, though. The ASAN error report itself is seldom enlightening since it only contains native stacks. > > After this patch, the JVM will always produce hs-err files when an ASAN-report happens. It will *only* produce core files if ASAN_OPTIONS `disable_coredump=0` and `abort_on_error=1` and the JVM option `CreateCoredumpOnCrash` had not been disabled (and the limit for core file size is high enough etc, all the usual restrictions on OS level still apply). > > This means that ASAN builds, by default, will continue to *not* generate cores, since ASAN default options inhibit that. See detail in the comments below. > > --- > > Tested on Fedora 42 and Debian 12, both manually and by running the new companion jtreg test. Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: - Update address.cpp - Comment reference to asan_interface.h ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27446/files - new: https://git.openjdk.org/jdk/pull/27446/files/4adc9689..0a1f5361 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27446&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27446&range=03-04 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27446.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27446/head:pull/27446 PR: https://git.openjdk.org/jdk/pull/27446 From stuefe at openjdk.org Sat Sep 27 08:14:14 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 27 Sep 2025 08:14:14 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps [v4] In-Reply-To: References: <4pvCey3FdUMcF29111jhrh2whmwECHBtSvi58ioedc8=.c9f6ff76-292c-4515-a148-6c027c66403e@github.com> Message-ID: On Fri, 26 Sep 2025 20:19:32 GMT, Ashutosh Mehra wrote: > > Documentation for Asan is sparse in general, but it is documented in the header file. I don't know if it was ever not supported - the dlsym'ing I did out of an abundance of caution in case there are older Asan versions around without that functionality. > > okay, I see it in the header file here https://github.com/llvm/llvm-project/blob/d2c189bc739c86bea28e9d603f8973f68869a772/compiler-rt/include/sanitizer/asan_interface.h#L270 If there is no official doc, perhaps just add a reference to this header file in the code where this symbol is referenced. > > > Prediction of the core file path is difficult (with systemd, you'd need to interpret the sysctl kernel.core-pattern value - we don't even manage to do that correctly in hotspot when displaying the core file dumping message). And with Asan, core file size is a bit unpredictable. > > Right, that comes with its own challenges. Scratch that. Thank you, @ashu-mehra ! If you are happy with the current version, mind marking the PR as reviewed? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27446#issuecomment-3341389326 From stuefe at openjdk.org Sat Sep 27 12:00:56 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 27 Sep 2025 12:00:56 GMT Subject: RFR: 8368621: In ASAN builds, attached non-main threads should have meaningful native names Message-ID: <4zmlXlIDkEzmmAPyxid7-9tU1QZPMNA9xcfNdj_vviE=.6797c163-f500-4076-a5df-e384b9b79251@github.com> See issue description and discussion. We set the thread name at the OS level, but only for ASAN builds, since outside of that narrow use case we consider attached threads to be owned by the application, not us, so we don't interfere with it. Tested manually with an ASAN build and a custom java launcher that attaches some native threads. ------------- Commit messages: - start Changes: https://git.openjdk.org/jdk/pull/27535/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27535&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368621 Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27535.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27535/head:pull/27535 PR: https://git.openjdk.org/jdk/pull/27535 From alanb at openjdk.org Sat Sep 27 13:10:04 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 27 Sep 2025 13:10:04 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v3] In-Reply-To: References: Message-ID: > Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500). > > Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP. > > HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX). > > There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package. > > Testing: tier1-6 Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: - Merge branch 'master' into JDK-8353835 - Merge branch 'master' into JDK-8353835 - Improve setters and test cleanup - Merge branch 'master' into JDK-8353835 - Merge branch 'master' into JDK-8353835 - Review feedback - Change ciField::initialize_from to use is_mutable_static_final, suggested by Vladimir Ivanov - Merge branch 'master' into JDK-8353835 - Test cleanup - More improvements - ... and 13 more: https://git.openjdk.org/jdk/compare/af8fb20a...545557d9 ------------- Changes: https://git.openjdk.org/jdk/pull/25115/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25115&range=02 Stats: 4557 lines in 62 files changed: 4380 ins; 54 del; 123 mod Patch: https://git.openjdk.org/jdk/pull/25115.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25115/head:pull/25115 PR: https://git.openjdk.org/jdk/pull/25115 From egahlin at openjdk.org Sat Sep 27 15:44:18 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Sat, 27 Sep 2025 15:44:18 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v3] In-Reply-To: References: Message-ID: On Sat, 27 Sep 2025 13:10:04 GMT, Alan Bateman wrote: >> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500). >> >> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP. >> >> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX). >> >> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package. >> >> Testing: tier1-6 > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: > > - Merge branch 'master' into JDK-8353835 > - Merge branch 'master' into JDK-8353835 > - Improve setters and test cleanup > - Merge branch 'master' into JDK-8353835 > - Merge branch 'master' into JDK-8353835 > - Review feedback > - Change ciField::initialize_from to use is_mutable_static_final, suggested by Vladimir Ivanov > - Merge branch 'master' into JDK-8353835 > - Test cleanup > - More improvements > - ... and 13 more: https://git.openjdk.org/jdk/compare/af8fb20a...545557d9 The JFR changes look good, but by adding @jdk.jfr.internal.RemoveFields("duration") to the jdk.jfr.events.FinalFieldMutationEvent class, the event is emitted without a duration, and the threshold setting can be removed from default.jfc and profile.jfc. There is no longer a need to update TestActiveSettingEvent.java. All the events listed there, e.g. VirtualThreadSubmitFailedEvent, should be removed. I've filed a bug for [this](https://bugs.openjdk.org/browse/JDK-8368809) Is it known whether the top frame of the stack traces originates in the method that mutates the field, or in a JDK internal class? There are two ways to control this. The cheapest is to set the stack trace offset in the jdk.jfr.internal.PlatformEventType::determineStackTraceOffset method, but this may not be feasible if the depth depends on how the call reaches the offer method. In those cases, the jdk.jfr.internal.StackFilter annotation can be used on the jdk.jfr.events.FinalFieldMutationEvent class to filter out specific classes. To prevent bit rot, event.getStackTrace().getFrames().getFirst().getMethod().getName() may be checked in the test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3341864819 From duke at openjdk.org Sat Sep 27 17:04:33 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Sat, 27 Sep 2025 17:04:33 GMT Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time Message-ID: Hi all, This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding. `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem. FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM. Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug. ------------- Commit messages: - Remove extra new line - Add GC CPU MXBeans Changes: https://git.openjdk.org/jdk/pull/27537/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368527 Stats: 146 lines in 11 files changed: 142 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27537.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27537/head:pull/27537 PR: https://git.openjdk.org/jdk/pull/27537 From alanb at openjdk.org Sat Sep 27 17:04:33 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 27 Sep 2025 17:04:33 GMT Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time In-Reply-To: References: Message-ID: On Sat, 27 Sep 2025 11:18:58 GMT, Jonas Norlinder wrote: > Hi all, > > This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding. > > `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem. > > FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM. > > Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug. This proposal will probably require discussion as to whether this is a property of a standard MXBean or a JDK-specific MXBean. It might be that GarbageCollectorMXBean is a better place for this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3341792562 From duke at openjdk.org Sat Sep 27 17:04:34 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Sat, 27 Sep 2025 17:04:34 GMT Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time In-Reply-To: References: Message-ID: On Sat, 27 Sep 2025 14:13:48 GMT, Alan Bateman wrote: >> Hi all, >> >> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding. >> >> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem. >> >> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM. >> >> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug. > > This proposal will probably require discussion as to whether this is a property of a standard MXBean or a JDK-specific MXBean. It might be that GarbageCollectorMXBean is a better place for this. Thanks @AlanBateman. I did first consider `GarbageCollectorMXBean` but given that this interface only exposes a sub-component of the GC at a time it might not fit in well with a systemic method that samples the total GC CPU time. To clarify what I mean with "exposing a sub-component at a time"; consider the following List list = java.lang.management.ManagementFactory.getGarbageCollectorMXBeans(); for (GarbageCollectorMXBean gcMXBean : list) { System.out.println(gcMXBean.getName()); } Its output will be $ java -XX:+UseSerialGC Main.java Copy MarkSweepCompact $ java -XX:+UseParallelGC Main.java PS MarkSweep PS Scavenge java -XX:+UseG1GC Main.java G1 Young Generation G1 Concurrent GC G1 Old Generation $ java -XX:+UseZGC Main.java ZGC Minor Cycles ZGC Minor Pauses ZGC Major Cycles ZGC Major Pauses So no `GarbageCollectorMXBean` for any collector would map nicely to a systemic method like `getGcCpuTime()`. I could be wrong but I don't think there will be many use cases where a user wants/needs to know CPU time per each GC component nor does we currently support such granularity. If we look at the API for `MemoryMXBean` (https://docs.oracle.com/en/java/javase/25/docs/api/java.management/java/lang/management/MemoryMXBean.html) we can se that it do already include a couple of methods to query a "systemic property": * `getHeapMemoryUsage()` * `getNonHeapMemoryUsage()` Additionally it includes a method to request a GC, which made me think that this could be a good fit for this method. That being said if my above observations are incorrect or there is a more appropriate place to put this method I'm happy to update the PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3341917745 From sspitsyn at openjdk.org Sun Sep 28 09:04:55 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sun, 28 Sep 2025 09:04:55 GMT Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired [v10] In-Reply-To: References: Message-ID: > The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27. > > TBD: Need to submit a related CSR. > > There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams: > - Class redefinition/retransformation can impact lambda expressions which are supported with private methods > - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now). > > Testing: > - mach5 tiers 1-6 are good > - may need to run mach5 tiers > 6 Serguei Spitsyn 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 10 additional commits since the last revision: - Merge - Merge - Merge - Merge - Merge - Merge - review: replace RESERVED flag with UNUSED - review: keep right order of the obsoleted VM options - corrected one assert message - 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26232/files - new: https://git.openjdk.org/jdk/pull/26232/files/70a595aa..8af14e76 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=08-09 Stats: 152168 lines in 1493 files changed: 127924 ins; 14723 del; 9521 mod Patch: https://git.openjdk.org/jdk/pull/26232.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26232/head:pull/26232 PR: https://git.openjdk.org/jdk/pull/26232 From kbarrett at openjdk.org Sun Sep 28 11:17:59 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 28 Sep 2025 11:17:59 GMT Subject: RFR: 8367013: Add Atomic to package/replace idiom of volatile var plus AtomicAccess:: operations Message-ID: Please review this change that adds the type Atomic, to use as the type of a variable that is accessed (including writes) concurrently by multiple threads. This is intended to replace (most) uses of the current HotSpot idiom of declaring a variable volatile and accessing that variable using functions from the AtomicAccess class. https://github.com/openjdk/jdk/blame/528f93f8cb9f1fb9c19f31ab80c8a546f47beed2/doc/hotspot-style.md#L138-L147 This change replaces https://github.com/openjdk/jdk/pull/27462. Differences are * Substantially restructured `Atomic`, to be IDE friendly. It's operationally the same, with the same API, hence uses and gtests didn't need to change in that respect. Thanks to @stefank for raising this issue, and for some suggestions toward improvements. * Changed how fetch_then_set for atomic translated types is handled, to avoid having the function there at all if it isn't usable, rather than just removing it via SFINAE, leaving an empty overload set. * Added more gtests. Testing: mach5 tier1-6, GHA sanity tests ------------- Commit messages: - update copyrights - update FreeListAllocator - update nonblockingQueue - update LockFreeStack - convert StringDedupTable - convert SingleWriterSynchronizer - test_atomic - Atomic - add DependentAlwaysFalse Changes: https://git.openjdk.org/jdk/pull/27539/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27539&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367013 Stats: 1515 lines in 13 files changed: 1377 ins; 0 del; 138 mod Patch: https://git.openjdk.org/jdk/pull/27539.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27539/head:pull/27539 PR: https://git.openjdk.org/jdk/pull/27539 From kbarrett at openjdk.org Sun Sep 28 11:17:59 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 28 Sep 2025 11:17:59 GMT Subject: RFR: 8367013: Add Atomic to package/replace idiom of volatile var plus AtomicAccess:: operations In-Reply-To: References: Message-ID: On Sun, 28 Sep 2025 11:10:41 GMT, Kim Barrett wrote: > Please review this change that adds the type Atomic, to use as the type > of a variable that is accessed (including writes) concurrently by multiple > threads. This is intended to replace (most) uses of the current HotSpot idiom > of declaring a variable volatile and accessing that variable using functions > from the AtomicAccess class. > https://github.com/openjdk/jdk/blame/528f93f8cb9f1fb9c19f31ab80c8a546f47beed2/doc/hotspot-style.md#L138-L147 > > This change replaces https://github.com/openjdk/jdk/pull/27462. Differences are > > * Substantially restructured `Atomic`, to be IDE friendly. It's > operationally the same, with the same API, hence uses and gtests didn't need > to change in that respect. Thanks to @stefank for raising this issue, and for > some suggestions toward improvements. > > * Changed how fetch_then_set for atomic translated types is handled, to avoid > having the function there at all if it isn't usable, rather than just removing > it via SFINAE, leaving an empty overload set. > > * Added more gtests. > > Testing: mach5 tier1-6, GHA sanity tests The implementation of Atomic leans heavily on AtomicAccess. But note that some of the Atomic function names differ from the corresponding AtomicAccess function names. Without the AtomicAccess:: prefix, the names from that class are in some cases subtle and easy to overlook, which is not a benefit when dealing with the complexities of lock-free code. This PR includes gtests for the new type. These gtests only test functional behavior, not concurrent access behavior. This PR also includes conversions for a few uses. This provides examples of what the new code will look like. It also provides some additional testing for this change. The plan is that other uses of the volatile + AtomicAccess idiom will be converted incrementally. It is expected that there will be some remaining direct uses of AtomicAccess, in places where conversion to Atomic isn't appropriate. An example is the BitMap::par_xxx suite of functions. This PR contains a sequence of commits, each covering different aspects of the change. It might help to focus on particular commits when reviewing. The HotSpot Style Guide needs to be updated for JDK-8367014 and for this change. That will be done in a followup. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3342949371 From fandreuzzi at openjdk.org Sun Sep 28 13:04:17 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Sun, 28 Sep 2025 13:04:17 GMT Subject: RFR: 8367013: Add Atomic to package/replace idiom of volatile var plus AtomicAccess:: operations In-Reply-To: References: Message-ID: <1mKLWCRvoIT6BgcUQlQ-ypkgW1_TV1QdllOx49Qn_5U=.b8f8a650-9533-43ed-927e-0a47242f559c@github.com> On Sun, 28 Sep 2025 11:10:41 GMT, Kim Barrett wrote: > Please review this change that adds the type Atomic, to use as the type > of a variable that is accessed (including writes) concurrently by multiple > threads. This is intended to replace (most) uses of the current HotSpot idiom > of declaring a variable volatile and accessing that variable using functions > from the AtomicAccess class. > https://github.com/openjdk/jdk/blame/528f93f8cb9f1fb9c19f31ab80c8a546f47beed2/doc/hotspot-style.md#L138-L147 > > This change replaces https://github.com/openjdk/jdk/pull/27462. Differences are > > * Substantially restructured `Atomic`, to be IDE friendly. It's > operationally the same, with the same API, hence uses and gtests didn't need > to change in that respect. Thanks to @stefank for raising this issue, and for > some suggestions toward improvements. > > * Changed how fetch_then_set for atomic translated types is handled, to avoid > having the function there at all if it isn't usable, rather than just removing > it via SFINAE, leaving an empty overload set. > > * Added more gtests. > > Testing: mach5 tier1-6, GHA sanity tests src/hotspot/share/runtime/atomic.hpp line 517: > 515: using ValueType = T; > 516: > 517: // If T is default constructible, construct from a a default constructed T. Suggestion: // If T is default constructible, construct from a default constructed T. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27539#discussion_r2385750050 From alanb at openjdk.org Sun Sep 28 15:03:26 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 28 Sep 2025 15:03:26 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v3] In-Reply-To: References: Message-ID: <4n6Jd4DDZEs0AIzVQrVJemXRF6PzJN2dNfBtShxeus4=.d33fbf78-0c59-464a-af7a-c4fa82a7c637@github.com> On Sat, 27 Sep 2025 15:35:13 GMT, Erik Gahlin wrote: > The JFR changes look good, but by adding @jdk.jfr.internal.RemoveFields("duration") to the jdk.jfr.events.FinalFieldMutationEvent class, the event is emitted without a duration, and the threshold setting is not needed in default.jfc and profile.jfc and special handling in TestActiveSettingEvent.java can be avoided. Thanks, I wasn't aware of `@RemoveFields` to drop the duration from instant events. > Is it known whether the top frame of the stack traces originates in the method that mutates the field, or in a JDK internal class? > > There are two ways to control this. The cheapest is to set the stack trace offset in the jdk.jfr.internal.PlatformEventType::determineStackTraceOffset method, but this may not be feasible if the depth depends on how the call reaches the offer method. In those cases, the jdk.jfr.internal.StackFilter annotation can (also) be used on the jdk.jfr.events.FinalFieldMutationEvent class to filter out specific classes. To prevent bit rot, event.getStackTrace().getFrames().getFirst().getMethod().getName() may be checked in the test. The top frame when recording is 4-5 frames from the API points. It would be too fragile to use the stack depth, esp. with instrumentation injected by tooling, so I'd prefer not use that approach. In addition, one of the API points will record at a different depth to the others so it makes it more awkward. I'll add `@StackFilter` for now and add a test as you suggested to ensure that the event has the expected top frame. I can also add a test to check that the StackFilter value names methods that exist as it would be too easy to refactor and leave stale values in the filter value. We could potentially add a test that scans all events for this annotation and checks the values as this would be useful to do for all events, not just FinalFieldMutation. Has there been any discussion about JFR respecting `@Hidden`? There's something a bit uncomfortable with having different filtering mechanisms, Ideally stack traces, JFR events, JVMTI, ... would use the same filters. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3343664490 From alanb at openjdk.org Sun Sep 28 16:44:56 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 28 Sep 2025 16:44:56 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v4] In-Reply-To: References: Message-ID: > Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500). > > Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP. > > HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX). > > There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package. > > Testing: tier1-6 Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: RemoveFields(duration) and filter internal frames ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25115/files - new: https://git.openjdk.org/jdk/pull/25115/files/545557d9..0041ef4a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25115&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25115&range=02-03 Stats: 57 lines in 5 files changed: 46 ins; 4 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/25115.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25115/head:pull/25115 PR: https://git.openjdk.org/jdk/pull/25115 From kbarrett at openjdk.org Sun Sep 28 19:39:15 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 28 Sep 2025 19:39:15 GMT Subject: RFR: 8367013: Add Atomic to package/replace idiom of volatile var plus AtomicAccess:: operations In-Reply-To: <1mKLWCRvoIT6BgcUQlQ-ypkgW1_TV1QdllOx49Qn_5U=.b8f8a650-9533-43ed-927e-0a47242f559c@github.com> References: <1mKLWCRvoIT6BgcUQlQ-ypkgW1_TV1QdllOx49Qn_5U=.b8f8a650-9533-43ed-927e-0a47242f559c@github.com> Message-ID: On Sun, 28 Sep 2025 13:01:15 GMT, Francesco Andreuzzi wrote: >> Please review this change that adds the type Atomic, to use as the type >> of a variable that is accessed (including writes) concurrently by multiple >> threads. This is intended to replace (most) uses of the current HotSpot idiom >> of declaring a variable volatile and accessing that variable using functions >> from the AtomicAccess class. >> https://github.com/openjdk/jdk/blame/528f93f8cb9f1fb9c19f31ab80c8a546f47beed2/doc/hotspot-style.md#L138-L147 >> >> This change replaces https://github.com/openjdk/jdk/pull/27462. Differences are >> >> * Substantially restructured `Atomic`, to be IDE friendly. It's >> operationally the same, with the same API, hence uses and gtests didn't need >> to change in that respect. Thanks to @stefank for raising this issue, and for >> some suggestions toward improvements. >> >> * Changed how fetch_then_set for atomic translated types is handled, to avoid >> having the function there at all if it isn't usable, rather than just removing >> it via SFINAE, leaving an empty overload set. >> >> * Added more gtests. >> >> Testing: mach5 tier1-6, GHA sanity tests > > src/hotspot/share/runtime/atomic.hpp line 517: > >> 515: using ValueType = T; >> 516: >> 517: // If T is default constructible, construct from a a default constructed T. > > Suggestion: > > // If T is default constructible, construct from a default constructed T. Thanks. Will fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27539#discussion_r2386297473 From dholmes at openjdk.org Mon Sep 29 01:16:26 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 29 Sep 2025 01:16:26 GMT Subject: RFR: 8368124: Show useful thread names in ASAN reports [v7] In-Reply-To: References: <4Qpoc_71yo7P8S5i7mNo-Neaia4zhQONf71WZpKqXmM=.575ac5a6-1796-4814-bdbe-e2a5091d27a1@github.com> Message-ID: On Thu, 25 Sep 2025 21:45:01 GMT, David Holmes wrote: >> Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: >> >> - reorder includes >> - remove redundant pthread_setname call > > I just remembered something - will this work on Alpine Linux with Musl-C? > @dholmes-ora sorry, I missed you comment change suggestion. Should I do that in a follow-up patch? If you could so when next in the area that would be good. It was actually that equivalence that I was concerned about for musl-C, but I just checked the sources and it does the same for the current thread. Thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/27395#issuecomment-3344516867 From dholmes at openjdk.org Mon Sep 29 01:23:24 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 29 Sep 2025 01:23:24 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps [v5] In-Reply-To: References: Message-ID: On Sat, 27 Sep 2025 06:48:36 GMT, Thomas Stuefe wrote: >> When we run with ASAN enabled and ASAN catches an error, it reports, then stops the JVM. hs-err files and crash dumps at that point would be incredibly useful, though. The ASAN error report itself is seldom enlightening since it only contains native stacks. >> >> After this patch, the JVM will always produce hs-err files when an ASAN-report happens. It will *only* produce core files if ASAN_OPTIONS `disable_coredump=0` and `abort_on_error=1` and the JVM option `CreateCoredumpOnCrash` had not been disabled (and the limit for core file size is high enough etc, all the usual restrictions on OS level still apply). >> >> This means that ASAN builds, by default, will continue to *not* generate cores, since ASAN default options inhibit that. See detail in the comments below. >> >> --- >> >> Tested on Fedora 42 and Debian 12, both manually and by running the new companion jtreg test. > > Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: > > - Update address.cpp > - Comment reference to asan_interface.h src/hotspot/share/sanitizers/address.cpp line 62: > 60: log_warning(asan)("*** Failed to install JVM callback for ASAN. ASAN errors will not generate hs-err files. ***"); > 61: return; > 62: } Doesn't this just mean ASAN is not present at runtime? It isn't really an error installing the callback. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27446#discussion_r2386486400 From dholmes at openjdk.org Mon Sep 29 01:36:22 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 29 Sep 2025 01:36:22 GMT Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time In-Reply-To: References: Message-ID: On Sat, 27 Sep 2025 11:18:58 GMT, Jonas Norlinder wrote: > Hi all, > > This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding. > > `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem. > > FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM. > > Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug. I don't think this is appropriately placed in MemoryMXBean. I will discuss in the CSR request ------------- PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3344548511 From dzhang at openjdk.org Mon Sep 29 01:43:22 2025 From: dzhang at openjdk.org (Dingli Zhang) Date: Mon, 29 Sep 2025 01:43:22 GMT Subject: RFR: 8368722: RISC-V: Several vector load/store tests fail on riscv without support for misaligned vector access In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 14:36:30 GMT, Vladimir Ivanov wrote: > It's not a test bug, but a product one. The Vector API deliberately doesn't require vector accesses to be naturally aligned. If a platform doesn't support misaligned vector accesses it has to either properly emulate them or fail to intrinsify corresponding vector intrinsics. @iwanowww Thanks for the comment. I see the requirement of vector api now. I am wondering if there is a simple way to disable the corresponding vector intrinsics on such a platform without affecting the superword optimization (the auto-vectorizer). Will turning off the `EnableVectorSupport` VM option do? Do you have any suggestions? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27506#issuecomment-3344563706 From dholmes at openjdk.org Mon Sep 29 02:30:22 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 29 Sep 2025 02:30:22 GMT Subject: RFR: 8368727: CDS custom loader support causes asserts during class unloading In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 06:11:54 GMT, Ioi Lam wrote: > When loading a class `k` from the CDS archive on behalf of a custom class loader, we were calling `loader_data->add_class(k)` too early. If the loading of `k` fails, it may be in `loader_data->_klasses`, but `k->init_state()` will remain `allocated`. This causes an assert during class unloading: > > > # assert(ik->is_loaded()) failed: class should be loaded 0x000000000b518eb8 > V [libjvm.so+0xfa6bd5] InstanceKlass::unload_class(InstanceKlass*)+0x555 (instanceKlass.cpp:2870) > V [libjvm.so+0xa790e3] ClassLoaderData::classes_do(void (*)(InstanceKlass*))+0xc3 (classLoaderData.cpp:441 > > > The fix is to move the `loader_data->add_class(k)` call to `k->Klass::restore_unshareable_info()`. This is the same location as if `k` were loaded by the 3 built-in class loaders. > > This was discovered when running some JCK tests in AOT mode. I've added a reproducer as a jtreg test case. src/hotspot/share/classfile/systemDictionaryShared.cpp line 177: > 175: // No longer holding SharedDictionary_lock > 176: // No need to lock, as can be held only by a single thread. > 177: loader_data->add_class(ik); Are the comments pertaining to the `add_class` call? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27511#discussion_r2386536063 From dholmes at openjdk.org Mon Sep 29 02:30:23 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 29 Sep 2025 02:30:23 GMT Subject: RFR: 8368727: CDS custom loader support causes asserts during class unloading In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 02:20:34 GMT, David Holmes wrote: >> When loading a class `k` from the CDS archive on behalf of a custom class loader, we were calling `loader_data->add_class(k)` too early. If the loading of `k` fails, it may be in `loader_data->_klasses`, but `k->init_state()` will remain `allocated`. This causes an assert during class unloading: >> >> >> # assert(ik->is_loaded()) failed: class should be loaded 0x000000000b518eb8 >> V [libjvm.so+0xfa6bd5] InstanceKlass::unload_class(InstanceKlass*)+0x555 (instanceKlass.cpp:2870) >> V [libjvm.so+0xa790e3] ClassLoaderData::classes_do(void (*)(InstanceKlass*))+0xc3 (classLoaderData.cpp:441 >> >> >> The fix is to move the `loader_data->add_class(k)` call to `k->Klass::restore_unshareable_info()`. This is the same location as if `k` were loaded by the 3 built-in class loaders. >> >> This was discovered when running some JCK tests in AOT mode. I've added a reproducer as a jtreg test case. > > src/hotspot/share/classfile/systemDictionaryShared.cpp line 177: > >> 175: // No longer holding SharedDictionary_lock >> 176: // No need to lock, as can be held only by a single thread. >> 177: loader_data->add_class(ik); > > Are the comments pertaining to the `add_class` call? Why not just move this to after the successful `load_shared_class` below? It is very hard to see the complete call sequence to when `restore_unshareable_info` gets called, to know that moving it there makes sense. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27511#discussion_r2386544451 From wenanjian at openjdk.org Mon Sep 29 02:31:18 2025 From: wenanjian at openjdk.org (Anjian Wen) Date: Mon, 29 Sep 2025 02:31:18 GMT Subject: RFR: 8368724: RISC-V: Check if unaligned_access is enabled before use In-Reply-To: References: <1Um6PaMwVL_OB6ZMfl2HEc7r7-0xuwTR4prgFKeepfo=.26d2deac-ad80-4e68-b4e3-b04a047261f6@github.com> Message-ID: On Fri, 26 Sep 2025 10:51:06 GMT, Hamlin Li wrote: >>> @Hamlin-Li Thanks for your review. According to the current use of `unaligned_access.value`, if it is not enabled, then using value will depend on the default value `-1`. This change is to try to make the use of `unaligned_access.value` more reasonable. Maybe we can keep this judgment and consider removing the Avoid flag latter? >> >> If the default value is `-1`, then `unaligned_access.value() == MISALIGNED_FAST` can only be true when it's enabled, so that makes the extra check added in this pr unnecessary for `UseUnalignedAccesses`. >> As for `AvoidUnalignedAccesses`, there is a discussion here to remove `AvoidUnalignedAccesses`: https://github.com/openjdk/jdk/pull/27445#pullrequestreview-3257314698. >> So my suggestion is to just remove `AvoidUnalignedAccesses` in riscv, how do you think about it? > >> So my suggestion is to just remove `AvoidUnalignedAccesses` in riscv, how do you think about it? > > I guess no one's already working it? Maybe you could take it if you are available. :) > > @Hamlin-Li Thanks for your review. According to the current use of `unaligned_access.value`, if it is not enabled, then using value will depend on the default value `-1`. This change is to try to make the use of `unaligned_access.value` more reasonable. Maybe we can keep this judgment and consider removing the Avoid flag latter? > > If the default value is `-1`, then `unaligned_access.value() == MISALIGNED_FAST` can only be true when it's enabled, so that makes the extra check added in this pr unnecessary for `UseUnalignedAccesses`. As for `AvoidUnalignedAccesses`, there is a discussion here to remove `AvoidUnalignedAccesses`: [#27445 (review)](https://github.com/openjdk/jdk/pull/27445#pullrequestreview-3257314698). So my suggestion is to just remove `AvoidUnalignedAccesses` in riscv, how do you think about it? @Hamlin-Li Oh, Thanks! I get it, I think it makes sence. I will try to figure out how to modify the code and remove `AvoidUnalignedAccesses` together ------------- PR Comment: https://git.openjdk.org/jdk/pull/27510#issuecomment-3344638329 From fyang at openjdk.org Mon Sep 29 02:36:40 2025 From: fyang at openjdk.org (Fei Yang) Date: Mon, 29 Sep 2025 02:36:40 GMT Subject: RFR: 8368732: RISC-V: Detect support for misaligned vector access via hwprobe [v3] In-Reply-To: References: Message-ID: <8BOYwzoTvlmwqiR5myDTH3UhpeSt9-rXGnawA0xd_Vc=.3de5d7f9-ce04-4df6-a650-f7c90c6e4253@github.com> > Hi, this is a followup change after [JDK-8368366](https://bugs.openjdk.org/browse/JDK-8368366). > > According to the latest RISC-V linux hardware probing syscall [1], the performance of misaligned memory accesses has been divided into two cases: `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` and `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` for scalar and vector respectively. > > This aligns `AlignVector` with `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF`. That is if the misaligned vector access is fast, we set `AlignVector` to false in the hope that it will save instructions handling address alignment thus improves performance. > > This choose to keep the use of `RISCV_HWPROBE_KEY_CPUPERF_0` which is now deprecated and returns similar values > to `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` for backward compatibility with old linux kernels. > > Manually checked the result on platforms w/wo fast misaligned vector accesses by running: > `$java -XX:+PrintFlagsFinal -version | grep AlignVector` > > [1] https://docs.kernel.org/arch/riscv/hwprobe.html Fei Yang has updated the pull request incrementally with one additional commit since the last revision: Macro names ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27512/files - new: https://git.openjdk.org/jdk/pull/27512/files/45cbcd9e..444bfc35 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27512&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27512&range=01-02 Stats: 12 lines in 2 files changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/27512.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27512/head:pull/27512 PR: https://git.openjdk.org/jdk/pull/27512 From fyang at openjdk.org Mon Sep 29 02:49:16 2025 From: fyang at openjdk.org (Fei Yang) Date: Mon, 29 Sep 2025 02:49:16 GMT Subject: RFR: 8368732: RISC-V: Detect support for misaligned vector access via hwprobe [v2] In-Reply-To: References: Message-ID: <9CTcYgEE2cOWk_MtCIHg_cE2EtlnwGJ6QWV7L27N93M=.d47b0ed6-3a6b-44c9-8730-670c29ab4415@github.com> On Fri, 26 Sep 2025 08:36:19 GMT, Hamlin Li wrote: >> Fei Yang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains three new commits since the last revision: >> >> - More white spaces >> - White spaces >> - 8368732: RISC-V: Detect support for misaligned vector access via hwprobe > > src/hotspot/cpu/riscv/vm_version_riscv.cpp line 181: > >> 179: } >> 180: >> 181: if (FLAG_IS_DEFAULT(AlignVector) && unaligned_vector.enabled()) { > > Seems this `unaligned_vector.enabled` is not necessary? The purpose is to give a consistent view of how the these extensions should be used. That is we only use the value of the extension when it is enabled. Otherwise, we are relying on the default value -1, which doesn't seem safe to me. And it shouldn't be a issue in performance to have this check here. What do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27512#discussion_r2386558533 From fyang at openjdk.org Mon Sep 29 02:58:41 2025 From: fyang at openjdk.org (Fei Yang) Date: Mon, 29 Sep 2025 02:58:41 GMT Subject: RFR: 8368732: RISC-V: Detect support for misaligned vector access via hwprobe [v4] In-Reply-To: References: Message-ID: > Hi, this is a followup change after [JDK-8368366](https://bugs.openjdk.org/browse/JDK-8368366). > > According to the latest RISC-V linux hardware probing syscall [1], the performance of misaligned memory accesses has been divided into two cases: `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` and `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` for scalar and vector respectively. > > This aligns `AlignVector` with `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF`. That is if the misaligned vector access is fast, we set `AlignVector` to false in the hope that it will save instructions handling address alignment thus improves performance. > > This choose to keep the use of `RISCV_HWPROBE_KEY_CPUPERF_0` which is now deprecated and returns similar values > to `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` for backward compatibility with old linux kernels. > > Manually checked the result on platforms w/wo fast misaligned vector accesses by running: > `$java -XX:+PrintFlagsFinal -version | grep AlignVector` > > [1] https://docs.kernel.org/arch/riscv/hwprobe.html Fei Yang has updated the pull request incrementally with one additional commit since the last revision: Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27512/files - new: https://git.openjdk.org/jdk/pull/27512/files/444bfc35..a80ee075 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27512&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27512&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27512.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27512/head:pull/27512 PR: https://git.openjdk.org/jdk/pull/27512 From duke at openjdk.org Mon Sep 29 03:27:17 2025 From: duke at openjdk.org (erifan) Date: Mon, 29 Sep 2025 03:27:17 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v8] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 10:11:47 GMT, Jatin Bhateja wrote: >> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction. >> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails. >> >> Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java). >> >> Vector API jtreg tests pass at AVX level 2, remaining validation in progress. >> >> Performance numbers: >> >> >> System : 13th Gen Intel(R) Core(TM) i3-1315U >> >> Baseline: >> Benchmark (size) Mode Cnt Score Error Units >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 9444.444 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 10009.319 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9081.926 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 6085.825 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 6505.378 ops/ms >> VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 6204.489 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 1651.334 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 1642.784 ops/ms >> VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1474.808 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 10399.394 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 10502.894 ops/ms >> VectorSliceB... > > 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 101: > 99: .slice(0, ByteVector.fromArray(BSP, bsrc2, i)) > 100: .intoArray(bdst, i); > 101: } Would you mind adding a correctness check for these tests, for byte type, like: @DontInline static void verifyVectorSliceByte(int origin) { for (int i = 0; i < BSP.loopBound(SIZE); i += BSP.length()) { int index = i; for (int j = i + origin; j < i + BSP.length(); j++) { Asserts.assertEquals(bsrc1[j], bdst[index++]); } for (int j = i; j < i + origin; j++) { Asserts.assertEquals(bsrc2[j], bdst[index++]); } } } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2386593970 From fyang at openjdk.org Mon Sep 29 03:35:20 2025 From: fyang at openjdk.org (Fei Yang) Date: Mon, 29 Sep 2025 03:35:20 GMT Subject: RFR: 8367253: RISC-V: refactor dependent cpu extensions [v5] In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 08:19:32 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> >> Dependent extensions could be improved in several ways. >> >> Currently, the dependent cpu extensions are processed in 2 separate places: >> 1. update_flag() when calling VM_Version::setup_cpu_available_features() >> 2. at the end of VM_Version::common_initialize(). >> >> And, dependency relationship can only be expressed in (1:1) way, can not be expressed (1:N) way, but in fact some extensions can depend on several different other extensions, for example, zvfh depends on zvf and rvv. It's would be better to support this (1:N) relationship. >> >> So, this PR brings several benefits: >> 1. VM options directly related to CPU extensions are automatically set, and they are all set in one place. >> 2. keep synchronization between CPU extensions (information in RVFeatureValue) and and VM options. Previously, code in common_initialize wont' sync to RVFeatureValue, unless do it manually, which is error-prone. >> 3. support to express (1:N) dependency relationship among cpu extensions and related vm options. >> >> Thanks! >> >> >> ## Test >> >> >> $TEST_JDK/bin/java -XX:+UnlockExperimentalVMOptions -XX:-UseRVV -XX:+PrintFlagsFinal -version | grep -e UseRVV -e UseZvbc -e UseZvfh -e UseZvkn >> OpenJDK 64-Bit Server VM warning: Cannot enable UseZvbb on cpu without any of the supports: v (disabled) >> OpenJDK 64-Bit Server VM warning: Cannot enable UseZvbc on cpu without any of the supports: v (disabled) >> OpenJDK 64-Bit Server VM warning: Cannot enable UseZvfh on cpu without any of the supports: v (disabled), Zfh (enabled) >> bool UseRVV = false {ARCH diagnostic} {command line} >> bool UseZvbc = false {ARCH experimental} {default} >> bool UseZvfh = false {ARCH diagnostic} {default} >> bool UseZvkn = false {ARCH experimental} {default} >> >> >> >> $TEST_JDK/bin/java -XX:+UnlockExperimentalVMOptions -XX:-UseZfh -XX:+PrintFlagsFinal -version | grep -e UseRVV -e UseZvbc -e UseZvfh -e UseZvkn >> OpenJDK 64-Bit Server VM warning: Cannot enable UseZvfh on cpu without any of the supports: v (enabled), Zfh (disabled) >> bool UseRVV = true {ARCH diagnostic} {default} >> bool UseZvbc = true ... > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > minor Hi, Thanks for the refactoring work. I have a small question. src/hotspot/cpu/riscv/vm_version_riscv.cpp line 75: > 73: > 74: void VM_Version::initialize() { > 75: ResourceMark rm; What's this change for? src/hotspot/cpu/riscv/vm_version_riscv.hpp line 103: > 101: } > 102: > 103: void verify_deps(RVFeatureValue* dep0, ...) { Not used anywhere? ------------- PR Review: https://git.openjdk.org/jdk/pull/27171#pullrequestreview-3277733329 PR Review Comment: https://git.openjdk.org/jdk/pull/27171#discussion_r2386582260 PR Review Comment: https://git.openjdk.org/jdk/pull/27171#discussion_r2386581994 From duke at openjdk.org Mon Sep 29 04:09:19 2025 From: duke at openjdk.org (erifan) Date: Mon, 29 Sep 2025 04:09:19 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v8] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 10:11:47 GMT, Jatin Bhateja wrote: >> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction. >> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails. >> >> Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java). >> >> Vector API jtreg tests pass at AVX level 2, remaining validation in progress. >> >> Performance numbers: >> >> >> System : 13th Gen Intel(R) Core(TM) i3-1315U >> >> Baseline: >> Benchmark (size) Mode Cnt Score Error Units >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 9444.444 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 10009.319 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9081.926 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 6085.825 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 6505.378 ops/ms >> VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 6204.489 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 1651.334 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 1642.784 ops/ms >> VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1474.808 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 10399.394 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 10502.894 ops/ms >> VectorSliceB... > > 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 130: > 128: for (int i = 0; i < BSP.loopBound(SIZE); i += BSP.length()) { > 129: ByteVector.fromArray(BSP, bsrc1, i) > 130: .slice(16, ByteVector.fromArray(BSP, bsrc2, i)) `16` may out of bounds when this test is run with option `-XX:MaxVectorSize=8` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2386633254 From dholmes at openjdk.org Mon Sep 29 04:48:17 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 29 Sep 2025 04:48:17 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v8] In-Reply-To: <7NmgdmfTkUlL6XJSOOi8QoroX0B-wYYqcrKswicgNls=.2bdc9156-c580-41b7-a2d0-1f8202d52007@github.com> References: <7NmgdmfTkUlL6XJSOOi8QoroX0B-wYYqcrKswicgNls=.2bdc9156-c580-41b7-a2d0-1f8202d52007@github.com> Message-ID: On Thu, 25 Sep 2025 12:23:11 GMT, Johan Sj?len wrote: >> Hi, >> >> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array` to store the offsets in and an `Array` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`. >> >> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately. >> >> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc. >> >> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement. >> >> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Serguei's review Updates look good. A couple of minor nits spotted. src/hotspot/share/oops/constantPool.cpp line 761: > 759: if (!(which >= 0 && which < cpool->resolved_method_entries_length())) { > 760: // FIXME: should be an assert > 761: log_debug(class, resolve)("bad bsm %d in:", which); cpool->print(); Suggestion: log_debug(class, resolve)("bad BSM %d in:", which); cpool->print(); src/hotspot/share/oops/constantPool.cpp line 2303: > 2301: st->print("constant pool [%d]", length()); > 2302: if (has_preresolution()) st->print("/preresolution"); > 2303: if (!bsm_entries().is_empty()) st->print("/bsms[%d]", bsm_entries().bootstrap_methods()->length()); Suggestion: if (!bsm_entries().is_empty()) st->print("/BSMs[%d]", bsm_entries().bootstrap_methods()->length()); src/hotspot/share/oops/constantPool.cpp line 2358: > 2356: BSMAttributeEntries::start_extension(const BSMAttributeEntries& other, ClassLoaderData* loader_data, TRAPS) { > 2357: InsertionIterator iter = start_extension(other.number_of_entries(), other.array_length(), > 2358: loader_data, CHECK_(BSMAttributeEntries::InsertionIterator())); Suggestion: InsertionIterator iter = start_extension(other.number_of_entries(), other.array_length(), loader_data, CHECK_(BSMAttributeEntries::InsertionIterator())); ------------- PR Review: https://git.openjdk.org/jdk/pull/27198#pullrequestreview-3277861284 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2386675664 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2386677067 PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2386677720 From dholmes at openjdk.org Mon Sep 29 05:32:17 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 29 Sep 2025 05:32:17 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing [v9] In-Reply-To: References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> Message-ID: On Tue, 23 Sep 2025 15:02:51 GMT, Johannes Bechberger wrote: >> This change hopefully fixes the test failures by making the test cases more resilient. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Fix build issue This seems to have stalled. If there is no fix forthcoming I will ProblemList the test ... though making the test flagless would exclude it from running in the tiers where we have seen failures so that could be a short-term fix whilst this more elaborate fix is finalized. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27293#issuecomment-3345013120 From jbhateja at openjdk.org Mon Sep 29 06:06:17 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 29 Sep 2025 06:06:17 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v8] In-Reply-To: References: Message-ID: On Wed, 20 Aug 2025 10:11:47 GMT, Jatin Bhateja wrote: >> Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction. >> It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails. >> >> Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java). >> >> Vector API jtreg tests pass at AVX level 2, remaining validation in progress. >> >> Performance numbers: >> >> >> System : 13th Gen Intel(R) Core(TM) i3-1315U >> >> Baseline: >> Benchmark (size) Mode Cnt Score Error Units >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 9444.444 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 10009.319 ops/ms >> VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9081.926 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 6085.825 ops/ms >> VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 6505.378 ops/ms >> VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 6204.489 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 1651.334 ops/ms >> VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 1642.784 ops/ms >> VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1474.808 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 10399.394 ops/ms >> VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 10502.894 ops/ms >> VectorSliceB... > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Update callGenerator.hpp copyright year Hi @erifan , Thanks for your comments. I will address them soon, please keep reviewing in the meantime :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3345152738 From mhaessig at openjdk.org Mon Sep 29 06:07:19 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Mon, 29 Sep 2025 06:07:19 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 Marked as reviewed by mhaessig (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27059#pullrequestreview-3278052544 From stuefe at openjdk.org Mon Sep 29 06:11:36 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 29 Sep 2025 06:11:36 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps [v6] In-Reply-To: References: Message-ID: > When we run with ASAN enabled and ASAN catches an error, it reports, then stops the JVM. hs-err files and crash dumps at that point would be incredibly useful, though. The ASAN error report itself is seldom enlightening since it only contains native stacks. > > After this patch, the JVM will always produce hs-err files when an ASAN-report happens. It will *only* produce core files if ASAN_OPTIONS `disable_coredump=0` and `abort_on_error=1` and the JVM option `CreateCoredumpOnCrash` had not been disabled (and the limit for core file size is high enough etc, all the usual restrictions on OS level still apply). > > This means that ASAN builds, by default, will continue to *not* generate cores, since ASAN default options inhibit that. See detail in the comments below. > > --- > > Tested on Fedora 42 and Debian 12, both manually and by running the new companion jtreg test. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Update address.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27446/files - new: https://git.openjdk.org/jdk/pull/27446/files/0a1f5361..e2503954 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27446&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27446&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27446.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27446/head:pull/27446 PR: https://git.openjdk.org/jdk/pull/27446 From stuefe at openjdk.org Mon Sep 29 06:11:39 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 29 Sep 2025 06:11:39 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps [v5] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 01:20:56 GMT, David Holmes wrote: >> Thomas Stuefe has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update address.cpp >> - Comment reference to asan_interface.h > > src/hotspot/share/sanitizers/address.cpp line 62: > >> 60: log_warning(asan)("*** Failed to install JVM callback for ASAN. ASAN errors will not generate hs-err files. ***"); >> 61: return; >> 62: } > > Doesn't this just mean ASAN is not present at runtime? It isn't really an error installing the callback. ASAN would work, but hs-err files would be missing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27446#discussion_r2386801071 From stuefe at openjdk.org Mon Sep 29 06:11:39 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 29 Sep 2025 06:11:39 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps [v5] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 06:06:31 GMT, Thomas Stuefe wrote: >> src/hotspot/share/sanitizers/address.cpp line 62: >> >>> 60: log_warning(asan)("*** Failed to install JVM callback for ASAN. ASAN errors will not generate hs-err files. ***"); >>> 61: return; >>> 62: } >> >> Doesn't this just mean ASAN is not present at runtime? It isn't really an error installing the callback. > > ASAN would work, but hs-err files would be missing. I changed it to info logging ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27446#discussion_r2386802261 From mbaesken at openjdk.org Mon Sep 29 07:09:28 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 29 Sep 2025 07:09:28 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps [v6] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 06:11:36 GMT, Thomas Stuefe wrote: >> When we run with ASAN enabled and ASAN catches an error, it reports, then stops the JVM. hs-err files and crash dumps at that point would be incredibly useful, though. The ASAN error report itself is seldom enlightening since it only contains native stacks. >> >> After this patch, the JVM will always produce hs-err files when an ASAN-report happens. It will *only* produce core files if ASAN_OPTIONS `disable_coredump=0` and `abort_on_error=1` and the JVM option `CreateCoredumpOnCrash` had not been disabled (and the limit for core file size is high enough etc, all the usual restrictions on OS level still apply). >> >> This means that ASAN builds, by default, will continue to *not* generate cores, since ASAN default options inhibit that. See detail in the comments below. >> >> --- >> >> Tested on Fedora 42 and Debian 12, both manually and by running the new companion jtreg test. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Update address.cpp Marked as reviewed by mbaesken (Reviewer). Looks okay to me, but we have to deal now with the many hserr files generated by the asanized-binary CI runs (fix some/all of the issues? or rewrite our test framework ?) ; for for now to asan any more in our tests. ------------- PR Review: https://git.openjdk.org/jdk/pull/27446#pullrequestreview-3278213175 PR Comment: https://git.openjdk.org/jdk/pull/27446#issuecomment-3345323184 From jbechberger at openjdk.org Mon Sep 29 07:26:15 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Mon, 29 Sep 2025 07:26:15 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing [v9] In-Reply-To: References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> Message-ID: On Tue, 23 Sep 2025 15:02:51 GMT, Johannes Bechberger wrote: >> This change hopefully fixes the test failures by making the test cases more resilient. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Fix build issue I fixed all the issues known to me. Are there still any issues? I'm waiting for feedback after I fixed some major issues ------------- PR Comment: https://git.openjdk.org/jdk/pull/27293#issuecomment-3345415049 From dzhang at openjdk.org Mon Sep 29 07:32:27 2025 From: dzhang at openjdk.org (Dingli Zhang) Date: Mon, 29 Sep 2025 07:32:27 GMT Subject: RFR: 8368732: RISC-V: Detect support for misaligned vector access via hwprobe [v4] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 02:58:41 GMT, Fei Yang wrote: >> Hi, this is a followup change after [JDK-8368366](https://bugs.openjdk.org/browse/JDK-8368366). >> >> According to the latest RISC-V linux hardware probing syscall [1], the performance of misaligned memory accesses has been divided into two cases: `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` and `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` for scalar and vector respectively. >> >> This aligns `AlignVector` with `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF`. That is if the misaligned vector access is fast, we set `AlignVector` to false in the hope that it will save instructions handling address alignment thus improves performance. >> >> This choose to keep the use of `RISCV_HWPROBE_KEY_CPUPERF_0` which is now deprecated and returns similar values >> to `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` for backward compatibility with old linux kernels. >> >> Manually checked the result on platforms w/wo fast misaligned vector accesses by running: >> `$java -XX:+PrintFlagsFinal -version | grep AlignVector` >> >> [1] https://docs.kernel.org/arch/riscv/hwprobe.html > > Fei Yang has updated the pull request incrementally with one additional commit since the last revision: > > Fix LGTM, thanks! ------------- Marked as reviewed by dzhang (Author). PR Review: https://git.openjdk.org/jdk/pull/27512#pullrequestreview-3278298483 From duke at openjdk.org Mon Sep 29 08:15:11 2025 From: duke at openjdk.org (duke) Date: Mon, 29 Sep 2025 08:15:11 GMT Subject: RFR: 8367485: os::physical_memory is broken in 32-bit JVMs when running on 64-bit OSes [v14] In-Reply-To: <3wQZ3ZsNCsP6GYOGSv83Y_ZuhyW6zsUaFkQjeiEtc8I=.5788cb9d-1633-428a-98d0-af37611ca052@github.com> References: <3wQZ3ZsNCsP6GYOGSv83Y_ZuhyW6zsUaFkQjeiEtc8I=.5788cb9d-1633-428a-98d0-af37611ca052@github.com> Message-ID: On Fri, 26 Sep 2025 07:32:42 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. >> >> The issue is addressed by changing the output type of all related functions to `physical_memory_size_type`, which is an alias to `uint64_t`. >> >> Tested in tiers 1 - 5. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8367485: Fixed typos in the comment. @toxaart Your change (at version 8601871e1101c4ea20f310f72dfe2fe40fdc4cc2) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27335#issuecomment-3345599522 From azafari at openjdk.org Mon Sep 29 08:29:57 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 29 Sep 2025 08:29:57 GMT Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer In-Reply-To: <-Ct2yCIbRn7bSazmFKxlMPMeP85zAZk3kUfP9ele4so=.78e5ec0f-2d17-45e6-a68d-9fff149577c1@github.com> References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com> <-Ct2yCIbRn7bSazmFKxlMPMeP85zAZk3kUfP9ele4so=.78e5ec0f-2d17-45e6-a68d-9fff149577c1@github.com> Message-ID: On Wed, 27 Aug 2025 14:19:23 GMT, Johan Sj?len wrote: >> The minimum acceptable value was 0 where using it as address was problematic according to UBSAN. >> The acceptable value is changed to 64K. >> >> Tests: >> linux-x64 tier1 > > It seems to me like we can fix the ubsan issue by avoiding the cast into pointers and computing through `size_t` as far as possible, and converting into pointer when necessary. > > For example > > ```c++ > size_t aligned_heap_base_min_address = align_up(HeapBaseMinAddress, alignment); > size_t noaccess_prefix = ((aligned_heap_base_min_address + size) > OopEncodingHeapMax) ? noaccess_prefix_size : 0; > > if (!FLAG_IS_DEFAULT(HeapBaseMinAddress)) { > reserved = try_reserve_memory(size + noaccess_prefix, alignment, page_size, static_cast(aligned_heap_base_min_address)); > if (reserved.base() != static_cast(aligned_heap_base_min_address)) { // Enforce this exact address. > release(reserved); > reserved = {}; > } > } > > > The semantics of reserving a `null` base address is still preserved as meaning "don't care where you put it" then. Someone from GC needs to look at this and see whether or not an undefined (implicitly 0?) HeapBaseMinAddress is meant to have that type of meaning. @jdksjolen and @xmas92, would you please check if your comments are applied here. TIA. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3345655077 From stuefe at openjdk.org Mon Sep 29 08:36:15 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 29 Sep 2025 08:36:15 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps [v7] In-Reply-To: References: Message-ID: > When we run with ASAN enabled and ASAN catches an error, it reports, then stops the JVM. hs-err files and crash dumps at that point would be incredibly useful, though. The ASAN error report itself is seldom enlightening since it only contains native stacks. > > After this patch, the JVM will always produce hs-err files when an ASAN-report happens. It will *only* produce core files if ASAN_OPTIONS `disable_coredump=0` and `abort_on_error=1` and the JVM option `CreateCoredumpOnCrash` had not been disabled (and the limit for core file size is high enough etc, all the usual restrictions on OS level still apply). > > This means that ASAN builds, by default, will continue to *not* generate cores, since ASAN default options inhibit that. See detail in the comments below. > > --- > > Tested on Fedora 42 and Debian 12, both manually and by running the new companion jtreg test. Thomas Stuefe has updated the pull request incrementally with 104 additional commits since the last revision: - 8368715: Serial: Add GCTraceTime for marking from roots subphases during full gc marking Reviewed-by: fandreuzzi, tschatzl, iwalulya - 8366582: Test jdk/jshell/ToolSimpleTest.java failed: provider not found Reviewed-by: asotona - 8368754: runtime/cds/appcds/SignedJar.java log regex is too strict Reviewed-by: iklam, dholmes - 8367795: HeadlessMalfunctionTest may fail due to timeout Reviewed-by: prr - 8368307: Shenandoah: get_next_bit_impl should special case weak and strong mark bits Reviewed-by: wkemper - 8368668: Several vmTestbase/vm/gc/compact tests timed out on large memory machine Reviewed-by: lmesnik - 8366561: Improve documentation for how the -Xlint flag works Reviewed-by: vromero - 8364305: Support AVX10 saturating floating point conversion instructions Reviewed-by: sviswanathan, sparasa, jbhateja - 8365057: Add support for java.util.concurrent lock information to Thread.dump_to_file Co-authored-by: Alex Menkov Co-authored-by: Alan Bateman Reviewed-by: sspitsyn, alanb - 8368498: Use JUnit instead of TestNG for jdk_text tests Reviewed-by: naoto - ... and 94 more: https://git.openjdk.org/jdk/compare/e2503954...8412f5bf ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27446/files - new: https://git.openjdk.org/jdk/pull/27446/files/e2503954..8412f5bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27446&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27446&range=05-06 Stats: 18580 lines in 510 files changed: 10485 ins; 5552 del; 2543 mod Patch: https://git.openjdk.org/jdk/pull/27446.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27446/head:pull/27446 PR: https://git.openjdk.org/jdk/pull/27446 From stuefe at openjdk.org Mon Sep 29 08:36:16 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 29 Sep 2025 08:36:16 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps [v6] In-Reply-To: References: Message-ID: <2-6W8kczVGpejKBB0VM1WerGp89Lv5ApLHF71Dnv6ec=.07c130f1-f407-4957-ae09-df1c9423016f@github.com> On Mon, 29 Sep 2025 07:05:53 GMT, Matthias Baesken wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Update address.cpp > > Looks okay to me, but we have to deal now with the many hserr files generated by the asanized-binary CI runs (fix some/all of the issues? or rewrite our test framework ?) ; for for now to asan any more in our tests. @MBaesken Thank you for the approval. You can specify `-XX:+SuppressFatalErrorMessage` to bypass hs-err file generation completely (independently from ASAN) and go directly to os::abort(). Just tested it, it works. Maybe specify that for all of your ASAN builds? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27446#issuecomment-3345661629 From stuefe at openjdk.org Mon Sep 29 08:40:10 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 29 Sep 2025 08:40:10 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps [v7] In-Reply-To: References: Message-ID: <64EKQ580ZHjDhYNM17gtgI5m2tnCQn1w2wQPD_PNvDc=.d79be6b0-aafa-4cda-9a44-8f1c5ed0e120@github.com> On Mon, 29 Sep 2025 08:36:15 GMT, Thomas Stuefe wrote: >> When we run with ASAN enabled and ASAN catches an error, it reports, then stops the JVM. hs-err files and crash dumps at that point would be incredibly useful, though. The ASAN error report itself is seldom enlightening since it only contains native stacks. >> >> After this patch, the JVM will always produce hs-err files when an ASAN-report happens. It will *only* produce core files if ASAN_OPTIONS `disable_coredump=0` and `abort_on_error=1` and the JVM option `CreateCoredumpOnCrash` had not been disabled (and the limit for core file size is high enough etc, all the usual restrictions on OS level still apply). >> >> This means that ASAN builds, by default, will continue to *not* generate cores, since ASAN default options inhibit that. See detail in the comments below. >> >> --- >> >> Tested on Fedora 42 and Debian 12, both manually and by running the new companion jtreg test. > > Thomas Stuefe has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. Sorry for the spam and the force push. Something went wrong with my final merge from master. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27446#issuecomment-3345696306 From stefank at openjdk.org Mon Sep 29 08:47:21 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 29 Sep 2025 08:47:21 GMT Subject: RFR: 8355631: The events might be generated after VM_DEATH event In-Reply-To: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com> References: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com> Message-ID: On Thu, 25 Sep 2025 21:43:46 GMT, Leonid Mesnik wrote: > The JVMTI spec says: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#VMDeath > `The VM death event notifies the agent of the termination of the VM. No events will occur after the VMDeath event.` > > However, current implementation changes state and only after this start disabling events. > > It might be not a conformance issue, because there is no way to get thread state in the very beginning of event. > The main practical issue is that currently certain events are generated when VM is becoming dead. So any function in event should check error against JVMTI_PHASE_DEAD. We can easily trigger it by running tests with enabled https://bugs.openjdk.org/browse/JDK-8352654 > > The proposed fix to disable all event generation and then post the last (VMDeath) event. After this event is completed change VM phase to death. It's guaranteed that no any events are generated after VMDeath completion. > > After this fix the VMDeath callback also can't generate any events. > The alternative is to disable events posting after VMDeath completion and before changing VM state. However, seems it is still a gap between vm death event completion and disabling events. So user can see events after VMDeath completion. > > It might be still possible also to wait while all currently executing events are completed. It is not required be specification, might add unneeded complexity. So I want to apply this fix first and then to check if we still any problems. > Then, I plan to wait with timeout until all current (and queued) jvmti events are completed with some reasonable timeout. > Currently, I haven't seen problems with this fix and https://bugs.openjdk.org/browse/JDK-8352654. Hi Leonid, We currently have a shutdown issue where the GC is shut down before the last JVMTI events are sent from the same thread. The problem is that the JVMTI code allocates Java objects, which is problematic given that we've just shut down the GC threads. Because of this extra allocation we have added a stop-gap solution that is not what we want long-term, but it fixes some reoccuring issue that was reported. The real solution involves switching the order between shutting down the GC threads and sending the last JVMTI event. Take a look at before_exit in java.cpp: // Run before exit and then stop concurrent GC threads Universe::before_exit(); ... // some unrelated code ... if (JvmtiExport::should_post_thread_life()) { JvmtiExport::post_thread_end(thread); } // Always call even when there are not JVMTI environments yet, since environments // may be attached late and JVMTI must track phases of VM execution JvmtiExport::post_vm_death(); JvmtiAgentList::unload_agents(); The GC team thinks that the thread that shuts down the GC threads should not call code that allocates, so we would like to hoist the JVMTI code to before the code that stops the GC threads ... // some unrelated code ... if (JvmtiExport::should_post_thread_life()) { JvmtiExport::post_thread_end(thread); } // Always call even when there are not JVMTI environments yet, since environments // may be attached late and JVMTI must track phases of VM execution JvmtiExport::post_vm_death(); JvmtiAgentList::unload_agents(); // Run before exit and then stop concurrent GC threads Universe::before_exit(); There's a JBS entry created for the issue described above: https://bugs.openjdk.org/browse/JDK-8367902 Given that you have looked into this VMDeath code and proposes a change to it, maybe you could help reasoning about if the above reordering would fit into what you proposes here in this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27504#issuecomment-3345735398 From mli at openjdk.org Mon Sep 29 09:00:05 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 29 Sep 2025 09:00:05 GMT Subject: RFR: 8367253: RISC-V: refactor dependent cpu extensions [v6] In-Reply-To: References: Message-ID: > Hi, > Can you help to review this patch? > > Dependent extensions could be improved in several ways. > > Currently, the dependent cpu extensions are processed in 2 separate places: > 1. update_flag() when calling VM_Version::setup_cpu_available_features() > 2. at the end of VM_Version::common_initialize(). > > And, dependency relationship can only be expressed in (1:1) way, can not be expressed (1:N) way, but in fact some extensions can depend on several different other extensions, for example, zvfh depends on zvf and rvv. It's would be better to support this (1:N) relationship. > > So, this PR brings several benefits: > 1. VM options directly related to CPU extensions are automatically set, and they are all set in one place. > 2. keep synchronization between CPU extensions (information in RVFeatureValue) and and VM options. Previously, code in common_initialize wont' sync to RVFeatureValue, unless do it manually, which is error-prone. > 3. support to express (1:N) dependency relationship among cpu extensions and related vm options. > > Thanks! > > > ## Test > > > $TEST_JDK/bin/java -XX:+UnlockExperimentalVMOptions -XX:-UseRVV -XX:+PrintFlagsFinal -version | grep -e UseRVV -e UseZvbc -e UseZvfh -e UseZvkn > OpenJDK 64-Bit Server VM warning: Cannot enable UseZvbb on cpu without any of the supports: v (disabled) > OpenJDK 64-Bit Server VM warning: Cannot enable UseZvbc on cpu without any of the supports: v (disabled) > OpenJDK 64-Bit Server VM warning: Cannot enable UseZvfh on cpu without any of the supports: v (disabled), Zfh (enabled) > bool UseRVV = false {ARCH diagnostic} {command line} > bool UseZvbc = false {ARCH experimental} {default} > bool UseZvfh = false {ARCH diagnostic} {default} > bool UseZvkn = false {ARCH experimental} {default} > > > > $TEST_JDK/bin/java -XX:+UnlockExperimentalVMOptions -XX:-UseZfh -XX:+PrintFlagsFinal -version | grep -e UseRVV -e UseZvbc -e UseZvfh -e UseZvkn > OpenJDK 64-Bit Server VM warning: Cannot enable UseZvfh on cpu without any of the supports: v (enabled), Zfh (disabled) > bool UseRVV = true {ARCH diagnostic} {default} > bool UseZvbc = true {ARCH experimental} {default} > bool UseZvfh ... Hamlin Li has updated the pull request incrementally with two additional commits since the last revision: - remove ResourceMark - verify_deps ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27171/files - new: https://git.openjdk.org/jdk/pull/27171/files/0dd9f9c3..25b6dc87 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27171&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27171&range=04-05 Stats: 17 lines in 2 files changed: 0 ins; 17 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27171/head:pull/27171 PR: https://git.openjdk.org/jdk/pull/27171 From mli at openjdk.org Mon Sep 29 09:00:09 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 29 Sep 2025 09:00:09 GMT Subject: RFR: 8367253: RISC-V: refactor dependent cpu extensions [v5] In-Reply-To: References: Message-ID: <845g5GCtOzmGoU34gGDN4i6ydb_M8HWa8so658YKdSw=.8196e561-9ed1-48ef-b49b-845d269898cf@github.com> On Mon, 29 Sep 2025 03:13:13 GMT, Fei Yang wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> minor > > src/hotspot/cpu/riscv/vm_version_riscv.cpp line 75: > >> 73: >> 74: void VM_Version::initialize() { >> 75: ResourceMark rm; > > What's this change for? Thanks for catching. I'll remove it, seems it's useless in this version of the pr. > src/hotspot/cpu/riscv/vm_version_riscv.hpp line 103: > >> 101: } >> 102: >> 103: void verify_deps(RVFeatureValue* dep0, ...) { > > Not used anywhere? Thanks for catching! I'll just remove it in this pr. It should have been added in `UPDATE_DEFAULT_DEP(flag, dep0, ...)`, to do the similar work as the assert at https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/vm_version_riscv.hpp#L92. But seems previous way (introduced in https://github.com/openjdk/jdk/pull/24094) does not work as expected to catch declarations out of dependend orders, `verify_deps` does not catch it either as it inherits the way in the pr 24094. I'll investigate it later and fix it in another pr. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27171#discussion_r2387195064 PR Review Comment: https://git.openjdk.org/jdk/pull/27171#discussion_r2387195562 From stefank at openjdk.org Mon Sep 29 09:12:53 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 29 Sep 2025 09:12:53 GMT Subject: RFR: 8367013: Add Atomic to package/replace idiom of volatile var plus AtomicAccess:: operations In-Reply-To: References: Message-ID: On Sun, 28 Sep 2025 11:10:41 GMT, Kim Barrett wrote: > Please review this change that adds the type Atomic, to use as the type > of a variable that is accessed (including writes) concurrently by multiple > threads. This is intended to replace (most) uses of the current HotSpot idiom > of declaring a variable volatile and accessing that variable using functions > from the AtomicAccess class. > https://github.com/openjdk/jdk/blame/528f93f8cb9f1fb9c19f31ab80c8a546f47beed2/doc/hotspot-style.md#L138-L147 > > This change replaces https://github.com/openjdk/jdk/pull/27462. Differences are > > * Substantially restructured `Atomic`, to be IDE friendly. It's > operationally the same, with the same API, hence uses and gtests didn't need > to change in that respect. Thanks to @stefank for raising this issue, and for > some suggestions toward improvements. > > * Changed how fetch_then_set for atomic translated types is handled, to avoid > having the function there at all if it isn't usable, rather than just removing > it via SFINAE, leaving an empty overload set. > > * Added more gtests. > > Testing: mach5 tier1-6, GHA sanity tests The following isn't a strong request, but maybe more of stated preference and an inquiry what other HotSpot devs think about the proposed names: 1) The proposed `load_relaxed` is visually very similar to `load_release`. So much that I have to double check that the code is using one or the other. The same for `relaxed_store`. 2) I'm no sure about putting the word relaxed before the word store in `relaxed_store`. I understand why it was done for `release_store`, but not really for the relaxed version. The name is also harder to discover. I think I would try to look for a function prefixed with store and not relaxed when trying to remember the name. So, I would prefer if we would have kept the load/store names. ------------- PR Review: https://git.openjdk.org/jdk/pull/27539#pullrequestreview-3278691725 From rehn at openjdk.org Mon Sep 29 09:17:02 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Mon, 29 Sep 2025 09:17:02 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v6] In-Reply-To: References: Message-ID: > Hi please, consider. > > As ziccif require instructions to natural aligned to be atomic the 4 byte post call nop must be aligned. > But I don't want to add a c.nop(2b) to align the nop(4b) which means the jal(r) must also be algined. > As we have no utility to aligned the end of an instruction sequence the call it self is aligned and uses only 4 byte instructions. Only in the case where we could use an two c-instruction we may loose space. > > Thanks, Robbin Robbin Ehn 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 'master' into align_post_nops - Use relocation spec as marker. - Revert "Removed relocate for post call nops" This reverts commit 033ecd4ab3d62c1ccc7845d8bc9e62fc6574e05d. - Removed relocate for post call nops - Merge branch 'master' into align_post_nops - Review comments - init ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27467/files - new: https://git.openjdk.org/jdk/pull/27467/files/1438c380..76c4f861 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27467&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27467&range=04-05 Stats: 8627 lines in 220 files changed: 5167 ins; 2402 del; 1058 mod Patch: https://git.openjdk.org/jdk/pull/27467.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27467/head:pull/27467 PR: https://git.openjdk.org/jdk/pull/27467 From mli at openjdk.org Mon Sep 29 09:33:33 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 29 Sep 2025 09:33:33 GMT Subject: RFR: 8368732: RISC-V: Detect support for misaligned vector access via hwprobe [v2] In-Reply-To: <9CTcYgEE2cOWk_MtCIHg_cE2EtlnwGJ6QWV7L27N93M=.d47b0ed6-3a6b-44c9-8730-670c29ab4415@github.com> References: <9CTcYgEE2cOWk_MtCIHg_cE2EtlnwGJ6QWV7L27N93M=.d47b0ed6-3a6b-44c9-8730-670c29ab4415@github.com> Message-ID: On Mon, 29 Sep 2025 02:45:59 GMT, Fei Yang wrote: >> src/hotspot/cpu/riscv/vm_version_riscv.cpp line 181: >> >>> 179: } >>> 180: >>> 181: if (FLAG_IS_DEFAULT(AlignVector) && unaligned_vector.enabled()) { >> >> Seems this `unaligned_vector.enabled` is not necessary? > > The purpose is to give a consistent view of how the these extensions should be used. That is we only use the value of the extension when it is enabled. Otherwise, we are relying on the default value -1, which doesn't seem safe to me. And it shouldn't be a issue in performance to have this check here. What do you think? `-1` normally means error/fail/unsuccess, or something similar. The reason that `-1` was chosen as default value should have the same rational here. I wonder if the linux or a C api would choose `-1` to mean pass/success. In the case of `AlignVector`, we only enable unaligned vector mem access when `value == MISALIGNED_VECTOR_FAST`, in this sense, w/wo `unaligned_vector.enabled()` produce the exact same result. In this sense, the `unaligned_vector.enabled()` is redundant. In another hand, if the default value of a vm option `A` is true and its CPU feature is not enabled (for some reason), we should still set the default value of `A` as `cpu_feature_A.value() !=/== A_enabled_Value`, rather than only set it when it's enabled. In this sense, it's safer to always set a VM option's default value based on its value in RVFeatureValue instance. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27512#discussion_r2387300894 From duke at openjdk.org Mon Sep 29 09:48:11 2025 From: duke at openjdk.org (Ruben) Date: Mon, 29 Sep 2025 09:48:11 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v5] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Fri, 26 Sep 2025 12:56:32 GMT, Martin Doerr wrote: > Should we rename `entry_point` to `entry_offset` in the deopt handlers to emphasize that it's an offset and not a pointer? Sure. I will do that. > src/hotspot/share/code/nmethod.cpp line 3: > >> 1: /* >> 2: * Copyright (c) 1997, 2025, Oracle and/or its affiliates. All rights reserved. >> 3: * Copyright 2025 Arm Limited and/or its affiliates. > > Still questionable, here. Do we have clear guidelines? Thanks for the feedback. I followed the current guideline at https://openjdk.org/guide/#copyright-headers which advises: > If your affiliation doesn?t have a copyright notice, again consult your legal representative to see if you should add one. If the guideline isn't applicable or if there is a more detailed guidance on when Copyright header should or should not be added, I'd appreciate further advice. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3346006871 PR Review Comment: https://git.openjdk.org/jdk/pull/26678#discussion_r2387339188 From mli at openjdk.org Mon Sep 29 10:05:46 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 29 Sep 2025 10:05:46 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v5] In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 16:13:11 GMT, Robbin Ehn wrote: > Runtime calls don't have an interrupt point and used for calling stub and such. For "interrupt point" above, do you mean safepoint? > E.g. C2_MacroAssembler::string_compare calls StubRoutines::riscv::compare_long_string_LL. There is not post_call_nops as we can't deoptimize the caller while running this stub. So it's still true that they don't need to be aligned. I see, thanks! >> src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp line 1353: >> >>> 1351: >>> 1352: void LIR_Assembler::call(LIR_OpJavaCall* op, relocInfo::relocType rtype) { >>> 1353: Assembler::IncompressibleScope scope(_masm); >> >> Is an alignment needed here? > > It's aligned: > > void LIR_Assembler::emit_call(LIR_OpJavaCall* op) { > verify_oop_map(op->info()); > > // must align calls sites, otherwise they can't be updated atomically > align_call(op->code()); I see, thanks! >> src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp line 1364: >> >>> 1362: >>> 1363: void LIR_Assembler::ic_call(LIR_OpJavaCall* op) { >>> 1364: Assembler::IncompressibleScope scope(_masm); >> >> Is an alignment needed here? > > It's aligned: > > void LIR_Assembler::emit_call(LIR_OpJavaCall* op) { > verify_oop_map(op->info()); > > // must align calls sites, otherwise they can't be updated atomically > align_call(op->code()); I see, thanks! >> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 358: >> >>> 356: >>> 357: void MacroAssembler::post_call_nop() { >>> 358: assert(!in_compressible_scope(), "Must be"); >> >> Maybe `do_compress` is better? All other places use `do_compress`. >> Similar suggestion as below. > > There is a semantic difference: in_compressible_scope() only check if caller turned off c-instruction. > While do_compressed() also consider what ISA we are using in runtime. > Regardless of ISA : caller of post_call_nop() should have turned C off is what I want to assert. Although I prefer do_compress, in_compressible_scope is also fine to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27467#issuecomment-3346071581 PR Review Comment: https://git.openjdk.org/jdk/pull/27467#discussion_r2387385726 PR Review Comment: https://git.openjdk.org/jdk/pull/27467#discussion_r2387385900 PR Review Comment: https://git.openjdk.org/jdk/pull/27467#discussion_r2387388024 From mli at openjdk.org Mon Sep 29 10:12:14 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 29 Sep 2025 10:12:14 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v6] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 09:17:02 GMT, Robbin Ehn wrote: >> Hi please, consider. >> >> As ziccif require instructions to natural aligned to be atomic the 4 byte post call nop must be aligned. >> But I don't want to add a c.nop(2b) to align the nop(4b) which means the jal(r) must also be algined. >> As we have no utility to aligned the end of an instruction sequence the call it self is aligned and uses only 4 byte instructions. Only in the case where we could use an two c-instruction we may loose space. >> >> Thanks, Robbin > > Robbin Ehn 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 'master' into align_post_nops > - Use relocation spec as marker. > - Revert "Removed relocate for post call nops" > > This reverts commit 033ecd4ab3d62c1ccc7845d8bc9e62fc6574e05d. > - Removed relocate for post call nops > - Merge branch 'master' into align_post_nops > - Review comments > - init src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 363: > 361: return; > 362: } > 363: relocate(post_call_nop_Relocation::spec()); What's the reason for this change? Does it make difference from the previous code? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27467#discussion_r2387410055 From fyang at openjdk.org Mon Sep 29 10:12:50 2025 From: fyang at openjdk.org (Fei Yang) Date: Mon, 29 Sep 2025 10:12:50 GMT Subject: RFR: 8368732: RISC-V: Detect support for misaligned vector access via hwprobe [v5] In-Reply-To: References: Message-ID: <7CinJwmzealqgTITMY8Lqrew3NIL3eOF7AunJiSfphY=.a9ea0b79-2474-4934-b70f-6ed87f46ff6e@github.com> > Hi, this is a followup change after [JDK-8368366](https://bugs.openjdk.org/browse/JDK-8368366). > > According to the latest RISC-V linux hardware probing syscall [1], the performance of misaligned memory accesses has been divided into two cases: `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` and `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` for scalar and vector respectively. > > This aligns `AlignVector` with `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF`. That is if the misaligned vector access is fast, we set `AlignVector` to false in the hope that it will save instructions handling address alignment thus improves performance. > > This choose to keep the use of `RISCV_HWPROBE_KEY_CPUPERF_0` which is now deprecated and returns similar values > to `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` for backward compatibility with old linux kernels. > > Manually checked the result on platforms w/wo fast misaligned vector accesses by running: > `$java -XX:+PrintFlagsFinal -version | grep AlignVector` > > [1] https://docs.kernel.org/arch/riscv/hwprobe.html Fei Yang has updated the pull request incrementally with one additional commit since the last revision: Review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27512/files - new: https://git.openjdk.org/jdk/pull/27512/files/a80ee075..90f6eb79 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27512&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27512&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27512.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27512/head:pull/27512 PR: https://git.openjdk.org/jdk/pull/27512 From fyang at openjdk.org Mon Sep 29 10:16:17 2025 From: fyang at openjdk.org (Fei Yang) Date: Mon, 29 Sep 2025 10:16:17 GMT Subject: RFR: 8368732: RISC-V: Detect support for misaligned vector access via hwprobe [v2] In-Reply-To: References: <9CTcYgEE2cOWk_MtCIHg_cE2EtlnwGJ6QWV7L27N93M=.d47b0ed6-3a6b-44c9-8730-670c29ab4415@github.com> Message-ID: <2UrHgs-oeX_Y_y2jm6uVSDOwOqUu1O3Cpp1tK8Vg2P4=.522de48d-acc2-4c8d-9dc3-4482eb451d12@github.com> On Mon, 29 Sep 2025 09:30:20 GMT, Hamlin Li wrote: >> The purpose is to give a consistent view of how the these extensions should be used. That is we only use the value of the extension when it is enabled. Otherwise, we are relying on the default value -1, which doesn't seem safe to me. And it shouldn't be a issue in performance to have this check here. What do you think? > > `-1` normally means error/fail/unsuccess, or something similar. The reason that `-1` was chosen as default value should have the same rational here. I wonder if the linux or a C api would choose `-1` to mean pass/success. > In the case of `AlignVector`, we only enable unaligned vector mem access when `value == MISALIGNED_VECTOR_FAST`, in this sense, w/wo `unaligned_vector.enabled()` produce the exact same result. > In this sense, the `unaligned_vector.enabled()` is redundant. > > In another hand, if the default value of a vm option `A` is true and its CPU feature is not enabled (for some reason), we should still set the default value of `A` as `cpu_feature_A.value() !=/== A_enabled_Value`, rather than only set it when it's enabled. > In this sense, it's safer to always set a VM option's default value based on its value in RVFeatureValue instance. OK if you prefer that way. I think that should only work for these non-extension hwprobe items. So you might also want to remove the enabled check for other friends like `zicboz_block_size` and `mvendorid` for consistency. But that should go as a separate PR. I just updated this PR removing this check. Please take another look. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27512#discussion_r2387421424 From myankelevich at openjdk.org Mon Sep 29 10:28:19 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Mon, 29 Sep 2025 10:28:19 GMT Subject: RFR: 8365072: Refactor tests to use PEM API (Phase 2) [v3] In-Reply-To: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com> References: <_Qf2f6cwWoaNPHpm8TfYeWQTiiqhn-z291PeGY7uP6U=.8e77e560-d233-4232-86e8-4e0da5180947@github.com> Message-ID: > Tests changed in this PR: > 1. test/jdk/java/security/cert/CertPathBuilder/selfIssued/StatusLoopDependency.java > 2. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevel.java > 3. test/jdk/java/security/cert/CertPathValidator/indirectCRL/CircularCRLTwoLevelRevoked.java > 6. test/jdk/sun/security/ssl/ClientHandshaker/RSAExport.java > 7. test/jdk/javax/net/ssl/ServerName/SSLSocketSNISensitive.java > 9. test/jdk/sun/security/ssl/X509TrustManagerImpl/BasicConstraints.java > 10. test/jdk/sun/security/ssl/X509TrustManagerImpl/ComodoHacker.java > 11. test/jdk/javax/net/ssl/interop/ClientHelloInterOp.java > 12. test/jdk/sun/security/rsa/InvalidBitString.java > 14. test/jdk/java/security/cert/CertPathBuilder/NoExtensions.java > 17. test/jdk/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java > 19. test/jdk/sun/security/x509/X509CRLImpl/Verify.java > > PEMRecord tests will be done under a subtask [JDK-8367326](https://bugs.openjdk.org/browse/JDK-8367326) Mikhail Yankelevich has updated the pull request incrementally with 364 additional commits since the last revision: - removed pemrecord usage - 8365190: Remove LockingMode related code from share Reviewed-by: aboldtch, dholmes, ayang, coleenp, lmesnik, rcastanedalo - 8367025: zIndexDistributor.hpp uses angle-bracket inclusion of globalDefinitions.hpp Reviewed-by: aboldtch, tschatzl, jwaters - 8360219: [AIX] assert(locals_base >= l2) failed: bad placement Reviewed-by: dlong, mdoerr - 8366864: Sort os/linux includes Reviewed-by: ayang, dholmes - 8366874: Test gc/arguments/TestParallelGCErgo.java fails with UseTransparentHugePages Reviewed-by: ayang, shade, stefank, tschatzl - 8351260: java.lang.AssertionError: Unexpected type tree: (ERROR) = (ERROR) Reviewed-by: vromero - 8365776: Convert JShell tests to use JUnit instead of TestNG Reviewed-by: vromero - 8354871: Replace stack map frame type magics with constants Reviewed-by: liach - 8361533: Apply java.io.Serial annotations in java.logging Reviewed-by: rriggs - ... and 354 more: https://git.openjdk.org/jdk/compare/d44cb277...e0be5eaa ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27194/files - new: https://git.openjdk.org/jdk/pull/27194/files/d44cb277..e0be5eaa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27194&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27194&range=01-02 Stats: 53711 lines in 1891 files changed: 31453 ins; 14034 del; 8224 mod Patch: https://git.openjdk.org/jdk/pull/27194.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27194/head:pull/27194 PR: https://git.openjdk.org/jdk/pull/27194 From ssarathi at openjdk.org Mon Sep 29 10:29:30 2025 From: ssarathi at openjdk.org (Sorna Sarathi N) Date: Mon, 29 Sep 2025 10:29:30 GMT Subject: RFR: 8334247: [PPC64] Consider trap based nmethod entry barriers [v5] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 13:33:20 GMT, Martin Doerr wrote: >> We can shrink nmethod entry barriers to 4 instructions (from 8) using conditional trap instructions. Some benchmarks seem to show very small improvements. At least the code size reduction is an advantage. > > Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier > - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier > - Move nmethod entry barrier code up in the signal handler. > - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier > - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier > - 8334247: [PPC64] Consider trap based nmethod entry barriers I carefully reviewed the proposed changes. The patch looks good to me. The code seems to be clean and well contained. I don?t see any correctness issues. On the performance side, the benchmark results consistently demonstrate a substantial improvement in performance compared to the baseline. Importantly, I did not see any regressions in functionality. Overall, the code is clean and shows clear performance gains. LGTM. ------------- Marked as reviewed by ssarathi (Author). PR Review: https://git.openjdk.org/jdk/pull/24135#pullrequestreview-3279016448 From mli at openjdk.org Mon Sep 29 10:36:18 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 29 Sep 2025 10:36:18 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v5] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 10:01:56 GMT, Hamlin Li wrote: > > Runtime calls don't have an interrupt point and used for calling stub and such. > > For "interrupt point" above, do you mean safepoint? I see what you meant. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27467#issuecomment-3346213321 From mdoerr at openjdk.org Mon Sep 29 10:39:33 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 29 Sep 2025 10:39:33 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v5] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Mon, 29 Sep 2025 09:45:40 GMT, Ruben wrote: >> src/hotspot/share/code/nmethod.cpp line 3: >> >>> 1: /* >>> 2: * Copyright (c) 1997, 2025, Oracle and/or its affiliates. All rights reserved. >>> 3: * Copyright 2025 Arm Limited and/or its affiliates. >> >> Still questionable, here. Do we have clear guidelines? > > Thanks for the feedback. I followed the current guideline at https://openjdk.org/guide/#copyright-headers which advises: > >> If your affiliation doesn?t have a copyright notice, again consult your legal representative to see if you should add one. > > If the guideline isn't applicable or if there is a more detailed guidance on when Copyright header should or should not be added, I'd appreciate further advice. Here are some arguments why I wouldn't do it: - We usually don't add Copyright headers to existing files. Only to new ones we created. Many contributors are doing the same AFAIK. (Maybe only for very significant contributions to a file.) - The Linux Foundation has listed reasons "Why not list every copyright holder?" https://www.linuxfoundation.org/blog/blog/copyright-notices-in-open-source-software-projects - OpenJDK headers say "DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26678#discussion_r2387477511 From rrich at openjdk.org Mon Sep 29 10:51:04 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Mon, 29 Sep 2025 10:51:04 GMT Subject: RFR: 8334247: [PPC64] Consider trap based nmethod entry barriers [v5] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 10:26:42 GMT, Sorna Sarathi N wrote: > On the performance side, the benchmark results consistently demonstrate a substantial improvement in performance compared to the baseline. Importantly, I did not see any regressions in functionality. Hi @Sorna-Sarathi, would you mind sharing the benchmark results you are referring to? Thanks, Richard. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24135#issuecomment-3346279528 From ssarathi at openjdk.org Mon Sep 29 11:12:08 2025 From: ssarathi at openjdk.org (Sorna Sarathi N) Date: Mon, 29 Sep 2025 11:12:08 GMT Subject: RFR: 8334247: [PPC64] Consider trap based nmethod entry barriers [v5] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 10:48:41 GMT, Richard Reingruber wrote: > > On the performance side, the benchmark results consistently demonstrate a substantial improvement in performance compared to the baseline. Importantly, I did not see any regressions in functionality. > > Hi @Sorna-Sarathi, would you mind sharing the benchmark results you are referring to? Thanks, Richard. Hi, @reinrich I checked with Dacapo benchmark in aix-ppc64. There is a significant decrease in benchmark runtime(sec) after the patch gc_runtime_heatmap-final Thanks, Sorna Sarathi N. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24135#issuecomment-3346355070 From fyang at openjdk.org Mon Sep 29 11:15:16 2025 From: fyang at openjdk.org (Fei Yang) Date: Mon, 29 Sep 2025 11:15:16 GMT Subject: RFR: 8367253: RISC-V: refactor dependent cpu extensions [v6] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 09:00:05 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> >> Dependent extensions could be improved in several ways. >> >> Currently, the dependent cpu extensions are processed in 2 separate places: >> 1. update_flag() when calling VM_Version::setup_cpu_available_features() >> 2. at the end of VM_Version::common_initialize(). >> >> And, dependency relationship can only be expressed in (1:1) way, can not be expressed (1:N) way, but in fact some extensions can depend on several different other extensions, for example, zvfh depends on zvf and rvv. It's would be better to support this (1:N) relationship. >> >> So, this PR brings several benefits: >> 1. VM options directly related to CPU extensions are automatically set, and they are all set in one place. >> 2. keep synchronization between CPU extensions (information in RVFeatureValue) and and VM options. Previously, code in common_initialize wont' sync to RVFeatureValue, unless do it manually, which is error-prone. >> 3. support to express (1:N) dependency relationship among cpu extensions and related vm options. >> >> Thanks! >> >> >> ## Test >> >> >> $TEST_JDK/bin/java -XX:+UnlockExperimentalVMOptions -XX:-UseRVV -XX:+PrintFlagsFinal -version | grep -e UseRVV -e UseZvbc -e UseZvfh -e UseZvkn >> OpenJDK 64-Bit Server VM warning: Cannot enable UseZvbb on cpu without any of the supports: v (disabled) >> OpenJDK 64-Bit Server VM warning: Cannot enable UseZvbc on cpu without any of the supports: v (disabled) >> OpenJDK 64-Bit Server VM warning: Cannot enable UseZvfh on cpu without any of the supports: v (disabled), Zfh (enabled) >> bool UseRVV = false {ARCH diagnostic} {command line} >> bool UseZvbc = false {ARCH experimental} {default} >> bool UseZvfh = false {ARCH diagnostic} {default} >> bool UseZvkn = false {ARCH experimental} {default} >> >> >> >> $TEST_JDK/bin/java -XX:+UnlockExperimentalVMOptions -XX:-UseZfh -XX:+PrintFlagsFinal -version | grep -e UseRVV -e UseZvbc -e UseZvfh -e UseZvkn >> OpenJDK 64-Bit Server VM warning: Cannot enable UseZvfh on cpu without any of the supports: v (enabled), Zfh (disabled) >> bool UseRVV = true {ARCH diagnostic} {default} >> bool UseZvbc = true ... > > Hamlin Li has updated the pull request incrementally with two additional commits since the last revision: > > - remove ResourceMark > - verify_deps Latest version LGTM. ------------- Marked as reviewed by fyang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27171#pullrequestreview-3279166352 From duke at openjdk.org Mon Sep 29 11:16:35 2025 From: duke at openjdk.org (Ruben) Date: Mon, 29 Sep 2025 11:16:35 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v6] In-Reply-To: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: > The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob. > > According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only. Ruben has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26678/files - new: https://git.openjdk.org/jdk/pull/26678/files/5107d025..18e36eca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26678&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26678&range=04-05 Stats: 24 lines in 12 files changed: 0 ins; 0 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/26678.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26678/head:pull/26678 PR: https://git.openjdk.org/jdk/pull/26678 From bulasevich at openjdk.org Mon Sep 29 11:16:36 2025 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Mon, 29 Sep 2025 11:16:36 GMT Subject: RFR: 8365047: Remove exception handler stub code in C2 [v5] In-Reply-To: References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com> Message-ID: On Mon, 29 Sep 2025 10:36:22 GMT, Martin Doerr wrote: >> Thanks for the feedback. I followed the current guideline at https://openjdk.org/guide/#copyright-headers which advises: >> >>> If your affiliation doesn?t have a copyright notice, again consult your legal representative to see if you should add one. >> >> If the guideline isn't applicable or if there is a more detailed guidance on when Copyright header should or should not be added, I'd appreciate further advice. > > Here are some arguments why I wouldn't do it: > - We usually don't add Copyright headers to existing files. Only to new ones we created. Many contributors are doing the same AFAIK. (Maybe only for very significant contributions to a file.) > - The Linux Foundation has listed reasons "Why not list every copyright holder?" https://www.linuxfoundation.org/blog/blog/copyright-notices-in-open-source-software-projects > - OpenJDK headers say "DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER." Many companies have contributed to this file over time. If we all added our copyright lines, the header would become unreadable. The usual OpenJDK practice is to only update header for new files or very substantial rewrites. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26678#discussion_r2387563956 From rrich at openjdk.org Mon Sep 29 11:28:55 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Mon, 29 Sep 2025 11:28:55 GMT Subject: RFR: 8334247: [PPC64] Consider trap based nmethod entry barriers [v5] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 13:33:20 GMT, Martin Doerr wrote: >> We can shrink nmethod entry barriers to 4 instructions (from 8) using conditional trap instructions. Some benchmarks seem to show very small improvements. At least the code size reduction is an advantage. > > Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier > - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier > - Move nmethod entry barrier code up in the signal handler. > - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier > - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier > - 8334247: [PPC64] Consider trap based nmethod entry barriers Thanks for sharing the results. > Hi, @reinrich I checked with Dacapo benchmark in aix-ppc64. There is a significant decrease in benchmark runtime(sec) after the patch. So the numbers are benchmark runtime(sec), correct? Looking at the fist 2 columns I read that with G1 the runtime of the *tomcat* benchmark is reduced from 85s to 1.4s by the change. This doesn't sound plausible to me. Am I misinterpreting the results? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24135#issuecomment-3346424001 From ssarathi at openjdk.org Mon Sep 29 11:45:08 2025 From: ssarathi at openjdk.org (Sorna Sarathi N) Date: Mon, 29 Sep 2025 11:45:08 GMT Subject: RFR: 8334247: [PPC64] Consider trap based nmethod entry barriers [v5] In-Reply-To: References: Message-ID: On Wed, 10 Sep 2025 13:33:20 GMT, Martin Doerr wrote: >> We can shrink nmethod entry barriers to 4 instructions (from 8) using conditional trap instructions. Some benchmarks seem to show very small improvements. At least the code size reduction is an advantage. > > Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier > - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier > - Move nmethod entry barrier code up in the signal handler. > - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier > - Merge remote-tracking branch 'origin' into 8334247_PPC64_trap_based_nmethod_entry_barrier > - 8334247: [PPC64] Consider trap based nmethod entry barriers > Thanks for sharing the results. > > > Hi, @reinrich I checked with Dacapo benchmark in aix-ppc64. There is a significant decrease in benchmark runtime(sec) after the patch. > > So the numbers are benchmark runtime(sec), correct? Looking at the fist 2 columns I read that with G1 the runtime of the _tomcat_ benchmark is reduced from 85s to 1.4s by the change. This doesn't sound plausible to me. Am I misinterpreting the results? Yeah, that an error. Found the problem, it's due to incompatible java version while running. Will get back with corrected one. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24135#issuecomment-3346490530 From kbarrett at openjdk.org Mon Sep 29 11:48:55 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 29 Sep 2025 11:48:55 GMT Subject: RFR: 8367013: Add Atomic to package/replace idiom of volatile var plus AtomicAccess:: operations In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 09:09:50 GMT, Stefan Karlsson wrote: > The following isn't a strong request, but maybe more of stated preference and an inquiry what other HotSpot devs think about the proposed names: > > 1. The proposed `load_relaxed` is visually very similar to `load_release`. So much that I have to double check that the code is using one or the other. The same for `relaxed_store`. I assume you mean `load_acquire` - there is no `load_release`. `load_relaxed` and `load_acquire` don't look very much alike to me. OTOH, I find `load` (without any qualifying suffix) tends to hide when in the midst of other code. I also prefer the operations be explicit about the ordering. Personally, I've never liked `Atomic::load` and `Atomic::store` either. > 2. I'm no sure about putting the word relaxed before the word store in `relaxed_store`. I understand why it was done for `release_store`, but not really for the relaxed version. The name is also harder to discover. I think I would try to look for a function prefixed with store and not relaxed when trying to remember the name. If the relaxed storing operation is going to be explicit, putting the qualifier at the front to be consistent seems better to me. > So, I would prefer if we would have kept the load/store names. And I would prefer the ordering (or lack thereof) be explicit, so don't want to keep the load/store names. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3346503040 From kevinw at openjdk.org Mon Sep 29 12:08:14 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 29 Sep 2025 12:08:14 GMT Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time In-Reply-To: References: Message-ID: On Sat, 27 Sep 2025 11:18:58 GMT, Jonas Norlinder wrote: > Hi all, > > This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding. > > `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem. > > FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM. > > Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug. src/hotspot/share/include/jmm.h line 85: > 83: JMM_GC_COUNT = 10, /* Total number of collections */ > 84: JMM_GC_CPU_TIME = 11, /* Total accumulated GC CPU time */ > 85: JMM_JVM_UPTIME_MS = 12, /* The JVM uptime in milliseconds */ It looks a bit odd to me to change the existing define of UPTIME here. OK it is not a public interface used between different versions, and people should not be mixing up jmm.h and management implementations... But usually we would just add the new definition? (items below are not strictly grouped by name) Maybe this is just a nit, and only makes cross-version comparisons easier. Looks good overall. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2387698942 From kbarrett at openjdk.org Mon Sep 29 12:09:10 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 29 Sep 2025 12:09:10 GMT Subject: RFR: 8367013: Add Atomic to package/replace idiom of volatile var plus AtomicAccess:: operations In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 11:45:51 GMT, Kim Barrett wrote: > Personally, I've never liked `Atomic::load` and `Atomic::store` either. I've always thought it's weird that for most AtomicAccess operations, the short form (defaulted memory order) provides the strongest ordering, but the short form of load/store is the weakest form. If we were to be more like std::atomic we'd have load(memory_order_relaxed) load(memory_order_acquire) store(memory_order_relaxed) store(memory_order_release) (And std::atomic doesn't have release_store_fence?) And there I'd agree the visual cues for the distinctions are not great. But we're not doing that, and I don't think we should. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3346575233 From rehn at openjdk.org Mon Sep 29 12:41:03 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Mon, 29 Sep 2025 12:41:03 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v6] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 10:09:39 GMT, Hamlin Li wrote: >> Robbin Ehn 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 'master' into align_post_nops >> - Use relocation spec as marker. >> - Revert "Removed relocate for post call nops" >> >> This reverts commit 033ecd4ab3d62c1ccc7845d8bc9e62fc6574e05d. >> - Removed relocate for post call nops >> - Merge branch 'master' into align_post_nops >> - Review comments >> - init > > src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 363: > >> 361: return; >> 362: } >> 363: relocate(post_call_nop_Relocation::spec()); > > What's the reason for this change? Does it make difference from the previous code? The code is location inpedent, meaning it will be the exact same encoding regardless of what addresses it's placed on. But we need a reloc spec to keep track of where we did place them. So we don't need to regenerate the instructions after move. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27467#discussion_r2387789861 From mli at openjdk.org Mon Sep 29 13:11:46 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 29 Sep 2025 13:11:46 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v6] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 12:38:10 GMT, Robbin Ehn wrote: >> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 363: >> >>> 361: return; >>> 362: } >>> 363: relocate(post_call_nop_Relocation::spec()); >> >> What's the reason for this change? Does it make difference from the previous code? > > The code is location independent, meaning it will be the exact same encoding regardless of what addresses it's placed on. But we need a reloc spec to keep track of where we did place them. > So we don't need to regenerate the instructions after move. Just checked the code, seems either `relocate` w/wo `Callback` will be treated in the same way when relocation happens. For the version with `Callback` argument, the code will be in an `IncompressibleScope`. But this pr you put an `assert(!in_compressible_scope()` at the beginning, so seems it's also fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27467#discussion_r2387899135 From mli at openjdk.org Mon Sep 29 13:15:10 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 29 Sep 2025 13:15:10 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v6] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 09:17:02 GMT, Robbin Ehn wrote: >> Hi please, consider. >> >> As ziccif require instructions to natural aligned to be atomic the 4 byte post call nop must be aligned. >> But I don't want to add a c.nop(2b) to align the nop(4b) which means the jal(r) must also be algined. >> As we have no utility to aligned the end of an instruction sequence the call it self is aligned and uses only 4 byte instructions. Only in the case where we could use an two c-instruction we may loose space. >> >> Thanks, Robbin > > Robbin Ehn 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 'master' into align_post_nops > - Use relocation spec as marker. > - Revert "Removed relocate for post call nops" > > This reverts commit 033ecd4ab3d62c1ccc7845d8bc9e62fc6574e05d. > - Removed relocate for post call nops > - Merge branch 'master' into align_post_nops > - Review comments > - init Thanks for discussion. Nice fix, look good! ------------- Marked as reviewed by mli (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27467#pullrequestreview-3279741084 From mli at openjdk.org Mon Sep 29 13:33:34 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 29 Sep 2025 13:33:34 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v6] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 09:17:02 GMT, Robbin Ehn wrote: >> Hi please, consider. >> >> As ziccif require instructions to natural aligned to be atomic the 4 byte post call nop must be aligned. >> But I don't want to add a c.nop(2b) to align the nop(4b) which means the jal(r) must also be algined. >> As we have no utility to aligned the end of an instruction sequence the call it self is aligned and uses only 4 byte instructions. Only in the case where we could use an two c-instruction we may loose space. >> >> Thanks, Robbin > > Robbin Ehn 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 'master' into align_post_nops > - Use relocation spec as marker. > - Revert "Removed relocate for post call nops" > > This reverts commit 033ecd4ab3d62c1ccc7845d8bc9e62fc6574e05d. > - Removed relocate for post call nops > - Merge branch 'master' into align_post_nops > - Review comments > - init I got another question, it' not a comment on this pr. In `nmethod::make_deoptimized`, it will only `make_deopt` virtual_call_type/static_call_type/opt_virtual_call_type. But in riscv.ad, `post_call_nop`s are appended to calls which are not virtual_call_type/static_call_type/opt_virtual_call_type, are all these `post_call_nop`s necessary? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27467#issuecomment-3346971831 From mli at openjdk.org Mon Sep 29 13:34:47 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 29 Sep 2025 13:34:47 GMT Subject: RFR: 8367253: RISC-V: refactor dependent cpu extensions [v6] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 11:12:34 GMT, Fei Yang wrote: > Latest version LGTM. Thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27171#issuecomment-3346974841 From mli at openjdk.org Mon Sep 29 13:39:13 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 29 Sep 2025 13:39:13 GMT Subject: RFR: 8368732: RISC-V: Detect support for misaligned vector access via hwprobe [v5] In-Reply-To: <7CinJwmzealqgTITMY8Lqrew3NIL3eOF7AunJiSfphY=.a9ea0b79-2474-4934-b70f-6ed87f46ff6e@github.com> References: <7CinJwmzealqgTITMY8Lqrew3NIL3eOF7AunJiSfphY=.a9ea0b79-2474-4934-b70f-6ed87f46ff6e@github.com> Message-ID: On Mon, 29 Sep 2025 10:12:50 GMT, Fei Yang wrote: >> Hi, this is a followup change after [JDK-8368366](https://bugs.openjdk.org/browse/JDK-8368366). >> >> According to the latest RISC-V linux hardware probing syscall [1], the performance of misaligned memory accesses has been divided into two cases: `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` and `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` for scalar and vector respectively. >> >> This aligns `AlignVector` with `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF`. That is if the misaligned vector access is fast, we set `AlignVector` to false in the hope that it will save instructions handling address alignment thus improves performance. >> >> This choose to keep the use of `RISCV_HWPROBE_KEY_CPUPERF_0` which is now deprecated and returns similar values >> to `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` for backward compatibility with old linux kernels. >> >> Manually checked the result on platforms w/wo fast misaligned vector accesses by running: >> `$java -XX:+PrintFlagsFinal -version | grep AlignVector` >> >> [1] https://docs.kernel.org/arch/riscv/hwprobe.html > > Fei Yang has updated the pull request incrementally with one additional commit since the last revision: > > Review src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp line 270: > 268: } > 269: #endif > 270: // RISCV_HWPROBE_KEY_CPUPERF_0 is deprecated. Keep it there for backward Shoud `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` also be checked and enable `unaligned_scalar` here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27512#discussion_r2388012375 From mli at openjdk.org Mon Sep 29 13:42:18 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 29 Sep 2025 13:42:18 GMT Subject: RFR: 8368732: RISC-V: Detect support for misaligned vector access via hwprobe [v2] In-Reply-To: <2UrHgs-oeX_Y_y2jm6uVSDOwOqUu1O3Cpp1tK8Vg2P4=.522de48d-acc2-4c8d-9dc3-4482eb451d12@github.com> References: <9CTcYgEE2cOWk_MtCIHg_cE2EtlnwGJ6QWV7L27N93M=.d47b0ed6-3a6b-44c9-8730-670c29ab4415@github.com> <2UrHgs-oeX_Y_y2jm6uVSDOwOqUu1O3Cpp1tK8Vg2P4=.522de48d-acc2-4c8d-9dc3-4482eb451d12@github.com> Message-ID: On Mon, 29 Sep 2025 10:13:15 GMT, Fei Yang wrote: > So you might also want to remove the enabled() check for other friends like zicboz_block_size and mvendorid for consistency. But that should go as a separate PR. Sure, it's OK. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27512#discussion_r2388026379 From asmehra at openjdk.org Mon Sep 29 14:05:36 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Mon, 29 Sep 2025 14:05:36 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps [v6] In-Reply-To: References: Message-ID: <2vVqlVCRKO-vefgMtqqLzWGjnmxh1EAqHzN91QIl1h8=.1d8323b3-c467-4079-a813-f5ae224ea4e2@github.com> On Mon, 29 Sep 2025 06:11:36 GMT, Thomas Stuefe wrote: >> When we run with ASAN enabled and ASAN catches an error, it reports, then stops the JVM. hs-err files and crash dumps at that point would be incredibly useful, though. The ASAN error report itself is seldom enlightening since it only contains native stacks. >> >> After this patch, the JVM will always produce hs-err files when an ASAN-report happens. It will *only* produce core files if ASAN_OPTIONS `disable_coredump=0` and `abort_on_error=1` and the JVM option `CreateCoredumpOnCrash` had not been disabled (and the limit for core file size is high enough etc, all the usual restrictions on OS level still apply). >> >> This means that ASAN builds, by default, will continue to *not* generate cores, since ASAN default options inhibit that. See detail in the comments below. >> >> --- >> >> Tested on Fedora 42 and Debian 12, both manually and by running the new companion jtreg test. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Update address.cpp Marked as reviewed by asmehra (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27446#pullrequestreview-3280031603 From fyang at openjdk.org Mon Sep 29 14:11:15 2025 From: fyang at openjdk.org (Fei Yang) Date: Mon, 29 Sep 2025 14:11:15 GMT Subject: RFR: 8368732: RISC-V: Detect support for misaligned vector access via hwprobe [v6] In-Reply-To: References: Message-ID: > Hi, this is a followup change after [JDK-8368366](https://bugs.openjdk.org/browse/JDK-8368366). > > According to the latest RISC-V linux hardware probing syscall [1], the performance of misaligned memory accesses has been divided into two cases: `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` and `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` for scalar and vector respectively. > > This aligns `AlignVector` with `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF`. That is if the misaligned vector access is fast, we set `AlignVector` to false in the hope that it will save instructions handling address alignment thus improves performance. > > This choose to keep the use of `RISCV_HWPROBE_KEY_CPUPERF_0` which is now deprecated and returns similar values > to `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` for backward compatibility with old linux kernels. > > Manually checked the result on platforms w/wo fast misaligned vector accesses by running: > `$java -XX:+PrintFlagsFinal -version | grep AlignVector` > > [1] https://docs.kernel.org/arch/riscv/hwprobe.html Fei Yang has updated the pull request incrementally with one additional commit since the last revision: Review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27512/files - new: https://git.openjdk.org/jdk/pull/27512/files/90f6eb79..aabf1ea9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27512&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27512&range=04-05 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27512.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27512/head:pull/27512 PR: https://git.openjdk.org/jdk/pull/27512 From fyang at openjdk.org Mon Sep 29 14:11:18 2025 From: fyang at openjdk.org (Fei Yang) Date: Mon, 29 Sep 2025 14:11:18 GMT Subject: RFR: 8368732: RISC-V: Detect support for misaligned vector access via hwprobe [v5] In-Reply-To: References: <7CinJwmzealqgTITMY8Lqrew3NIL3eOF7AunJiSfphY=.a9ea0b79-2474-4934-b70f-6ed87f46ff6e@github.com> Message-ID: On Mon, 29 Sep 2025 13:36:50 GMT, Hamlin Li wrote: >> Fei Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> Review > > src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp line 270: > >> 268: } >> 269: #endif >> 270: // RISCV_HWPROBE_KEY_CPUPERF_0 is deprecated. Keep it there for backward > > Shoud `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` also be checked and enable `unaligned_scalar` here? Yeah. I think we should. Fixed. Let me know. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27512#discussion_r2388132030 From mli at openjdk.org Mon Sep 29 14:15:20 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 29 Sep 2025 14:15:20 GMT Subject: RFR: 8368732: RISC-V: Detect support for misaligned vector access via hwprobe [v6] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 14:11:15 GMT, Fei Yang wrote: >> Hi, this is a followup change after [JDK-8368366](https://bugs.openjdk.org/browse/JDK-8368366). >> >> According to the latest RISC-V linux hardware probing syscall [1], the performance of misaligned memory accesses has been divided into two cases: `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` and `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` for scalar and vector respectively. >> >> This aligns `AlignVector` with `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF`. That is if the misaligned vector access is fast, we set `AlignVector` to false in the hope that it will save instructions handling address alignment thus improves performance. >> >> This choose to keep the use of `RISCV_HWPROBE_KEY_CPUPERF_0` which is now deprecated and returns similar values >> to `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` for backward compatibility with old linux kernels. >> >> Manually checked the result on platforms w/wo fast misaligned vector accesses by running: >> `$java -XX:+PrintFlagsFinal -version | grep AlignVector` >> >> [1] https://docs.kernel.org/arch/riscv/hwprobe.html > > Fei Yang has updated the pull request incrementally with one additional commit since the last revision: > > Review Looks good. Thanks! ------------- Marked as reviewed by mli (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27512#pullrequestreview-3280088337 From mli at openjdk.org Mon Sep 29 16:08:18 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 29 Sep 2025 16:08:18 GMT Subject: Integrated: 8367253: RISC-V: refactor dependent cpu extensions In-Reply-To: References: Message-ID: On Tue, 9 Sep 2025 12:52:18 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > > Dependent extensions could be improved in several ways. > > Currently, the dependent cpu extensions are processed in 2 separate places: > 1. update_flag() when calling VM_Version::setup_cpu_available_features() > 2. at the end of VM_Version::common_initialize(). > > And, dependency relationship can only be expressed in (1:1) way, can not be expressed (1:N) way, but in fact some extensions can depend on several different other extensions, for example, zvfh depends on zvf and rvv. It's would be better to support this (1:N) relationship. > > So, this PR brings several benefits: > 1. VM options directly related to CPU extensions are automatically set, and they are all set in one place. > 2. keep synchronization between CPU extensions (information in RVFeatureValue) and and VM options. Previously, code in common_initialize wont' sync to RVFeatureValue, unless do it manually, which is error-prone. > 3. support to express (1:N) dependency relationship among cpu extensions and related vm options. > > Thanks! > > > ## Test > > > $TEST_JDK/bin/java -XX:+UnlockExperimentalVMOptions -XX:-UseRVV -XX:+PrintFlagsFinal -version | grep -e UseRVV -e UseZvbc -e UseZvfh -e UseZvkn > OpenJDK 64-Bit Server VM warning: Cannot enable UseZvbb on cpu without any of the supports: v (disabled) > OpenJDK 64-Bit Server VM warning: Cannot enable UseZvbc on cpu without any of the supports: v (disabled) > OpenJDK 64-Bit Server VM warning: Cannot enable UseZvfh on cpu without any of the supports: v (disabled), Zfh (enabled) > bool UseRVV = false {ARCH diagnostic} {command line} > bool UseZvbc = false {ARCH experimental} {default} > bool UseZvfh = false {ARCH diagnostic} {default} > bool UseZvkn = false {ARCH experimental} {default} > > > > $TEST_JDK/bin/java -XX:+UnlockExperimentalVMOptions -XX:-UseZfh -XX:+PrintFlagsFinal -version | grep -e UseRVV -e UseZvbc -e UseZvfh -e UseZvkn > OpenJDK 64-Bit Server VM warning: Cannot enable UseZvfh on cpu without any of the supports: v (enabled), Zfh (disabled) > bool UseRVV = true {ARCH diagnostic} {default} > bool UseZvbc = true {ARCH experimental} {default} > bool UseZvfh ... This pull request has now been integrated. Changeset: 9d71af10 Author: Hamlin Li URL: https://git.openjdk.org/jdk/commit/9d71af108ea2cc3682607527246d60a19fd820ba Stats: 121 lines in 2 files changed: 36 ins; 30 del; 55 mod 8367253: RISC-V: refactor dependent cpu extensions Reviewed-by: fyang, luhenry ------------- PR: https://git.openjdk.org/jdk/pull/27171 From vlivanov at openjdk.org Mon Sep 29 16:15:16 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 29 Sep 2025 16:15:16 GMT Subject: RFR: 8368722: RISC-V: Several vector load/store tests fail on riscv without support for misaligned vector access In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 01:44:19 GMT, Dingli Zhang wrote: > Hi, > Can you help to review this patch? Thanks! > > In `*VectorLoadStoreTests.java`, `loadMemorySegmentMaskIOOBE` and `storeMemorySegmentMaskIOOBE` may fail because `int index = fi.apply((int) a.byteSize())` can generate random indices that result in misaligned addresses, leading to SIGBUS on hardware that disallows misaligned vector accesses. > > Some RISC-V hardware supports fast misaligned scalar accesses but not vector ones, which causes SIGBUS when executing these tests with misaligned vector memory operations. > > So we should adjusted index to align with the element byte size in these tests. > > ### Test > - [x] Run jdk_vector on k1 > - [x] Run jdk_vector on x86_64 and ARM64 That's a good point. I didn't realize it at first, but there's no point in enabling VM support when misaligned vector memory operations aren't natively supported by the JVM. C2 relies on `LoadVector`/`StoreVector` support for any vector operation (when performing vector boxing/unboxing for arguments & result). If those operations aren't supported, there's no way to intrinsify any other vector operations. So, either you introduce an emulation for `LoadVector`/`StoreVector` when misaligned vector accesses aren't supported or completely disable VM support by setting `-XX:-EnableVectorSupport`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27506#issuecomment-3347871216 From asmehra at openjdk.org Mon Sep 29 16:28:54 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Mon, 29 Sep 2025 16:28:54 GMT Subject: RFR: 8364929: Assign unique id to each AdapterBlob stored in AOTCodeCache Message-ID: This patch assigns unique id to each AdapterHandlerEntry so as to avoid using hash computed from AdapterFingerPrint which may not be unique. Unique id allows AOTCodeCache to locate the AdapterBlob being requested to be loaded. Testing: Before this patch `runtime/cds/appcds/aotClassLinking/StringConcatStress.java` emits warning messages in the production run: [0.009s][warning][aot,codecache,stubs] Saved blob's name 'LIIDIIIDL' is different from the expected name 'LIIDIIDL' [0.009s][warning][aot ] Failed to link AdapterHandlerEntry (fp=LIIDIIDL) to its code in the AOT code cache [0.009s][warning][aot,codecache,stubs] Saved blob's name 'IILLLLIIIIII' is different from the expected name 'IILLLLLILIII' [0.009s][warning][aot ] Failed to link AdapterHandlerEntry (fp=IILLLLLILIII) to its code in the AOT code cache With this patch, such warnings are not seen at all ------------- Commit messages: - 8364929: Assign unique id to each AdapterBlob stored in AOTCodeCache Changes: https://git.openjdk.org/jdk/pull/27553/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27553&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364929 Stats: 30 lines in 2 files changed: 14 ins; 1 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/27553.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27553/head:pull/27553 PR: https://git.openjdk.org/jdk/pull/27553 From jsjolen at openjdk.org Mon Sep 29 17:57:57 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 29 Sep 2025 17:57:57 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v9] In-Reply-To: References: Message-ID: > Hi, > > This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array` to store the offsets in and an `Array` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`. > > We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately. > > For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc. > > On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement. > > Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again. Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision: - Apply suggestions from code review Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> - Wrap size calc into static method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27198/files - new: https://git.openjdk.org/jdk/pull/27198/files/f96a16e5..5a42b0df Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=07-08 Stats: 9 lines in 3 files changed: 5 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27198/head:pull/27198 PR: https://git.openjdk.org/jdk/pull/27198 From jsjolen at openjdk.org Mon Sep 29 17:58:01 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 29 Sep 2025 17:58:01 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v5] In-Reply-To: <9GaOIC1GMr4TNQ-P-K54NJF-vVqaAFAOFVNZNNOpWM4=.a2c29f92-b499-4780-8187-82693d512448@github.com> References: <9GaOIC1GMr4TNQ-P-K54NJF-vVqaAFAOFVNZNNOpWM4=.a2c29f92-b499-4780-8187-82693d512448@github.com> Message-ID: On Thu, 18 Sep 2025 21:27:01 GMT, David Holmes wrote: >> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix rename > > src/hotspot/share/oops/constantPool.inline.hpp line 93: > >> 91: inline BSMAttributeEntry* BSMAttributeEntries::InsertionIterator::reserve_new_entry(u2 bsmi, u2 argc) { >> 92: if (_cur_offset + 1 > insert_into->offsets()->length() || >> 93: _cur_array + 1 + 1 + argc > insert_into->bootstrap_methods()->length()) { > > The `+ 1 + 1 + argc` looks a little magical - can we factor it out and explain it e.g. > > int next_array = _cur_array + 1 /* ??? */ + 1 /* ??? */ + argc; > ... > _curr_array = next_array; > ... I wrapped the size calculation into `BSMAE::u2s_needed` and annotated the magic numbers there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2388764436 From lmesnik at openjdk.org Mon Sep 29 18:09:43 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 29 Sep 2025 18:09:43 GMT Subject: RFR: 8355631: The events might be generated after VM_DEATH event In-Reply-To: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com> References: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com> Message-ID: On Thu, 25 Sep 2025 21:43:46 GMT, Leonid Mesnik wrote: > The JVMTI spec says: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#VMDeath > `The VM death event notifies the agent of the termination of the VM. No events will occur after the VMDeath event.` > > However, current implementation changes state and only after this start disabling events. > > It might be not a conformance issue, because there is no way to get thread state in the very beginning of event. > The main practical issue is that currently certain events are generated when VM is becoming dead. So any function in event should check error against JVMTI_PHASE_DEAD. We can easily trigger it by running tests with enabled https://bugs.openjdk.org/browse/JDK-8352654 > > The proposed fix to disable all event generation and then post the last (VMDeath) event. After this event is completed change VM phase to death. It's guaranteed that no any events are generated after VMDeath completion. > > After this fix the VMDeath callback also can't generate any events. > The alternative is to disable events posting after VMDeath completion and before changing VM state. However, seems it is still a gap between vm death event completion and disabling events. So user can see events after VMDeath completion. > > It might be still possible also to wait while all currently executing events are completed. It is not required be specification, might add unneeded complexity. So I want to apply this fix first and then to check if we still any problems. > Then, I plan to wait with timeout until all current (and queued) jvmti events are completed with some reasonable timeout. > Currently, I haven't seen problems with this fix and https://bugs.openjdk.org/browse/JDK-8352654. The VM Death call back is still valid point to call any java code. So the GC should be active at this point. I quickly check that 'Universe::before_exit()' doesn't post any jvmti events, so it makes sense to call it after vm death. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27504#issuecomment-3348335060 From asmehra at openjdk.org Mon Sep 29 18:44:31 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Mon, 29 Sep 2025 18:44:31 GMT Subject: RFR: 8364929: Assign unique id to each AdapterBlob stored in AOTCodeCache In-Reply-To: References: Message-ID: <3uJMHlUIc7b3JfthilJN8hNt5v18fEdiCg8-7MPS3tE=.3801bb0b-914b-4c1f-bfd7-746589ae6d38@github.com> On Mon, 29 Sep 2025 16:22:45 GMT, Ashutosh Mehra wrote: > This patch assigns unique id to each AdapterHandlerEntry so as to avoid using hash computed from AdapterFingerPrint which may not be unique. Unique id allows AOTCodeCache to locate the AdapterBlob being requested to be loaded. > > Testing: > Before this patch `runtime/cds/appcds/aotClassLinking/StringConcatStress.java` emits warning messages in the production run: > > [0.009s][warning][aot,codecache,stubs] Saved blob's name 'LIIDIIIDL' is different from the expected name 'LIIDIIDL' > [0.009s][warning][aot ] Failed to link AdapterHandlerEntry (fp=LIIDIIDL) to its code in the AOT code cache > [0.009s][warning][aot,codecache,stubs] Saved blob's name 'IILLLLIIIIII' is different from the expected name 'IILLLLLILIII' > [0.009s][warning][aot ] Failed to link AdapterHandlerEntry (fp=IILLLLLILIII) to its code in the AOT code cache > > With this patch, such warnings are not seen at all @adinn @vnkozlov can you please review this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27553#issuecomment-3348566123 From kvn at openjdk.org Mon Sep 29 20:09:49 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 29 Sep 2025 20:09:49 GMT Subject: RFR: 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays [v7] In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 15:00:58 GMT, Vladimir Ivanov wrote: >> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8365290 [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays > > Thanks for your review! @IvaVladimir Thank you for pinging me. Please, don't push this yet. I need to run our testing for it and do review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26747#issuecomment-3348861571 From mli at openjdk.org Mon Sep 29 20:33:48 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 29 Sep 2025 20:33:48 GMT Subject: RFR: 8368893: RISC-V: crash after JDK-8352673 on fastdebug version Message-ID: <75qGO1Bp16IqiuTctrqoaYKeS3keeHEnfWFQ2yz7eEc=.1777323a-da81-4ebd-aec6-a04402a79b44@github.com> Hi, Can you review this patch? check https://github.com/openjdk/jdk/pull/24182. This patch * fix the crash, * do some simple code cleanup, I don't think this piece of code is necessary: if (!ext_V.enabled() && FLAG_IS_DEFAULT(UseRVV)) { warning("RVV is not supported on this CPU"); FLAG_SET_DEFAULT(UseRVV, false); ## Crash crash when linux version < 6.8.5, with following command: * $ java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -version stack: Stack: [0x00007f5d4d05a000,0x00007f5d4d25a000], sp=0x00007f5d4d255e80, free space=2031k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x1661202] VM_Version::cpu_vector_length()+0x42 (vm_version_linux_riscv.cpp:103) V [libjvm.so+0x1662b1c] VM_Version::common_initialize()+0x25a (vm_version_riscv.cpp:202) V [libjvm.so+0x1662e0a] VM_Version::initialize()+0xc (vm_version_riscv.cpp:61) V [libjvm.so+0x1660cca] VM_Version_init()+0x46 (vm_version.cpp:31) V [libjvm.so+0xb6c538] init_globals()+0x68 (init.cpp:127) V [libjvm.so+0x158daea] Threads::create_vm(JavaVMInitArgs*, bool*)+0x370 (threads.cpp:576) V [libjvm.so+0xcd087c] JNI_CreateJavaVM+0x6e (jni.cpp:3587) C [libjli.so+0x612c] JavaMain+0x7a (java.c:1499) C [libjli.so+0x8eee] ThreadJavaMain+0xc (java_md.c:649) C [libc.so.6+0x67552] C [libc.so.6+0xb3b86] ## Test java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version | grep -e UseRVV -e MaxVectorSize intx MaxVectorSize = 0 {C2 product} {default} bool UseRVV = false {ARCH diagnostic} {default} java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:-UseRVV -version | grep -e UseRVV -e MaxVectorSize intx MaxVectorSize = 0 {C2 product} {default} bool UseRVV = false {ARCH diagnostic} {command line} java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -version | grep -e UseRVV -e MaxVectorSize intx MaxVectorSize = 32 {C2 product} {default} bool UseRVV = true {ARCH diagnostic} {command line} Thanks ------------- Commit messages: - initial commit - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - initial commit Changes: https://git.openjdk.org/jdk/pull/27557/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27557&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368893 Stats: 8 lines in 2 files changed: 0 ins; 6 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27557.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27557/head:pull/27557 PR: https://git.openjdk.org/jdk/pull/27557 From ayang at openjdk.org Mon Sep 29 20:39:01 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 29 Sep 2025 20:39:01 GMT Subject: RFR: 8363932: G1: Better distribute KlassCleaningTask [v2] In-Reply-To: References: <4wv4YEc8jXOrh142RF4lbiAOx5HSEe8tcDc-BYQC-5I=.461e968b-21dd-493e-9dfb-dcc9f962700a@github.com> Message-ID: On Mon, 22 Sep 2025 10:19:02 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to parallel klass cleaning to improve performance. >> >> The current implementation only parallelizes cleaning of weak class links, while the main work, cleaning the object tree is single-threaded. Hence in practice, the current mechanism does not scale beyond 2-3 threads. >> >> Cleaning an object graph in an application that loads some jars and instantiates central classes within them, with around 180k classes the current `G1 Complete Cleaning` task (which executes this code) can take 80ms (with 25 threads). >> >> The suggested change is to walk the object graph by (live) `ClassLoaderData` klass by klass, fixing only the links of that particular klass. >> >> E.g. >> >> CLD1 has klasses A, B, C, CLD2 has klasses a, b, c and CLD3 has klasses 0, 1, 2, 4; >> vertical links are subklass references, while horizontal links are sibling references. >> >> j.l.O >> | >> A - B - c - 3 >> | >> 0 - 2 - C - 1 >> >> >> CLD 3 is dead. Thread 1 claims CLD 1, Thread 2 claims CLD 2 (and nobody claims CLD3 because it's dead). >> >> So thread 1, when reaching `A` fixes its subklass link to `C`, and otherwise does nothing with `A`. When looking at `C`, it will remove the link to `1`. >> Thread 2 will only remove the link to `3` of `c`. >> >> The result is >> >> j.l.O >> | >> A - B - c >> | >> C >> >> >> There should be no unnecessary object graph walking. >> >> There is a slight change in printing during unlinking: previously the code, when cleaning subklasses it printed `unlinking class (subclass)`for every class that has been removed on the way to the next live one. In above case, it would print >> >> >> unlinking class (subclass): 0 >> unlinking class (subclass): 2 >> >> >> With the change, to avoid following the subklasses of the graph twice, it prints >> >> >> ?unlinking class (subclass): 0 >> unlinking class (sibling): 0 >> >> >> because the string in brackets is the actual link that is followed. I can revert that change. >> >> With the change "Complete Cleaning" time for 200k classes takes 7.6ms (The test is a bit random on when it does the class unloading). >> >> Testing: tier1-5 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * ayang review Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27316#pullrequestreview-3281701843 From mli at openjdk.org Mon Sep 29 21:28:33 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 29 Sep 2025 21:28:33 GMT Subject: RFR: 8367253: RISC-V: refactor dependent cpu extensions [v5] In-Reply-To: <845g5GCtOzmGoU34gGDN4i6ydb_M8HWa8so658YKdSw=.8196e561-9ed1-48ef-b49b-845d269898cf@github.com> References: <845g5GCtOzmGoU34gGDN4i6ydb_M8HWa8so658YKdSw=.8196e561-9ed1-48ef-b49b-845d269898cf@github.com> Message-ID: On Mon, 29 Sep 2025 08:55:58 GMT, Hamlin Li wrote: >> src/hotspot/cpu/riscv/vm_version_riscv.hpp line 103: >> >>> 101: } >>> 102: >>> 103: void verify_deps(RVFeatureValue* dep0, ...) { >> >> Not used anywhere? > > Thanks for catching! I'll just remove it in this pr. > > It should have been added in `UPDATE_DEFAULT_DEP(flag, dep0, ...)`, to do the similar work as the assert at https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/vm_version_riscv.hpp#L92. But seems previous way (introduced in https://github.com/openjdk/jdk/pull/24094) does not work as expected to catch declarations out of dependend orders, `verify_deps` does not catch it either as it inherits the way in the pr 24094. > > I'll investigate it later and fix it in another pr. I don't think the previous assert introduced in https://github.com/openjdk/jdk/pull/24094 is necessary. So we are good to just remove the related code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27171#discussion_r2389310449 From mli at openjdk.org Mon Sep 29 21:41:14 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 29 Sep 2025 21:41:14 GMT Subject: RFR: 8367253: RISC-V: refactor dependent cpu extensions [v5] In-Reply-To: References: <845g5GCtOzmGoU34gGDN4i6ydb_M8HWa8so658YKdSw=.8196e561-9ed1-48ef-b49b-845d269898cf@github.com> Message-ID: On Mon, 29 Sep 2025 21:26:04 GMT, Hamlin Li wrote: >> Thanks for catching! I'll just remove it in this pr. >> >> It should have been added in `UPDATE_DEFAULT_DEP(flag, dep0, ...)`, to do the similar work as the assert at https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/vm_version_riscv.hpp#L92. But seems previous way (introduced in https://github.com/openjdk/jdk/pull/24094) does not work as expected to catch declarations out of dependend orders, `verify_deps` does not catch it either as it inherits the way in the pr 24094. >> >> I'll investigate it later and fix it in another pr. > > I don't think the previous assert introduced in https://github.com/openjdk/jdk/pull/24094 is necessary. > So we are good to just remove the related code. check https://github.com/openjdk/jdk/pull/27562 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27171#discussion_r2389329229 From mli at openjdk.org Mon Sep 29 21:41:16 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 29 Sep 2025 21:41:16 GMT Subject: RFR: 8367103: RISC-V: store cpu features in a bitmap [v4] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 07:28:52 GMT, Fei Yang wrote: >> There is dependency between some extensions, which enforce some order not subject to this constraint. So, not sure if it's an good idea to force the aphabetic order, especailly in this pr. >> If you think it's necessary to do so, I can do it in another separate pr, and I hope to do it after https://github.com/openjdk/jdk/pull/27171. > > Sure. That works for me. Thanks. check https://github.com/openjdk/jdk/pull/27562 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27152#discussion_r2389328974 From mli at openjdk.org Mon Sep 29 21:45:19 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 29 Sep 2025 21:45:19 GMT Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS Message-ID: Hi, Can you help to review the patch? This patch cleans up RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS, as discussed https://github.com/openjdk/jdk/pull/27152#discussion_r2367109820: * reorder flags in alphabetic order for RV_EXT_FEATURE_FLAGS * move comments close to feature declaration for RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS We also discussed (https://github.com/openjdk/jdk/pull/27171#discussion_r2387195562) the assert introduced in https://github.com/openjdk/jdk/pull/24094, previously we think this will restrict the flags order in RV_EXT_FEATURE_FLAGS, but I found out that this assert is not necessary, so we should be able to order flags in RV_EXT_FEATURE_FLAGS in any way we'd like to. Thanks! ------------- Commit messages: - initial commit - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - initial commit Changes: https://git.openjdk.org/jdk/pull/27562/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27562&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368897 Stats: 103 lines in 1 file changed: 44 ins; 48 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/27562.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27562/head:pull/27562 PR: https://git.openjdk.org/jdk/pull/27562 From fyang at openjdk.org Tue Sep 30 01:16:42 2025 From: fyang at openjdk.org (Fei Yang) Date: Tue, 30 Sep 2025 01:16:42 GMT Subject: RFR: 8368732: RISC-V: Detect support for misaligned vector access via hwprobe [v7] In-Reply-To: References: Message-ID: > Hi, this is a followup change after [JDK-8368366](https://bugs.openjdk.org/browse/JDK-8368366). > > According to the latest RISC-V linux hardware probing syscall [1], the performance of misaligned memory accesses has been divided into two cases: `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` and `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` for scalar and vector respectively. > > This aligns `AlignVector` with `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF`. That is if the misaligned vector access is fast, we set `AlignVector` to false in the hope that it will save instructions handling address alignment thus improves performance. > > This choose to keep the use of `RISCV_HWPROBE_KEY_CPUPERF_0` which is now deprecated and returns similar values > to `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` for backward compatibility with old linux kernels. > > Manually checked the result on platforms w/wo fast misaligned vector accesses by running: > `$java -XX:+PrintFlagsFinal -version | grep AlignVector` > > [1] https://docs.kernel.org/arch/riscv/hwprobe.html Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into JDK-8368732 - Review - Review - Fix - Macro names - More white spaces - White spaces - 8368732: RISC-V: Detect support for misaligned vector access via hwprobe ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27512/files - new: https://git.openjdk.org/jdk/pull/27512/files/aabf1ea9..4d6540a8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27512&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27512&range=05-06 Stats: 3556 lines in 121 files changed: 2187 ins; 661 del; 708 mod Patch: https://git.openjdk.org/jdk/pull/27512.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27512/head:pull/27512 PR: https://git.openjdk.org/jdk/pull/27512 From fyang at openjdk.org Tue Sep 30 01:44:04 2025 From: fyang at openjdk.org (Fei Yang) Date: Tue, 30 Sep 2025 01:44:04 GMT Subject: RFR: 8368732: RISC-V: Detect support for misaligned vector access via hwprobe [v7] In-Reply-To: References: Message-ID: <4aqSfY-H7AcosDqRIsgvKqcq3mE6P-oS94uQ_39gk48=.0ddbe2c8-0771-458c-8709-65b9e316e870@github.com> On Mon, 29 Sep 2025 14:12:55 GMT, Hamlin Li wrote: >> Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: >> >> - Merge remote-tracking branch 'upstream/master' into JDK-8368732 >> - Review >> - Review >> - Fix >> - Macro names >> - More white spaces >> - White spaces >> - 8368732: RISC-V: Detect support for misaligned vector access via hwprobe > > Looks good. Thanks! @Hamlin-Li @DingliZhang : Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27512#issuecomment-3349628414 From fyang at openjdk.org Tue Sep 30 01:44:05 2025 From: fyang at openjdk.org (Fei Yang) Date: Tue, 30 Sep 2025 01:44:05 GMT Subject: Integrated: 8368732: RISC-V: Detect support for misaligned vector access via hwprobe In-Reply-To: References: Message-ID: <2rouBRJGPBuVVRZbgtbkE-IOVGFuBW_FReNCOkJ--js=.71c92c0d-c41e-4db8-a5ba-3ece6810a32f@github.com> On Fri, 26 Sep 2025 06:28:39 GMT, Fei Yang wrote: > Hi, this is a followup change after [JDK-8368366](https://bugs.openjdk.org/browse/JDK-8368366). > > According to the latest RISC-V linux hardware probing syscall [1], the performance of misaligned memory accesses has been divided into two cases: `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` and `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` for scalar and vector respectively. > > This aligns `AlignVector` with `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF`. That is if the misaligned vector access is fast, we set `AlignVector` to false in the hope that it will save instructions handling address alignment thus improves performance. > > This choose to keep the use of `RISCV_HWPROBE_KEY_CPUPERF_0` which is now deprecated and returns similar values > to `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` for backward compatibility with old linux kernels. > > Manually checked the result on platforms w/wo fast misaligned vector accesses by running: > `$java -XX:+PrintFlagsFinal -version | grep AlignVector` > > [1] https://docs.kernel.org/arch/riscv/hwprobe.html This pull request has now been integrated. Changeset: 538a722c Author: Fei Yang URL: https://git.openjdk.org/jdk/commit/538a722c2e9123cc575355879ff230444cf2dadc Stats: 61 lines in 4 files changed: 47 ins; 1 del; 13 mod 8368732: RISC-V: Detect support for misaligned vector access via hwprobe Reviewed-by: mli, dzhang ------------- PR: https://git.openjdk.org/jdk/pull/27512 From fyang at openjdk.org Tue Sep 30 02:25:50 2025 From: fyang at openjdk.org (Fei Yang) Date: Tue, 30 Sep 2025 02:25:50 GMT Subject: RFR: 8368893: RISC-V: crash after JDK-8352673 on fastdebug version In-Reply-To: <75qGO1Bp16IqiuTctrqoaYKeS3keeHEnfWFQ2yz7eEc=.1777323a-da81-4ebd-aec6-a04402a79b44@github.com> References: <75qGO1Bp16IqiuTctrqoaYKeS3keeHEnfWFQ2yz7eEc=.1777323a-da81-4ebd-aec6-a04402a79b44@github.com> Message-ID: On Mon, 29 Sep 2025 20:24:25 GMT, Hamlin Li wrote: > Hi, > Can you review this patch? > > check https://github.com/openjdk/jdk/pull/24182. > > This patch > * fix the crash, > * do some simple code cleanup, I don't think this piece of code is necessary: > > if (!ext_V.enabled() && FLAG_IS_DEFAULT(UseRVV)) { > warning("RVV is not supported on this CPU"); > FLAG_SET_DEFAULT(UseRVV, false); > > > ## Crash > crash when linux version < 6.8.5, with following command: > * $ java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -version > > stack: > > Stack: [0x00007f5d4d05a000,0x00007f5d4d25a000], sp=0x00007f5d4d255e80, free space=2031k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x1661202] VM_Version::cpu_vector_length()+0x42 (vm_version_linux_riscv.cpp:103) > V [libjvm.so+0x1662b1c] VM_Version::common_initialize()+0x25a (vm_version_riscv.cpp:202) > V [libjvm.so+0x1662e0a] VM_Version::initialize()+0xc (vm_version_riscv.cpp:61) > V [libjvm.so+0x1660cca] VM_Version_init()+0x46 (vm_version.cpp:31) > V [libjvm.so+0xb6c538] init_globals()+0x68 (init.cpp:127) > V [libjvm.so+0x158daea] Threads::create_vm(JavaVMInitArgs*, bool*)+0x370 (threads.cpp:576) > V [libjvm.so+0xcd087c] JNI_CreateJavaVM+0x6e (jni.cpp:3587) > C [libjli.so+0x612c] JavaMain+0x7a (java.c:1499) > C [libjli.so+0x8eee] ThreadJavaMain+0xc (java_md.c:649) > C [libc.so.6+0x67552] > C [libc.so.6+0xb3b86] > > > ## Test > > > java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version | grep -e UseRVV -e MaxVectorSize > intx MaxVectorSize = 0 {C2 product} {default} > bool UseRVV = false {ARCH diagnostic} {default} > > > > > java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:-UseRVV -version | grep -e UseRVV -e MaxVectorSize > intx MaxVectorSize = 0 {C2 product} {default} > bool UseRVV = false {ARCH diagnostic} {command line} > > > > java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -version | grep -e UseRVV -e MaxVectorSize > intx MaxVectorSize = 32 {C2 product} {default} > bool UseRVV = true {ARCH diagnostic} {command line} > > > > Thanks Thanks! ------------- Marked as reviewed by fyang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27557#pullrequestreview-3282364736 From dzhang at openjdk.org Tue Sep 30 02:25:50 2025 From: dzhang at openjdk.org (Dingli Zhang) Date: Tue, 30 Sep 2025 02:25:50 GMT Subject: RFR: 8368893: RISC-V: crash after JDK-8352673 on fastdebug version In-Reply-To: <75qGO1Bp16IqiuTctrqoaYKeS3keeHEnfWFQ2yz7eEc=.1777323a-da81-4ebd-aec6-a04402a79b44@github.com> References: <75qGO1Bp16IqiuTctrqoaYKeS3keeHEnfWFQ2yz7eEc=.1777323a-da81-4ebd-aec6-a04402a79b44@github.com> Message-ID: On Mon, 29 Sep 2025 20:24:25 GMT, Hamlin Li wrote: > Hi, > Can you review this patch? > > check https://github.com/openjdk/jdk/pull/24182. > > This patch > * fix the crash, > * do some simple code cleanup, I don't think this piece of code is necessary: > > if (!ext_V.enabled() && FLAG_IS_DEFAULT(UseRVV)) { > warning("RVV is not supported on this CPU"); > FLAG_SET_DEFAULT(UseRVV, false); > > > ## Crash > crash when linux version < 6.8.5, with following command: > * $ java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -version > > stack: > > Stack: [0x00007f5d4d05a000,0x00007f5d4d25a000], sp=0x00007f5d4d255e80, free space=2031k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x1661202] VM_Version::cpu_vector_length()+0x42 (vm_version_linux_riscv.cpp:103) > V [libjvm.so+0x1662b1c] VM_Version::common_initialize()+0x25a (vm_version_riscv.cpp:202) > V [libjvm.so+0x1662e0a] VM_Version::initialize()+0xc (vm_version_riscv.cpp:61) > V [libjvm.so+0x1660cca] VM_Version_init()+0x46 (vm_version.cpp:31) > V [libjvm.so+0xb6c538] init_globals()+0x68 (init.cpp:127) > V [libjvm.so+0x158daea] Threads::create_vm(JavaVMInitArgs*, bool*)+0x370 (threads.cpp:576) > V [libjvm.so+0xcd087c] JNI_CreateJavaVM+0x6e (jni.cpp:3587) > C [libjli.so+0x612c] JavaMain+0x7a (java.c:1499) > C [libjli.so+0x8eee] ThreadJavaMain+0xc (java_md.c:649) > C [libc.so.6+0x67552] > C [libc.so.6+0xb3b86] > > > ## Test > > > java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -version | grep -e UseRVV -e MaxVectorSize > intx MaxVectorSize = 0 {C2 product} {default} > bool UseRVV = false {ARCH diagnostic} {default} > > > > > java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:-UseRVV -version | grep -e UseRVV -e MaxVectorSize > intx MaxVectorSize = 0 {C2 product} {default} > bool UseRVV = false {ARCH diagnostic} {command line} > > > > java -XX:+PrintFlagsFinal -XX:+UnlockDiagnosticVMOptions -XX:+UseRVV -version | grep -e UseRVV -e MaxVectorSize > intx MaxVectorSize = 32 {C2 product} {default} > bool UseRVV = true {ARCH diagnostic} {command line} > > > > Thanks LGTM, thanks! ------------- Marked as reviewed by dzhang (Author). PR Review: https://git.openjdk.org/jdk/pull/27557#pullrequestreview-3282366648 From dzhang at openjdk.org Tue Sep 30 03:01:10 2025 From: dzhang at openjdk.org (Dingli Zhang) Date: Tue, 30 Sep 2025 03:01:10 GMT Subject: RFR: 8368722: RISC-V: Several vector load/store tests fail without support for misaligned vector access [v2] In-Reply-To: References: Message-ID: > Hi, > Can you help to review this patch? Thanks! > > In `*VectorLoadStoreTests.java`, `loadMemorySegmentMaskIOOBE` and `storeMemorySegmentMaskIOOBE` may fail because `int index = fi.apply((int) a.byteSize())` can generate random indices that result in misaligned addresses, leading to SIGBUS on hardware that disallows misaligned vector accesses. > > Some RISC-V hardware supports fast misaligned scalar accesses but not vector ones, which causes SIGBUS when executing these tests with misaligned vector memory operations. > > After [JDK-8368732](https://bugs.openjdk.org/browse/JDK-8368732), we can use `AlignVector` to check the result on platforms with or without fast misaligned vector accesses. When misaligned vector accesses are not supported, it is possible to completely disable the VM?s VectorAPI support by setting `EnableVectorSupport`, without affecting auto-vectorization. > > In addition, after running fastdebug tests including `jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization`, we found that some IR-related tests require EnableVectorSupport. Therefore, we added `@requires vm.opt.EnableVectorSupport == true` to skip these tests. > > We can check the status of EnableVectorSupport as follows: > > On k1 > $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version > [0.737s][info][compilation] EnableVectorSupport=false > [0.738s][info][compilation] EnableVectorReboxing=false > [0.738s][info][compilation] EnableVectorAggressiveReboxing=false > > On qemu > $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version > [3.048s][info][compilation] EnableVectorSupport=true > [3.050s][info][compilation] EnableVectorReboxing=true > [3.051s][info][compilation] EnableVectorAggressiveReboxing=true > > > ### Test (fastdebug) > - [x] Run jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization on k1 Dingli Zhang 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 one additional commit since the last revision: 8368722: RISC-V: Several vector load/store tests fail without support for misaligned vector access ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27506/files - new: https://git.openjdk.org/jdk/pull/27506/files/9cca9967..a36d5f8f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27506&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27506&range=00-01 Stats: 3744 lines in 174 files changed: 2283 ins; 668 del; 793 mod Patch: https://git.openjdk.org/jdk/pull/27506.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27506/head:pull/27506 PR: https://git.openjdk.org/jdk/pull/27506 From dzhang at openjdk.org Tue Sep 30 03:01:11 2025 From: dzhang at openjdk.org (Dingli Zhang) Date: Tue, 30 Sep 2025 03:01:11 GMT Subject: RFR: 8368722: RISC-V: Several vector load/store tests fail without support for misaligned vector access In-Reply-To: References: Message-ID: <0ToelwpUX6z7CCZd6grXyqOviQHFQx67AGdOxSI4hrQ=.2ac1470e-4fa3-4c3b-9d21-45e7a48261e3@github.com> On Fri, 26 Sep 2025 08:32:56 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? Thanks! >> >> In `*VectorLoadStoreTests.java`, `loadMemorySegmentMaskIOOBE` and `storeMemorySegmentMaskIOOBE` may fail because `int index = fi.apply((int) a.byteSize())` can generate random indices that result in misaligned addresses, leading to SIGBUS on hardware that disallows misaligned vector accesses. >> >> Some RISC-V hardware supports fast misaligned scalar accesses but not vector ones, which causes SIGBUS when executing these tests with misaligned vector memory operations. >> >> After [JDK-8368732](https://bugs.openjdk.org/browse/JDK-8368732), we can use `AlignVector` to check the result on platforms with or without fast misaligned vector accesses. When misaligned vector accesses are not supported, it is possible to completely disable the VM?s VectorAPI support by setting `EnableVectorSupport`, without affecting auto-vectorization. >> >> In addition, after running fastdebug tests including `jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization`, we found that some IR-related tests require EnableVectorSupport. Therefore, we added `@requires vm.opt.EnableVectorSupport == true` to skip these tests. >> >> We can check the status of EnableVectorSupport as follows: >> >> On k1 >> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version >> [0.737s][info][compilation] EnableVectorSupport=false >> [0.738s][info][compilation] EnableVectorReboxing=false >> [0.738s][info][compilation] EnableVectorAggressiveReboxing=false >> >> On qemu >> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version >> [3.048s][info][compilation] EnableVectorSupport=true >> [3.050s][info][compilation] EnableVectorReboxing=true >> [3.051s][info][compilation] EnableVectorAggressiveReboxing=true >> >> >> ### Test (fastdebug) >> - [x] Run jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization on k1 > > Hey, not check the pr yet. It's better to have a `RISC-V: ` prefix in the issue's subject. Hi @Hamlin-Li @iwanowww Could you help review it again? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27506#issuecomment-3349754614 From fyang at openjdk.org Tue Sep 30 03:05:45 2025 From: fyang at openjdk.org (Fei Yang) Date: Tue, 30 Sep 2025 03:05:45 GMT Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 21:37:49 GMT, Hamlin Li wrote: > Hi, > Can you help to review the patch? > > This patch cleans up RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS, as discussed https://github.com/openjdk/jdk/pull/27152#discussion_r2367109820: > * reorder flags in alphabetic order for RV_EXT_FEATURE_FLAGS > * move comments close to feature declaration for RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS > > We also discussed (https://github.com/openjdk/jdk/pull/27171#discussion_r2387195562) the assert introduced in https://github.com/openjdk/jdk/pull/24094, previously we think this will restrict the flags order in RV_EXT_FEATURE_FLAGS, but I found out that this assert is not necessary, so we should be able to order flags in RV_EXT_FEATURE_FLAGS in any way we'd like to. > > Thanks! Hi, You need merge and rebase :-) But the order of the detection of these extesions still matters, right? Say we must detect `ext_v` before `ext_Zvbb`. ------------- PR Review: https://git.openjdk.org/jdk/pull/27562#pullrequestreview-3282416140 From duke at openjdk.org Tue Sep 30 04:38:48 2025 From: duke at openjdk.org (Bernd) Date: Tue, 30 Sep 2025 04:38:48 GMT Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time In-Reply-To: References: Message-ID: On Sat, 27 Sep 2025 11:18:58 GMT, Jonas Norlinder wrote: > Hi all, > > This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding. > > `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem. > > FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM. > > Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug. Thanks, it?s a useful function. (I would not have expected it in the memory bean but in the go bean, but I guess both is fine.) Some more comments inline src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 273: > 271: * Returns the CPU time used by all garbage collection threads. > 272: * > 273: *

This include time since genesis, so the value can be The ?so the? is not too obvious to me. Maybe simplify it a bit ?This includes time since genesis and counts activities even before the first collection cycle.?? src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 279: > 277: * deduplication thread (if enabled). This method returns > 278: * {@code -1} if the platform does not support this operation > 279: * or if called during shutdown. Can we explicitly state here that this is concurrent time as well as worker time spent during pauses but not accumulated pause times? src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 282: > 280: * > 281: * @return the total CPU time for all garbage collection > 282: * threads in nanoseconds. Not sure did I miss the discussion, other methods like getTotalCompilationTime() return millis, is it ok or required to use new units here? test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java line 73: > 71: while (true) { > 72: long gcCpuTimeFromThread = mxMemoryBean.getGcCpuTime(); > 73: if (gcCpuTimeFromThread < -1) { None of the tests actually test if it is ever != -1 or if it is monotonically increasing or under which conditions (go? Platform? Build flags?) it is unsupported? ------------- PR Review: https://git.openjdk.org/jdk/pull/27537#pullrequestreview-3282521865 PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2389806062 PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2389808338 PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2389815933 PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2389822026 From stuefe at openjdk.org Tue Sep 30 05:07:55 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 30 Sep 2025 05:07:55 GMT Subject: RFR: 8368365: ASAN errors should produce hs-err files and core dumps [v7] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 08:36:15 GMT, Thomas Stuefe wrote: >> When we run with ASAN enabled and ASAN catches an error, it reports, then stops the JVM. hs-err files and crash dumps at that point would be incredibly useful, though. The ASAN error report itself is seldom enlightening since it only contains native stacks. >> >> After this patch, the JVM will always produce hs-err files when an ASAN-report happens. It will *only* produce core files if ASAN_OPTIONS `disable_coredump=0` and `abort_on_error=1` and the JVM option `CreateCoredumpOnCrash` had not been disabled (and the limit for core file size is high enough etc, all the usual restrictions on OS level still apply). >> >> This means that ASAN builds, by default, will continue to *not* generate cores, since ASAN default options inhibit that. See detail in the comments below. >> >> --- >> >> Tested on Fedora 42 and Debian 12, both manually and by running the new companion jtreg test. > > Thomas Stuefe has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. Thanks all. I'll hold off with the push until I am back from vacation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27446#issuecomment-3349993794 From duke at openjdk.org Tue Sep 30 05:13:04 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 30 Sep 2025 05:13:04 GMT Subject: Integrated: 8367485: os::physical_memory is broken in 32-bit JVMs when running on 64-bit OSes In-Reply-To: References: Message-ID: <-VHkaO8YWmJ-byTJT3QFhhQFf2uwS6kbkz_0aSaPgSY=.5271d59f-4693-4f6b-ad82-a7f0122d4c28@github.com> On Wed, 17 Sep 2025 08:42:11 GMT, Anton Artemov wrote: > Hi, please consider the following changes: > > In this PR we address the overflow issue in `os::physical_memory()` on Linux, which can occur when running a 32-bit JVM on a 64-bit machine, introduced by https://bugs.openjdk.org/browse/JDK-8357086. The problem is that the product of _SC_PHYS_PAGES and _SC_PAGESIZE can overflow according to the documentation. > > The issue is addressed by changing the output type of all related functions to `physical_memory_size_type`, which is an alias to `uint64_t`. > > Tested in tiers 1 - 5. This pull request has now been integrated. Changeset: 2746c1a5 Author: Anton Artemov Committer: Thomas Stuefe URL: https://git.openjdk.org/jdk/commit/2746c1a555891564963299182b3b0293eaefc901 Stats: 152 lines in 20 files changed: 7 ins; 0 del; 145 mod 8367485: os::physical_memory is broken in 32-bit JVMs when running on 64-bit OSes Reviewed-by: jsikstro, sgehwolf, stefank, stuefe, aph ------------- PR: https://git.openjdk.org/jdk/pull/27335 From dholmes at openjdk.org Tue Sep 30 06:30:48 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 30 Sep 2025 06:30:48 GMT Subject: RFR: 8355631: The events might be generated after VM_DEATH event In-Reply-To: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com> References: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com> Message-ID: <9Pt3r-dYcnG_IOpxWynEIWfl4EF0ZQVVoQ1CHbstwRo=.ea9be3fe-1143-4615-a26d-8c51f0adbfc0@github.com> On Thu, 25 Sep 2025 21:43:46 GMT, Leonid Mesnik wrote: > After this fix the VMDeath callback also can't generate any events. I think this needs a CSR request and likely a release note. Though if you plan to later wait for all event processing to complete, is it even necessary to make the current change? The spec is very imprecise when it comes to when exactly no further events will be processed, but it seems reasonable to expect that the callback for VM_DEATH is the last thing that should generate events. Though unless event processing is fully synchronized with locks (which I'm pretty sure it isn't) then you have races no matter what you do. I am concerned that, given you cannot completely prevent events from being generated "after" VM_DEATH, the change may "break" more code than it "fixes". ?? src/hotspot/share/prims/jvmtiEventController.cpp line 1060: > 1058: void > 1059: JvmtiEventControllerPrivate::vm_death() { > 1060: _execution_finished = true; Unless there is some lock guarding this that I cannot see in this diff, if you want to ensure this will be seen as soon as possible then you need a `store_fence` (and the variable should be `volatile` - and will be a candidate for `Atomic`). You are still racing with others threads but this would at least attempt to minimise the window. ------------- PR Review: https://git.openjdk.org/jdk/pull/27504#pullrequestreview-3282743437 PR Review Comment: https://git.openjdk.org/jdk/pull/27504#discussion_r2389970167 From dholmes at openjdk.org Tue Sep 30 06:51:49 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 30 Sep 2025 06:51:49 GMT Subject: RFR: 8367013: Add Atomic to package/replace idiom of volatile var plus AtomicAccess:: operations In-Reply-To: References: Message-ID: <412dpkY8V6-WYlLdqsSBIjoOCTXJua5-jQO1PzLRE-s=.308279ed-5eda-4658-bcac-0d3e61347497@github.com> On Mon, 29 Sep 2025 12:06:04 GMT, Kim Barrett wrote: > I've always thought it's weird that for most AtomicAccess operations, the short form (defaulted memory order) provides the strongest ordering, but the short form of load/store is the weakest form. Atomic r-m-w operations (pretty much everything except base load/store) were required to have full bi-directional fence semantics from "day one". That doesn't make sense for base load/store so they are "relaxed" by default. I personally hate the term "relaxed" as it suggests to me a removal of "normal" ordering, when really it means the absence of a stronger ordering. Naming is hard and very subjective. I agree with @stefank about `relaxed_store` and `release_store` being similar enough that you have to stop and make sure you read it correctly. I don't have an issue with dropping `relaxed` from the names. I'm also not going to fight for its removal. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3350228979 From dholmes at openjdk.org Tue Sep 30 07:03:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 30 Sep 2025 07:03:53 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing [v9] In-Reply-To: References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> Message-ID: On Tue, 23 Sep 2025 15:02:51 GMT, Johannes Bechberger wrote: >> This change hopefully fixes the test failures by making the test cases more resilient. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Fix build issue Needed to add back the hotspot-jfr label as skara had removed it. JFR folk can we please get this re-reviewed and approved. Thanks. @parttimenerd perhaps you could rally other JEP 509 folk to review this fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27293#issuecomment-3350276492 From dholmes at openjdk.org Tue Sep 30 07:09:59 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 30 Sep 2025 07:09:59 GMT Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v9] In-Reply-To: References: Message-ID: <2Sj-S9Au_zYHUwDITCnAkoUBPAGpG-bOLJMrnFbBNDY=.95369cfe-a4f0-4727-a026-5203f26414ae@github.com> On Mon, 29 Sep 2025 17:57:57 GMT, Johan Sj?len wrote: >> Hi, >> >> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array` to store the offsets in and an `Array` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`. >> >> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately. >> >> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc. >> >> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement. >> >> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again. > > Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision: > > - Apply suggestions from code review > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> > - Wrap size calc into static method src/hotspot/share/oops/constantPool.hpp line 127: > 125: > 126: // How many u2s are required to store a BSM entry with argc arguments? > 127: static size_t u2s_required (u2 argc) { Suggestion: static int u2s_required (u2 argc) { If you are going to cast the result to an int, it may as well be an int anyway. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2390090412 From vyazici at openjdk.org Tue Sep 30 07:31:41 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 30 Sep 2025 07:31:41 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v4] In-Reply-To: References: Message-ID: On Sun, 28 Sep 2025 16:44:56 GMT, Alan Bateman wrote: >> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500). >> >> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP. >> >> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX). >> >> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package. >> >> Testing: tier1-6 > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > RemoveFields(duration) and filter internal frames I've read the JEP, and reviewed the tests. I hope I manage to contribute meaningfully. A common theme I've struggled with: While JEP explicitly mentions of `static` fields, and `MethodHandle`s, they are not always exercised in tests. It very well might be unnecessary given the context, but dropped some comments anyway. For those who were about to jump the gun after seeing no mentions of `VarHandle`s: _"The 2 APIs that are changed by the JEP are `Field.setXXX` and `Lookup.unreflectSetter`. A `VarHandle` produced by `Lookup.unreflectVarHandle` has never been allowed write access to final fields, so no change there, `UOE` will continue to be thrown."_ ? @AlanBateman src/hotspot/share/runtime/arguments.cpp line 2281: > 2279: } > 2280: } else if (match_option(option, "--illegal-final-field-mutation=", &tail)) { > 2281: if (strcmp(tail, "allow") == 0 || strcmp(tail, "warn") == 0 || strcmp(tail, "debug") == 0 || strcmp(tail, "deny") == 0) { Is the `jdk.module.illegal.final.field.mutation` property intended as a public API? If so, where is it documented? test/jdk/java/lang/reflect/Field/mutateFinals/FinalFieldMutationEventTest.java line 1: > 1: /* Do we need to extend the cases for a `static` field? test/jdk/java/lang/reflect/Field/mutateFinals/FinalFieldMutationEventTest.java line 79: > 77: recording.enable(EVENT_NAME).withStackTrace(); > 78: > 79: boolean mutated = false; Instead of relying on `IAE` to be thrown as expected, you may consider passing `mutated` flag in `@run` (`-DwriteAccess`?) and using it to double-check the programmatically computed `mutated`. test/jdk/java/lang/reflect/Field/mutateFinals/FinalFieldMutationEventTest.java line 114: > 112: > 113: try (Recording recording = new Recording()) { > 114: recording.enable(EVENT_NAME).withStackTrace(); Above remark on `mutated` applies to `unreflected` too. test/jdk/java/lang/reflect/Field/mutateFinals/MutateFinalsTest.java line 1: > 1: /* Do we need to extend the cases for `static` fields and VH too? test/jdk/java/lang/reflect/Field/mutateFinals/MutateFinalsTest.java line 33: > 31: * @run junit/othervm --illegal-final-field-mutation=debug -DwriteAccess=true MutateFinalsTest > 32: * @run junit/othervm --illegal-final-field-mutation=deny -DwriteAccess=false MutateFinalsTest > 33: */ Shall we also test the defaults too? Suggestion: * @run junit/othervm -DwriteAccess=true MutateFinalsTest */ test/jdk/java/lang/reflect/Field/mutateFinals/cli/CommandLineTest.java line 122: > 120: * Test warn on first mutation of a final. > 121: */ > 122: @Test Shall we also test the other way around (i.e., `testUnreflectSetter+testFieldSetInt`) and assert that the ` has been unreflected ...` warning is emitted? test/jdk/java/lang/reflect/Field/mutateFinals/cli/CommandLineTest.java line 123: > 121: */ > 122: @Test > 123: void testWarn() throws Exception { While this asserts `WARNING: Final field ...` is emitted, it does not assert it is emitted *once*. You may consider performing this check too. test/jdk/java/lang/reflect/Field/mutateFinals/cli/CommandLineTest.java line 166: > 164: .shouldHaveExitValue(0); > 165: } > 166: You may consider repeating the test with `deny, allow` order. test/jdk/java/lang/reflect/Field/mutateFinals/cli/CommandLineTest.java line 185: > 183: } > 184: > 185: /** Suggestion: * Test setting system property to "allow" at runtime. The saved value from startup test/jdk/java/lang/reflect/Field/mutateFinals/cli/CommandLineTest.java line 190: > 188: @Test > 189: void testLastOneWins() throws Exception { > 190: test("testFieldSetInt", "--illegal-final-field-mutation=allow", "--illegal-final-field-mutation=deny") This tests `setProperty+Defaults`. Shall we also test `setProperty+vmOpt`? test/jdk/java/lang/reflect/Field/mutateFinals/cli/CommandLineTestHelper.java line 1: > 1: /* Do we also need to assert the default IAE throw before `f.setAccessible(true)` calls? test/jdk/java/lang/reflect/Field/mutateFinals/jar/ExecutableJarTest.java line 100: > 98: testExecutableJar(jarFile, "testUnreflectSetter") > 99: .shouldNotContain(WARNING_LINE1) > 100: .shouldNotContain(WARNING_UNREFLECTED) We test * `manifest={mutation=allow}` & `cliOpts={}`, and * `manifest={mutation=allow}` & `cliOpts={mutation=deny}`. Shall we also add a test with `manifest={}` & `cliOpts={mutation=allow}`? That is, in the absence of a manifest entry, do command line arguments still apply? test/jdk/java/lang/reflect/Field/mutateFinals/jar/ExecutableJarTest.java line 104: > 102: } > 103: > 104: /** Why don't we verify the output (i.e., no warnings) in this case? test/jdk/java/lang/reflect/Field/mutateFinals/jar/ExecutableJarTest.java line 110: > 108: */ > 109: @Test > 110: void testFieldSetWithAddOpens1() throws Exception { Suggestion: * with the Add-Opens attribute. test/jdk/java/lang/reflect/Field/mutateFinals/jar/ExecutableJarTest.java line 121: > 119: } > 120: > 121: /** Why don't we verify the output (i.e., no warnings) in this case? test/jdk/java/lang/reflect/Field/mutateFinals/jar/ExecutableJarTest.java line 129: > 127: void testFieldSetWithAddOpens2() throws Exception { > 128: String jarFile = createExecutableJar(Map.of( > 129: "Enable-Final-Field-Mutation", "ALL-UNNAMED", Instead of `BadValue`, shall we use a valid module name here to stress the following specification from the JEP: > The only supported value for the `Enable-Final-Field-Mutation` > manifest entry is `ALL-UNNAMED`; other values cause an > exception to be thrown. test/jdk/java/lang/reflect/Field/mutateFinals/jar/ExecutableJarTestHelper.java line 1: > 1: /* Do we need to extend the cases for a `static` value and VH? test/jdk/java/lang/reflect/Field/mutateFinals/jar/ExecutableJarTestHelper.java line 1: > 1: /* Do we also need to assert the default IAE throw before `f.setAccessible(true)` calls? test/jdk/java/lang/reflect/Field/mutateFinals/jni/JNIAttachMutator.java line 59: > 57: this.value = value; > 58: } > 59: } Do we need to extend this list with a copy of itself where `value` is static? test/jdk/java/lang/reflect/Field/mutateFinals/jni/JNIAttachMutatorTest.java line 1: > 1: /* Similar to `ExecutableJarTest`, do we need to extend this test for named modules? test/jdk/java/lang/reflect/Field/mutateFinals/modules/Driver.java line 30: > 28: * field is open to m2 and not open to m3. > 29: * @build m1/* m2/* m3/* > 30: * @run junit/othervm --illegal-final-field-mutation=allow -DallowedToMutate=m1,m2 m1/p1.TestMain Instead of an explicit `allow`, shall we use (and hence, stress) the defaults? Suggestion: * @run junit/othervm -DallowedToMutate=m1,m2 m1/p1.TestMain test/jdk/java/lang/reflect/Field/mutateFinals/modules/m1/p1/Mutator.java line 36: > 34: void setInt(Field f, Object obj, short value) throws IllegalAccessException; > 35: void setInt(Field f, Object obj, int value) throws IllegalAccessException; > 36: void setLong(Field f, Object obj, long value) throws IllegalAccessException; Is void setInt(..., short value) used at all? If so, 1. Where? 2. Do we also need the following? setLong(..., short value) setLong(..., int value) setDouble(..., float value) test/jdk/java/lang/reflect/Field/mutateFinals/modules/m1/p1/TestMain.java line 1: > 1: /* All `C::value` are instance fields, do we need to test class (i.e., `static`) fields too? test/jdk/java/lang/reflect/Field/mutateFinals/modules/m1/p1/TestMain.java line 42: > 40: * Test mutating final fields from different modules. > 41: */ > 42: Suggestion: test/jdk/java/lang/reflect/Field/mutateFinals/modules/m1/p1/TestMain.java line 44: > 42: > 43: class TestMain { > 44: // the names of modules that can mutate finals in m1/p1 Suggestion: // the names of modules that are allowed to mutate finals in m1/p1 test/jdk/java/lang/reflect/Field/mutateFinals/modules/m1/p1/TestMain.java line 88: > 86: return mutators.stream(); > 87: } > 88: } You can consider populating `mutators` and `deniedMutators` in `setup()` using a single loop. This would result in less LoC and render `allowedToMutate` field redundant. test/jdk/java/lang/reflect/Field/mutateFinals/modules/m1/p1/TestMain.java line 105: > 103: var obj = new C(oldValue); > 104: > 105: f.setAccessible(false); Shouldn't we avoid tampering the defaults with `f.setAccessible(false)` while validating the default IAE throw? test/micro/org/openjdk/bench/java/lang/reflect/FieldSet.java line 1: > 1: /* Do we need to extend the benchmark cases for a `static` field, VH, and MH too? test/micro/org/openjdk/bench/java/lang/reflect/FieldSet.java line 110: > 108: @Benchmark > 109: public void setNonFinalLongField() throws Exception { > 110: long newValue = ThreadLocalRandom.current().nextLong(); Double-checking: `ThreadLocalRandom.current().nextLong()` would not eclipse the timing of the subject setter, right? ------------- PR Review: https://git.openjdk.org/jdk/pull/25115#pullrequestreview-3272168187 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2387330308 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2389003505 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2389008777 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2389011029 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2389026675 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2389031363 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2387254039 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2387261330 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2387272585 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2387276982 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2387281666 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2389067367 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2387438980 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2387406182 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2387407350 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2387410454 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2387427536 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2389069905 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2389070187 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2388859285 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2388872897 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2389077443 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2388887478 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2388946831 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2388929369 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2388925794 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2388955439 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2389062409 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2389091791 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2389089796 From vyazici at openjdk.org Tue Sep 30 07:31:44 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 30 Sep 2025 07:31:44 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v2] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 18:03:54 GMT, Alan Bateman wrote: >> Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500). >> >> Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP. >> >> HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX). >> >> There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package. >> >> Testing: tier1-6 > > Alan Bateman has updated the pull request incrementally with two additional commits since the last revision: > > - Review feedback > - Change ciField::initialize_from to use is_mutable_static_final, suggested by Vladimir Ivanov test/hotspot/jtreg/runtime/jni/mutateFinals/MutateFinalsTest.java line 109: > 107: String instanceMethod = list1.get(rand.nextInt(list1.size())); > 108: String staticMethod = list2.get(rand.nextInt(list2.size())); > 109: return Stream.of(instanceMethod, staticMethod); * What is the rationale for choosing a random `pairOf(instanceMutator, classMutator)`? * Does "instance mutator gets followed by a class mutator" have any particular importance for the tests they are used? I was looking at this argument supplier and thinking of `Collections.shuffle()` over a list containing all method names, preferably, multiple times. test/hotspot/jtreg/runtime/jni/mutateFinals/MutateFinalsTest.java line 142: > 140: private OutputAnalyzer test(String methodName, String... vmopts) throws Exception { > 141: Stream s1 = Stream.of( > 142: "-Djava.library.path=" + javaLibraryPath, `javaLibraryPath` is only used here. You can consider inlining `System::getProperty` here and saving yourself from lines 51..56. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2382369054 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2382360896 From stefank at openjdk.org Tue Sep 30 07:39:27 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 30 Sep 2025 07:39:27 GMT Subject: RFR: 8367013: Add Atomic to package/replace idiom of volatile var plus AtomicAccess:: operations In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 11:45:51 GMT, Kim Barrett wrote: > I assume you mean load_acquire - there is no load_release. I was more likely thinking about the store variants, but got tangled up in my rewrites of the comment above. :( ------------- PR Comment: https://git.openjdk.org/jdk/pull/27539#issuecomment-3350412927 From thartmann at openjdk.org Tue Sep 30 07:52:41 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 30 Sep 2025 07:52:41 GMT Subject: RFR: 8360389: Support printing from C2 compiled code [v11] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 15:06:51 GMT, Beno?t Maillard wrote: >> This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types. >> >> ## Usage >> >> Suppose we have this piece of Java code, that simply computes an arithmetic operation, and >> that we compile `square` with C2. >> >> class Square { >> static int square(int a) { >> return a * a; >> } >> >> public static void main(String[] args) { >> square(9); >> } >> } >> >> >> We would like to inspect the node that contains the value returned in this method. >> We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect. >> >> ```c++ >> void Compile::return_values(JVMState* jvms) { >> GraphKit kit(jvms); >> Node* ret = new ReturnNode(TypeFunc::Parms, >> kit.control(), >> kit.i_o(), >> kit.reset_memory(), >> kit.frameptr(), >> kit.returnadr()); >> // Add zero or 1 return values >> int ret_size = tf()->range()->cnt() - TypeFunc::Parms; >> >> >> Node* return_value; >> if (ret_size > 0) { >> kit.inc_sp(-ret_size); // pop the return value(s) >> kit.sync_jvms(); >> return_value = kit.argument(0); >> ret->add_req(return_value); >> >> // <-------------------- Simply insert this >> C->make_debug_print("return: ", initial_gvn(), return_value); >> } >> >> // bind it to root >> root()->add_req(ret); >> record_for_igvn(ret); >> initial_gvn()->transform(ret); >> } >> >> >> We can then call run our code with `-XX:CompileCommand="compileonly,Square::square` >> and we get the following output: >> >> >> return: >> int 81 >> >> >> This case is of course trivial, but more useful examples are shown later. >> >> ## Implementation >> >> The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed. >> >> The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the ... > > Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision: > > Remove implicit null check This looks good to me and will be handy for future printf-style debugging in compiled code. I could have made good use of this on several occasions in the past. Nice examples! src/hotspot/share/opto/compile.cpp line 5444: > 5442: Node* str_node = gvn->transform(new ConPNode(TypeRawPtr::make(((address) str)))); > 5443: const TypeFunc* type = OptoRuntime::debug_print_Type(parm0, parm1, parm2, parm3, parm4, parm5, parm6); > 5444: Node *call = new CallLeafNode(type, call_addr, "debug_print", TypeRawPtr::BOTTOM); Suggestion: Node* call = new CallLeafNode(type, call_addr, "debug_print", TypeRawPtr::BOTTOM); ------------- Marked as reviewed by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26475#pullrequestreview-3283055434 PR Review Comment: https://git.openjdk.org/jdk/pull/26475#discussion_r2390190807 From alanb at openjdk.org Tue Sep 30 08:11:21 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 30 Sep 2025 08:11:21 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v2] In-Reply-To: References: Message-ID: On Fri, 26 Sep 2025 13:02:57 GMT, Volkan Yazici wrote: >> Alan Bateman has updated the pull request incrementally with two additional commits since the last revision: >> >> - Review feedback >> - Change ciField::initialize_from to use is_mutable_static_final, suggested by Vladimir Ivanov > > test/hotspot/jtreg/runtime/jni/mutateFinals/MutateFinalsTest.java line 109: > >> 107: String instanceMethod = list1.get(rand.nextInt(list1.size())); >> 108: String staticMethod = list2.get(rand.nextInt(list2.size())); >> 109: return Stream.of(instanceMethod, staticMethod); > > * What is the rationale for choosing a random `pairOf(instanceMutator, classMutator)`? > * Does "instance mutator gets followed by a class mutator" have any particular importance for the tests they are used? > > I was looking at this argument supplier and thinking of `Collections.shuffle()` over a list containing all method names, preferably, multiple times. The comment in the test description has ".. to avoid starting a child VM to test every mutation method". I'll see if I can improve this comment to make it clearer, or maybe your comment is that the method source needs this comment too? The context here is that the test is launching a VM with -Xcheck:jni to check that it terminates with a "FATAL ERROR in native method". Doing this for each of 18 cases would be expensive, can be 30+ seconds on macOS systems with debug builds. To keep the test execution down, the test choses one JNI function that attempts to mutate a final instance field, and one JNI function that attempts to mutate a static final field. The ensures the instance + static implementations are tested on each run. There is template expansion, and all functions will get exercised with enough runs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2390255811 From alanb at openjdk.org Tue Sep 30 08:15:43 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 30 Sep 2025 08:15:43 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v4] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 09:42:00 GMT, Volkan Yazici wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> RemoveFields(duration) and filter internal frames > > src/hotspot/share/runtime/arguments.cpp line 2281: > >> 2279: } >> 2280: } else if (match_option(option, "--illegal-final-field-mutation=", &tail)) { >> 2281: if (strcmp(tail, "allow") == 0 || strcmp(tail, "warn") == 0 || strcmp(tail, "debug") == 0 || strcmp(tail, "deny") == 0) { > > Is the `jdk.module.illegal.final.field.mutation` property intended as a public API? If so, where is it documented? System properties are used to "communicate" the value of options from the VM to the library code. All internal/undocumented. There is a test in mutateFinal/cli/CommandLineTests.java that checks that specifying the system property on the command line is not effective. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2390266998 From alanb at openjdk.org Tue Sep 30 08:24:14 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 30 Sep 2025 08:24:14 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v4] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 18:35:29 GMT, Volkan Yazici wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> RemoveFields(duration) and filter internal frames > > test/jdk/java/lang/reflect/Field/mutateFinals/modules/m1/p1/Mutator.java line 36: > >> 34: void setInt(Field f, Object obj, short value) throws IllegalAccessException; >> 35: void setInt(Field f, Object obj, int value) throws IllegalAccessException; >> 36: void setLong(Field f, Object obj, long value) throws IllegalAccessException; > > Is > > void setInt(..., short value) > > used at all? If so, > > 1. Where? > 2. Do we also need the following? > > setLong(..., short value) > setLong(..., int value) > setDouble(..., float value) Well spotted, there should be only one setInt method in this interface, the setInt(... short) method is not used. (The test is cross-module access checking so is not concerned with conversions). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2390303198 From alanb at openjdk.org Tue Sep 30 08:27:19 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 30 Sep 2025 08:27:19 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v4] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 19:16:39 GMT, Volkan Yazici wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> RemoveFields(duration) and filter internal frames > > test/jdk/java/lang/reflect/Field/mutateFinals/FinalFieldMutationEventTest.java line 1: > >> 1: /* > > Do we need to extend the cases for a `static` field? You can't reflectively set a static final field so there is no JFR event. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2390315392 From vyazici at openjdk.org Tue Sep 30 08:47:41 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 30 Sep 2025 08:47:41 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v2] In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 08:08:09 GMT, Alan Bateman wrote: >> test/hotspot/jtreg/runtime/jni/mutateFinals/MutateFinalsTest.java line 109: >> >>> 107: String instanceMethod = list1.get(rand.nextInt(list1.size())); >>> 108: String staticMethod = list2.get(rand.nextInt(list2.size())); >>> 109: return Stream.of(instanceMethod, staticMethod); >> >> * What is the rationale for choosing a random `pairOf(instanceMutator, classMutator)`? >> * Does "instance mutator gets followed by a class mutator" have any particular importance for the tests they are used? >> >> I was looking at this argument supplier and thinking of `Collections.shuffle()` over a list containing all method names, preferably, multiple times. > > The comment in the test description has ".. to avoid starting a child VM to test every mutation method". I'll see if I can improve this comment to make it clearer, or maybe your comment is that the method source needs this comment too? > > The context here is that the test is launching a VM with -Xcheck:jni to check that it terminates with a "FATAL ERROR in native method". Doing this for each of 18 cases would be expensive, can be 30+ seconds on macOS systems with debug builds. To keep the test execution down, the test choses one JNI function that attempts to mutate a final instance field, and one JNI function that attempts to mutate a static final field. The ensures the instance + static implementations are tested on each run. There is template expansion, and all functions will get exercised with enough runs. I was curious why in particular `instance+static`, but not, say, `static+instance`, or `static1+instance1+static2+static3+instance3`, etc. That is, does checking the static field *after* the instance field have any significance. But AFAIU from your explanation, it does not. I don't have any further remarks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2390371924 From tschatzl at openjdk.org Tue Sep 30 08:48:44 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 30 Sep 2025 08:48:44 GMT Subject: RFR: 8363932: G1: Better distribute KlassCleaningTask [v2] In-Reply-To: References: <4wv4YEc8jXOrh142RF4lbiAOx5HSEe8tcDc-BYQC-5I=.461e968b-21dd-493e-9dfb-dcc9f962700a@github.com> Message-ID: On Mon, 29 Sep 2025 20:36:35 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> * ayang review > > Marked as reviewed by ayang (Reviewer). Thanks @albertnetymk @coleenp for your reviews ------------- PR Comment: https://git.openjdk.org/jdk/pull/27316#issuecomment-3350740673 From tschatzl at openjdk.org Tue Sep 30 08:51:55 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 30 Sep 2025 08:51:55 GMT Subject: Integrated: 8363932: G1: Better distribute KlassCleaningTask In-Reply-To: <4wv4YEc8jXOrh142RF4lbiAOx5HSEe8tcDc-BYQC-5I=.461e968b-21dd-493e-9dfb-dcc9f962700a@github.com> References: <4wv4YEc8jXOrh142RF4lbiAOx5HSEe8tcDc-BYQC-5I=.461e968b-21dd-493e-9dfb-dcc9f962700a@github.com> Message-ID: <46A0boaLdRkCJRykJbOKjkjYQtPEtq2AA6b6lJvSLS4=.7c79f287-81b7-421b-a45c-906b50eef65c@github.com> On Tue, 16 Sep 2025 15:54:19 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to parallel klass cleaning to improve performance. > > The current implementation only parallelizes cleaning of weak class links, while the main work, cleaning the object tree is single-threaded. Hence in practice, the current mechanism does not scale beyond 2-3 threads. > > Cleaning an object graph in an application that loads some jars and instantiates central classes within them, with around 180k classes the current `G1 Complete Cleaning` task (which executes this code) can take 80ms (with 25 threads). > > The suggested change is to walk the object graph by (live) `ClassLoaderData` klass by klass, fixing only the links of that particular klass. > > E.g. > > CLD1 has klasses A, B, C, CLD2 has klasses a, b, c and CLD3 has klasses 0, 1, 2, 4; > vertical links are subklass references, while horizontal links are sibling references. > > j.l.O > | > A - B - c - 3 > | > 0 - 2 - C - 1 > > > CLD 3 is dead. Thread 1 claims CLD 1, Thread 2 claims CLD 2 (and nobody claims CLD3 because it's dead). > > So thread 1, when reaching `A` fixes its subklass link to `C`, and otherwise does nothing with `A`. When looking at `C`, it will remove the link to `1`. > Thread 2 will only remove the link to `3` of `c`. > > The result is > > j.l.O > | > A - B - c > | > C > > > There should be no unnecessary object graph walking. > > There is a slight change in printing during unlinking: previously the code, when cleaning subklasses it printed `unlinking class (subclass)`for every class that has been removed on the way to the next live one. In above case, it would print > > > unlinking class (subclass): 0 > unlinking class (subclass): 2 > > > With the change, to avoid following the subklasses of the graph twice, it prints > > > ?unlinking class (subclass): 0 > unlinking class (sibling): 0 > > > because the string in brackets is the actual link that is followed. I can revert that change. > > With the change "Complete Cleaning" time for 200k classes takes 7.6ms (The test is a bit random on when it does the class unloading). > > Testing: tier1-5 > > Thanks, > Thomas This pull request has now been integrated. Changeset: 586167cf Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/586167cff5aaead0949c509f48bc5080834cc362 Stats: 116 lines in 7 files changed: 6 ins; 61 del; 49 mod 8363932: G1: Better distribute KlassCleaningTask Reviewed-by: ayang, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/27316 From alanb at openjdk.org Tue Sep 30 08:56:03 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 30 Sep 2025 08:56:03 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v2] In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 08:44:45 GMT, Volkan Yazici wrote: >> The comment in the test description has ".. to avoid starting a child VM to test every mutation method". I'll see if I can improve this comment to make it clearer, or maybe your comment is that the method source needs this comment too? >> >> The context here is that the test is launching a VM with -Xcheck:jni to check that it terminates with a "FATAL ERROR in native method". Doing this for each of 18 cases would be expensive, can be 30+ seconds on macOS systems with debug builds. To keep the test execution down, the test choses one JNI function that attempts to mutate a final instance field, and one JNI function that attempts to mutate a static final field. The ensures the instance + static implementations are tested on each run. There is template expansion, and all functions will get exercised with enough runs. > > I was curious why in particular `instance+static`, but not, say, `static+instance`, or `static1+instance1+static2+static3+instance3`, etc. That is, does checking the static field *after* the instance field have any significance. But AFAIU from your explanation, it does not. I don't have any further remarks. Right, the ordering doesn't matter it has to launch a new VM for each -Xcheck:jni test (necessary because the terminates with a fatal error when attempting to mutate a final field). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2390395915 From duke at openjdk.org Tue Sep 30 09:02:39 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 30 Sep 2025 09:02:39 GMT Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time In-Reply-To: References: Message-ID: <-vYR7lb41d_yoyG72ApZMuHpTNY8nTDW33m_0O04NVg=.8ee6f963-446a-4116-9f80-4c1fe37eb3d3@github.com> On Tue, 30 Sep 2025 04:29:40 GMT, Bernd wrote: >> Hi all, >> >> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding. >> >> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem. >> >> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM. >> >> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug. > > src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 282: > >> 280: * >> 281: * @return the total CPU time for all garbage collection >> 282: * threads in nanoseconds. > > Not sure did I miss the discussion, other methods like getTotalCompilationTime() return millis, is it ok or required to use new units here? It is indeed unfortunate that methods mix units but we are complementing, `OperatingSystemMXBean.getProcessCpuTime()` which returns nanoseconds. > test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java line 73: > >> 71: while (true) { >> 72: long gcCpuTimeFromThread = mxMemoryBean.getGcCpuTime(); >> 73: if (gcCpuTimeFromThread < -1) { > > None of the tests actually test if it is ever != -1 or if it is monotonically increasing or under which conditions (go? Platform? Build flags?) it is unsupported? The reason why there is no test for that is because `-1` is a valid return value. If this test is run on a system that does not support CPU time from os or if it queried during shutdown when we are terminating threads we opt to return `-1` for safety reasons. We cannot assume that OpenJDK is never run on a platform that does not support certain optional `os` implementations. The goal with this test is to verify the shutdown protection and the API. Additionally, since this API is piggybacking on other methods (effectively in `os`) that are actually responsible for the CPU time functionality, I believe they would be responsible implement tests for what you suggest. FWIW; I had a quick look and the tests that you are expecting might already be found in e.g. `test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/ThreadMonitor.java`, `vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001/TestDescription.java` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2390416360 PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2390406537 From mli at openjdk.org Tue Sep 30 09:06:23 2025 From: mli at openjdk.org (Hamlin Li) Date: Tue, 30 Sep 2025 09:06:23 GMT Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 03:03:04 GMT, Fei Yang wrote: > Hi, You need merge and rebase :-) Thanks for reminding :) I think my forked master needs to be adjusted in some way, as seems I previously accidently pushed some commit to master instead of branch, I'll figure out it later. > But the order of the detection of these extesions (the order in `RiscvHwprobe::add_features_from_query_result()`) still matters, right? Say we must detect `ext_v` before `ext_Zvbb`. Yes, you're right. But seems previous way (assert introduced in https://github.com/openjdk/jdk/pull/24094) does not work as expected, I moved ext_V below other ext_Zv ones, the assert was not triggerred, it's verified in a commit before (https://github.com/openjdk/jdk/pull/27152, https://github.com/openjdk/jdk/pull/27171), check below for a simple patch. I'll do more investigation and find out a way to catch the out of order detections in another PR. diff --git a/src/hotspot/cpu/riscv/vm_version_riscv.hpp b/src/hotspot/cpu/riscv/vm_version_riscv.hpp index a0a42fb5463..17e9635d0b6 100644 --- a/src/hotspot/cpu/riscv/vm_version_riscv.hpp +++ b/src/hotspot/cpu/riscv/vm_version_riscv.hpp @@ -169,7 +169,6 @@ class VM_Version : public Abstract_VM_Version { decl(ext_C , "c" , ('C' - 'A'), true , UPDATE_DEFAULT(UseRVC)) \ decl(ext_Q , "q" , ('Q' - 'A'), true , NO_UPDATE_DEFAULT) \ decl(ext_H , "h" , ('H' - 'A'), true , NO_UPDATE_DEFAULT) \ - decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \ decl(ext_Zicbom , "Zicbom" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbom)) \ decl(ext_Zicboz , "Zicboz" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicboz)) \ decl(ext_Zicbop , "Zicbop" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbop)) \ @@ -193,6 +192,7 @@ class VM_Version : public Abstract_VM_Version { decl(ext_Zvbc , "Zvbc" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvbc, ext_V)) \ decl(ext_Zvfh , "Zvfh" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvfh, ext_V)) \ decl(ext_Zvkn , "Zvkn" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvkn, ext_V)) \ + decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \ decl(ext_Zicond , "Zicond" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicond)) \ decl(mvendorid , "VendorId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \ decl(marchid , "ArchId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \ ------------- PR Comment: https://git.openjdk.org/jdk/pull/27562#issuecomment-3350827288 From duke at openjdk.org Tue Sep 30 09:11:49 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 30 Sep 2025 09:11:49 GMT Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 04:21:44 GMT, Bernd wrote: >> Hi all, >> >> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding. >> >> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem. >> >> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM. >> >> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug. > > src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 273: > >> 271: * Returns the CPU time used by all garbage collection threads. >> 272: * >> 273: *

This include time since genesis, so the value can be > > The ?so the? is not too obvious to me. Maybe simplify it a bit ?This includes time since genesis and counts activities even before the first collection cycle.?? Thanks @ecki for pointing that out :) I make a simplification whenever the CSR discussion (https://bugs.openjdk.org/browse/JDK-8368529) have reached a consensus where this method should live. > src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 279: > >> 277: * deduplication thread (if enabled). This method returns >> 278: * {@code -1} if the platform does not support this operation >> 279: * or if called during shutdown. > > Can we explicitly state here that this is concurrent time as well as worker time spent during pauses but not accumulated pause times? Just want to ensure that I read this correct, please correct any mistake below: * concurrent time = `CPU time` * accumulate times = `wall-clock time` Is your suggestion that we should clarify that the method may only account for `CPU time` and not `wall-clock time` during pauses? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2390466153 PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2390453810 From alanb at openjdk.org Tue Sep 30 09:13:01 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 30 Sep 2025 09:13:01 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v4] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 09:24:22 GMT, Volkan Yazici wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> RemoveFields(duration) and filter internal frames > > test/jdk/java/lang/reflect/Field/mutateFinals/cli/CommandLineTest.java line 190: > >> 188: @Test >> 189: void testLastOneWins() throws Exception { >> 190: test("testFieldSetInt", "--illegal-final-field-mutation=allow", "--illegal-final-field-mutation=deny") > > This tests `setProperty+Defaults`. Shall we also test `setProperty+vmOpt`? It wouldn't do any harm to have this test exercise another combination. The simplest one to add is where the winner specifies "warn" or "debug" as the output can be checked. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2390468743 From duke at openjdk.org Tue Sep 30 09:18:12 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 30 Sep 2025 09:18:12 GMT Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time In-Reply-To: References: Message-ID: On Sat, 27 Sep 2025 11:18:58 GMT, Jonas Norlinder wrote: > Hi all, > > This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding. > > `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem. > > FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM. > > Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug. Thanks @kevinjwalls for your review. I will update the order in `jmm.h` whenever we have reached a consensus in the CSR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3350875133 From duke at openjdk.org Tue Sep 30 09:22:18 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 30 Sep 2025 09:22:18 GMT Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 04:35:46 GMT, Bernd wrote: > Thanks, it?s a useful function @ecki That's great to hear ?! Thanks for taking your time to go through this and provide feedback/comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3350891366 From duke at openjdk.org Tue Sep 30 09:22:20 2025 From: duke at openjdk.org (Bernd) Date: Tue, 30 Sep 2025 09:22:20 GMT Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time In-Reply-To: References: Message-ID: <2OpfdNirFyJ5McqqMwVXNgb4-pmc3SHGxoymu8_bHs4=.18923437-25ec-48f0-8828-d13e30bd5dd7@github.com> On Tue, 30 Sep 2025 09:06:48 GMT, Jonas Norlinder wrote: >> src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 279: >> >>> 277: * deduplication thread (if enabled). This method returns >>> 278: * {@code -1} if the platform does not support this operation >>> 279: * or if called during shutdown. >> >> Can we explicitly state here that this is concurrent time as well as worker time spent during pauses but not accumulated pause times? > > Just want to ensure that I read this correct, please correct any mistake below: > > * concurrent time = `CPU time` > * accumulate times = `wall-clock time` > > Is your suggestion that we should clarify that the method may only account for `CPU time` and not `wall-clock time` during pauses? It?s mostly about making clear it?s Not a measurement for pause time (no matter if wall clock or per thread), dont know how to best Formulate it. I think it?s needed sind typically pause times have been associated with GRC thread Timings. Maybe something like ?the accounted CPU time can be spent concurrently with application threads or during pauses? or something Like that? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2390505263 From duke at openjdk.org Tue Sep 30 09:28:25 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 30 Sep 2025 09:28:25 GMT Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time In-Reply-To: <2OpfdNirFyJ5McqqMwVXNgb4-pmc3SHGxoymu8_bHs4=.18923437-25ec-48f0-8828-d13e30bd5dd7@github.com> References: <2OpfdNirFyJ5McqqMwVXNgb4-pmc3SHGxoymu8_bHs4=.18923437-25ec-48f0-8828-d13e30bd5dd7@github.com> Message-ID: On Tue, 30 Sep 2025 09:19:28 GMT, Bernd wrote: >> Just want to ensure that I read this correct, please correct any mistake below: >> >> * concurrent time = `CPU time` >> * accumulate times = `wall-clock time` >> >> Is your suggestion that we should clarify that the method may only account for `CPU time` and not `wall-clock time` during pauses? > > It?s mostly about making clear it?s Not a measurement for pause time (no matter if wall clock or per thread), dont know how to best Formulate it. I think it?s needed sind typically pause times have been associated with GRC thread Timings. Maybe something like ?the accounted CPU time can be spent concurrently with application threads or during pauses? or something Like that? In the CSR discussion I proposed changing the method name to `getTotalGcCpuTime()` as @kevinjwalls raised concerns about conflating it with per generation CPU timings. Would the renaming to `getTotalGcCpuTime()` also solve your concern here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2390533951 From mli at openjdk.org Tue Sep 30 09:32:28 2025 From: mli at openjdk.org (Hamlin Li) Date: Tue, 30 Sep 2025 09:32:28 GMT Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS [v2] In-Reply-To: References: Message-ID: > Hi, > Can you help to review the patch? > > This patch cleans up RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS, as discussed https://github.com/openjdk/jdk/pull/27152#discussion_r2367109820: > * reorder flags in alphabetic order for RV_EXT_FEATURE_FLAGS > * move comments close to feature declaration for RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS > > We also discussed (https://github.com/openjdk/jdk/pull/27171#discussion_r2387195562) the assert introduced in https://github.com/openjdk/jdk/pull/24094, previously we think this will restrict the flags order in RV_EXT_FEATURE_FLAGS, but I found out that this assert (is not necessary, so we should be able to order flags in RV_EXT_FEATURE_FLAGS in any way we'd like to) does not work as expected, will fix this in another pr. > > Thanks! Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - merge master - Merge branch 'openjdk:master' into master - initial commit - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - ... and 1 more: https://git.openjdk.org/jdk/compare/c0a4c0ba...247b63d9 ------------- Changes: https://git.openjdk.org/jdk/pull/27562/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27562&range=01 Stats: 105 lines in 1 file changed: 45 ins; 49 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/27562.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27562/head:pull/27562 PR: https://git.openjdk.org/jdk/pull/27562 From egahlin at openjdk.org Tue Sep 30 09:34:44 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 30 Sep 2025 09:34:44 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing [v9] In-Reply-To: References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> Message-ID: <3HaxpHnrD03IwGt4i_7sHtJOBKzAeKiYXjoprxlO2wM=.171690a4-b55d-49ce-9a1c-f5090940638d@github.com> On Tue, 23 Sep 2025 15:02:51 GMT, Johannes Bechberger wrote: >> This change hopefully fixes the test failures by making the test cases more resilient. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Fix build issue Thanks for adding vm.flagless. The other changes are better reviewed by those more familiar with the code introduced in JEP 509. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27293#issuecomment-3350952789 From duke at openjdk.org Tue Sep 30 09:41:26 2025 From: duke at openjdk.org (Bernd) Date: Tue, 30 Sep 2025 09:41:26 GMT Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time In-Reply-To: <-vYR7lb41d_yoyG72ApZMuHpTNY8nTDW33m_0O04NVg=.8ee6f963-446a-4116-9f80-4c1fe37eb3d3@github.com> References: <-vYR7lb41d_yoyG72ApZMuHpTNY8nTDW33m_0O04NVg=.8ee6f963-446a-4116-9f80-4c1fe37eb3d3@github.com> Message-ID: On Tue, 30 Sep 2025 08:58:54 GMT, Jonas Norlinder wrote: >> src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 282: >> >>> 280: * >>> 281: * @return the total CPU time for all garbage collection >>> 282: * threads in nanoseconds. >> >> Not sure did I miss the discussion, other methods like getTotalCompilationTime() return millis, is it ok or required to use new units here? > > It is indeed unfortunate that methods mix units but we are complementing, `OperatingSystemMXBean.getProcessCpuTime()` which returns nanoseconds. It?s in Both names - especially with the Description - understandable what it means, I was just afraid that people could confuse concepts. Maybe it doesn?t really matter. I think in the gc specific ones the colateral doc was a bit more specific about concurrent times and pauses, in the past. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2390586886 From mli at openjdk.org Tue Sep 30 09:42:44 2025 From: mli at openjdk.org (Hamlin Li) Date: Tue, 30 Sep 2025 09:42:44 GMT Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS [v2] In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 09:32:28 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review the patch? >> >> This patch cleans up RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS, as discussed https://github.com/openjdk/jdk/pull/27152#discussion_r2367109820: >> * reorder flags in alphabetic order for RV_EXT_FEATURE_FLAGS >> * move comments close to feature declaration for RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS >> >> We also discussed (https://github.com/openjdk/jdk/pull/27171#discussion_r2387195562) the assert introduced in https://github.com/openjdk/jdk/pull/24094, previously we think this will restrict the flags order in RV_EXT_FEATURE_FLAGS, but I found out that this assert (is not necessary, so we should be able to order flags in RV_EXT_FEATURE_FLAGS in any way we'd like to) does not work as expected, will fix this in another pr. >> >> Thanks! > > Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - merge master > - Merge branch 'openjdk:master' into master > - initial commit > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - ... and 1 more: https://git.openjdk.org/jdk/compare/c0a4c0ba...247b63d9 I'm also considering if we should remove the column ext_xx in RV_EXT_FEATURE_FLAGS, and the similar column in RV_NON_EXT_FEATURE_FLAGS in this pr, as it should be able to be generated from the pretty string. How do you think about it? The different opinions could be: * for RV_EXT_FEATURE_FLAGS, should we take for example `i` or `I` as pretty string? * for RV_NON_EXT_FEATURE_FLAGS, should we use `mvendorid` or `VendorId` as pretty string? let me know how do you think about it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27562#issuecomment-3350990571 From alanb at openjdk.org Tue Sep 30 09:57:02 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 30 Sep 2025 09:57:02 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v4] In-Reply-To: References: Message-ID: <1tTVxu7bHsI0WHxLZZftV1P1bKhDJgbhKPizUAv8rbs=.0f3d04e2-0ad0-4bf4-b81d-f1fd6e34def9@github.com> On Mon, 29 Sep 2025 18:26:40 GMT, Volkan Yazici wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> RemoveFields(duration) and filter internal frames > > test/jdk/java/lang/reflect/Field/mutateFinals/jni/JNIAttachMutator.java line 59: > >> 57: this.value = value; >> 58: } >> 59: } > > Do we need to extend this list with a copy of itself where `value` is static? This test is for the access check in Field.set when there is no Java caller. It's only applicable to final instance fields (can't mutate a static final with this API). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2390644652 From mli at openjdk.org Tue Sep 30 10:09:58 2025 From: mli at openjdk.org (Hamlin Li) Date: Tue, 30 Sep 2025 10:09:58 GMT Subject: RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS [v2] In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 09:32:28 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review the patch? >> >> This patch cleans up RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS, as discussed https://github.com/openjdk/jdk/pull/27152#discussion_r2367109820: >> * reorder flags in alphabetic order for RV_EXT_FEATURE_FLAGS >> * move comments close to feature declaration for RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS >> >> We also discussed (https://github.com/openjdk/jdk/pull/27171#discussion_r2387195562) the assert introduced in https://github.com/openjdk/jdk/pull/24094, previously we think this will restrict the flags order in RV_EXT_FEATURE_FLAGS, but I found out that this assert (is not necessary, so we should be able to order flags in RV_EXT_FEATURE_FLAGS in any way we'd like to) does not work as expected, will fix this in another pr. >> >> Thanks! > > Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - merge master > - Merge branch 'openjdk:master' into master > - initial commit > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - Merge branch 'openjdk:master' into master > - ... and 1 more: https://git.openjdk.org/jdk/compare/c0a4c0ba...247b63d9 I file https://bugs.openjdk.org/browse/JDK-8368950 to track the out of order declarations in RV_FEATURE_FLAGS. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27562#issuecomment-3351098223 From alanb at openjdk.org Tue Sep 30 10:11:08 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 30 Sep 2025 10:11:08 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v4] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 19:19:02 GMT, Volkan Yazici wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> RemoveFields(duration) and filter internal frames > > test/jdk/java/lang/reflect/Field/mutateFinals/FinalFieldMutationEventTest.java line 79: > >> 77: recording.enable(EVENT_NAME).withStackTrace(); >> 78: >> 79: boolean mutated = false; > > Instead of relying on `IAE` to be thrown as expected, you may consider passing `mutated` flag in `@run` (`-DwriteAccess`?) and using it to double-check the programmatically computed `mutated`. The test checks that an event is recorded when a final field is mutated (or unreflected on for setting), or that no event is recorded if not mutated. We could do as you suggest and also have it check if the mutation was expected or not but it would expand the scope and overlap with other tests. So I think it's okay as in. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2390702421 From alanb at openjdk.org Tue Sep 30 10:17:08 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 30 Sep 2025 10:17:08 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v4] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 19:29:21 GMT, Volkan Yazici wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> RemoveFields(duration) and filter internal frames > > test/jdk/java/lang/reflect/Field/mutateFinals/MutateFinalsTest.java line 33: > >> 31: * @run junit/othervm --illegal-final-field-mutation=debug -DwriteAccess=true MutateFinalsTest >> 32: * @run junit/othervm --illegal-final-field-mutation=deny -DwriteAccess=false MutateFinalsTest >> 33: */ > > Shall we also test the defaults too? > > Suggestion: > > * @run junit/othervm -DwriteAccess=true MutateFinalsTest > */ I didn't initially include that as the default has to be one of the 4 options that it already exercises. But you are right, we should add it in case the default could some result in different behavior, thanks for bringing it up. > test/jdk/java/lang/reflect/Field/mutateFinals/modules/m1/p1/TestMain.java line 105: > >> 103: var obj = new C(oldValue); >> 104: >> 105: f.setAccessible(false); > > Shouldn't we avoid tampering the defaults with `f.setAccessible(false)` while validating the default IAE throw? You are are right that the setAccessible(false) does nothing here but I think makes it clear that it is testing the scenario where access checks have not been suppressed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2390720820 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2390725922 From jbechberger at openjdk.org Tue Sep 30 10:18:15 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Tue, 30 Sep 2025 10:18:15 GMT Subject: RFR: 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing [v9] In-Reply-To: References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com> Message-ID: On Tue, 23 Sep 2025 15:02:51 GMT, Johannes Bechberger wrote: >> This change hopefully fixes the test failures by making the test cases more resilient. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Fix build issue Andrei has already reviewed. Maybe @jbachorik could rereview it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27293#issuecomment-3351139204 From alanb at openjdk.org Tue Sep 30 10:45:15 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 30 Sep 2025 10:45:15 GMT Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 01:33:23 GMT, David Holmes wrote: > I don't think this is appropriately placed in MemoryMXBean. I will discuss in the CSR request The CSR is probably a bit premature as this one is going to require seeing if the existing MXBeans are the best place for this (at least some of the original modelling assumed STW collectors) or whether a new management interface is needed. It will need think about whether should be a standard or JDK-specific API. Right now, the draft API spec makes it sounds very HotSpot VM specific. If added to an existing interface then it will need to be a default method and specifies to have default behavior when not implemented. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3351299156 From kevinw at openjdk.org Tue Sep 30 10:48:00 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 30 Sep 2025 10:48:00 GMT Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time In-Reply-To: References: <2OpfdNirFyJ5McqqMwVXNgb4-pmc3SHGxoymu8_bHs4=.18923437-25ec-48f0-8828-d13e30bd5dd7@github.com> Message-ID: <_q3wTgvwPMDMZn38MGoyw2pxM3Xf7zrhsNqG14Sw2VM=.95496553-d01e-4d89-99b4-4933d88be817@github.com> On Tue, 30 Sep 2025 09:25:24 GMT, Jonas Norlinder wrote: >> It?s mostly about making clear it?s Not a measurement for pause time (no matter if wall clock or per thread), dont know how to best Formulate it. I think it?s needed sind typically pause times have been associated with GRC thread Timings. Maybe something like ?the accounted CPU time can be spent concurrently with application threads or during pauses? or something Like that? > > In the CSR discussion I proposed changing the method name to `getTotalGcCpuTime()` as @kevinjwalls raised concerns about conflating it with per generation CPU timings. Would the renaming to `getTotalGcCpuTime()` also solve your concern here? Also, genesis (Universe::genesis()?), is a VM detail that may be unclear. Do we mean: " Returns the CPU time used by all garbage collection threads. This includes time for all driver threads, workers, VM operations on the VM thread, and the string deduplication thread (if enabled). Therefore the value can be non-zero even if no garbage collection cycles have occurred. This method returns {@code -1} if the platform does not support this operation, or if called during shutdown. " ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2390853215 From alanb at openjdk.org Tue Sep 30 10:52:50 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 30 Sep 2025 10:52:50 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v4] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 19:41:52 GMT, Volkan Yazici wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> RemoveFields(duration) and filter internal frames > > test/jdk/java/lang/reflect/Field/mutateFinals/modules/Driver.java line 30: > >> 28: * field is open to m2 and not open to m3. >> 29: * @build m1/* m2/* m3/* >> 30: * @run junit/othervm --illegal-final-field-mutation=allow -DallowedToMutate=m1,m2 m1/p1.TestMain > > Instead of an explicit `allow`, shall we use (and hence, stress) the defaults? > > Suggestion: > > * @run junit/othervm -DallowedToMutate=m1,m2 m1/p1.TestMain The default will allow or deny and these cases are tested. However, you are right that it wouldn't do any harm to have it run without options. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2390873380 From duke at openjdk.org Tue Sep 30 11:25:53 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 30 Sep 2025 11:25:53 GMT Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time In-Reply-To: References: Message-ID: <7wmf-1DUhidWeIJX6_A412wvVsxod9U2KOS-fxCPBIk=.5570ef04-e73d-47e8-8f1e-ff9f221f9e93@github.com> On Tue, 30 Sep 2025 10:41:41 GMT, Alan Bateman wrote: >> I don't think this is appropriately placed in MemoryMXBean. I will discuss in the CSR request > >> I don't think this is appropriately placed in MemoryMXBean. I will discuss in the CSR request > > The CSR is probably a bit premature as this one is going to require seeing if the existing MXBeans are the best place for this (at least some of the original modelling assumed STW collectors) or whether a new management interface is needed. > > It will need think about whether should be a standard or JDK-specific API. Right now, the draft API spec makes it sounds very HotSpot VM specific. > > If added to an existing interface then it will need to be a default method and specifies to have default behavior when not implemented. @AlanBateman > The CSR is probably a bit premature ... Sorry if I broke protocol (first time I submit a PR requiring a CSR). Are you saying that I should had sent out this suggestion on a mailing list for a pre-discussion before actually submitting the CSR? > Right now, the draft API spec makes it sounds very HotSpot VM specific. Could you elaborate on what makes this HotSpot VM specific? I think driver threads and workers are a generic concept but I do see your point that VM operations and string deduplication tends to be more HotSpot VM specific. Is that what you meant? I added these specific pointers in an effort to be helpful for a user to understand what parts the metric could include (but for actual details they would need to go to the VM implementation). To avoid being HotSpot VM specific I prefaced with "In general, ...". Should I remove these specialized pointers? > If added to an existing interface then it will need to be a default method and specifies to have default behavior when not implemented. Great point. Should have added a default behavior. Will include that in an updated PR (if we reach a consensus that we should add it to an existing interface). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3351513274 From mli at openjdk.org Tue Sep 30 11:34:14 2025 From: mli at openjdk.org (Hamlin Li) Date: Tue, 30 Sep 2025 11:34:14 GMT Subject: RFR: 8368950: RISC-V: fail to catch out of order declarations among dependent cpu extensions/flags Message-ID: Hi, Can you help to review this patch? ## Background In https://bugs.openjdk.org/browse/JDK-8352218, we introduced dependency among CPU extensions/flags. And to make sure it works, A needs to be declared before B in RV_FEATURE_FLAGS if B depends on A, for example, A is v, B is Zvfh. So in the pr an assert was introduced to make sure A is before B in RV_FEATURE_FLAGS. But the assert does not work as expected, means if I move A below B in RV_FEATURE_FLAGS (check below for a simple patch, it's based on 7853415217cc17179abf2e160ca735c936017f4e), it can not be caught by the assert. diff --git a/src/hotspot/cpu/riscv/vm_version_riscv.hpp b/src/hotspot/cpu/riscv/vm_version_riscv.hpp index 4214d6c53dc..80896f8fffc 100644 --- a/src/hotspot/cpu/riscv/vm_version_riscv.hpp +++ b/src/hotspot/cpu/riscv/vm_version_riscv.hpp @@ -169,7 +169,6 @@ class VM_Version : public Abstract_VM_Version { decl(ext_C , "c" , ('C' - 'A'), true , UPDATE_DEFAULT(UseRVC)) \ decl(ext_Q , "q" , ('Q' - 'A'), true , NO_UPDATE_DEFAULT) \ decl(ext_H , "h" , ('H' - 'A'), true , NO_UPDATE_DEFAULT) \ - decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \ decl(ext_Zicbom , "Zicbom" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbom)) \ decl(ext_Zicboz , "Zicboz" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicboz)) \ decl(ext_Zicbop , "Zicbop" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbop)) \ @@ -193,6 +192,7 @@ class VM_Version : public Abstract_VM_Version { decl(ext_Zvbc , "Zvbc" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvbc, ext_V)) \ decl(ext_Zvfh , "Zvfh" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvfh, ext_V)) \ decl(ext_Zvkn , "Zvkn" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvkn, ext_V)) \ + decl(ext_V , "v" , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \ decl(ext_Zicond , "Zicond" , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicond)) \ decl(mvendorid , "VendorId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \ decl(marchid , "ArchId" , RV_NO_FLAG_BIT, false, NO_UPDATE_DEFAULT) \ If added following patch based on the above patch, we can find out what's going on, it will trigger the assert: # Internal Error (/home/hamlin/workspace/repos/github/jdk-master-tmp-2/src/hotspot/cpu/riscv/vm_version_riscv.hpp:211), pid=430595, tid=430603 # assert((uintptr_t)(&ext_V) > (uintptr_t)(this)) failed: Invalid: dep: 140361453683696 (v), this: 140361453685240 (Zvbc) diff --git a/src/hotspot/cpu/riscv/vm_version_riscv.hpp b/src/hotspot/cpu/riscv/vm_version_riscv.hpp index 4214d6c53dc..0ba636dce96 100644 --- a/src/hotspot/cpu/riscv/vm_version_riscv.hpp +++ b/src/hotspot/cpu/riscv/vm_version_riscv.hpp @@ -90,8 +90,8 @@ class VM_Version : public Abstract_VM_Version { void update_flag() { \ assert(enabled(), "Must be."); \ /* dep must be declared before */ \ - assert((uintptr_t)(this) > \ - (uintptr_t)(&dep), "Invalid");\ + assert((uintptr_t)(&dep) > \ + (uintptr_t)(this), "Invalid: dep: %ld (%s), this: %ld (%s)", p2i(&dep), dep.pretty(), p2i(this), pretty()); \ if (FLAG_IS_DEFAULT(flag)) { \ if (dep.enabled()) { \ FLAG_SET_DEFAULT(flag, true); \ But I don't think we can rely on the address of different ext_x to determine their declaration order in RV_FEATURE_FLAGS, even if the patch above can catch it. ## Fix This patch reuses RVExtFeatureValue::_cpu_feature_index as dependent_index to check the declaration order is as expected. ## Test With the following patch, it will trigger the assert: # Internal Error (/home/hamlin/workspace/repos/github/jdk-master-aot/src/hotspot/cpu/riscv/vm_version_riscv.hpp:120), pid=708174, tid=708177 # assert(dependent_index() > next->dependent_index()) failed: Invalid diff --git a/src/hotspot/cpu/riscv/vm_version_riscv.hpp b/src/hotspot/cpu/riscv/vm_version_riscv.hpp index ae29bd36a10..8e602fb2413 100644 --- a/src/hotspot/cpu/riscv/vm_version_riscv.hpp +++ b/src/hotspot/cpu/riscv/vm_version_riscv.hpp @@ -277,7 +277,6 @@ class VM_Version : public Abstract_VM_Version { decl(ext_C , c , ('C' - 'A'), true , UPDATE_DEFAULT(UseRVC)) \ decl(ext_Q , q , ('Q' - 'A'), true , NO_UPDATE_DEFAULT) \ decl(ext_H , h , ('H' - 'A'), true , NO_UPDATE_DEFAULT) \ - decl(ext_V , v , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \ decl(ext_Zicbom , Zicbom , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbom)) \ decl(ext_Zicboz , Zicboz , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicboz)) \ decl(ext_Zicbop , Zicbop , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicbop)) \ @@ -301,6 +300,7 @@ class VM_Version : public Abstract_VM_Version { decl(ext_Zvbc , Zvbc , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvbc, &ext_V, nullptr)) \ decl(ext_Zvfh , Zvfh , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvfh, &ext_V, &ext_Zfh, nullptr)) \ decl(ext_Zvkn , Zvkn , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT_DEP(UseZvkn, &ext_V, nullptr)) \ + decl(ext_V , v , ('V' - 'A'), true , UPDATE_DEFAULT(UseRVV)) \ decl(ext_Zicond , Zicond , RV_NO_FLAG_BIT, true , UPDATE_DEFAULT(UseZicond)) \ Thanks! ------------- Commit messages: - initial commit - initial commit - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - ... and 1 more: https://git.openjdk.org/jdk/compare/c0a4c0ba...3205c38c Changes: https://git.openjdk.org/jdk/pull/27572/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27572&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368950 Stats: 34 lines in 1 file changed: 29 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27572.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27572/head:pull/27572 PR: https://git.openjdk.org/jdk/pull/27572 From alanb at openjdk.org Tue Sep 30 11:40:58 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 30 Sep 2025 11:40:58 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v4] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 19:01:28 GMT, Volkan Yazici wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> RemoveFields(duration) and filter internal frames > > test/jdk/java/lang/reflect/Field/mutateFinals/modules/m1/p1/TestMain.java line 88: > >> 86: return mutators.stream(); >> 87: } >> 88: } > > You can consider populating `mutators` and `deniedMutators` in `setup()` using a single loop. This would result in less LoC and render `allowedToMutate` field redundant. It doesn't really matter but it might be a bit cleaner to have "setup" locate/load the Mutators, then there would only be one place that uses ServiceLoader. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2391069760 From duke at openjdk.org Tue Sep 30 11:44:43 2025 From: duke at openjdk.org (Jonas Norlinder) Date: Tue, 30 Sep 2025 11:44:43 GMT Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time In-Reply-To: <_q3wTgvwPMDMZn38MGoyw2pxM3Xf7zrhsNqG14Sw2VM=.95496553-d01e-4d89-99b4-4933d88be817@github.com> References: <2OpfdNirFyJ5McqqMwVXNgb4-pmc3SHGxoymu8_bHs4=.18923437-25ec-48f0-8828-d13e30bd5dd7@github.com> <_q3wTgvwPMDMZn38MGoyw2pxM3Xf7zrhsNqG14Sw2VM=.95496553-d01e-4d89-99b4-4933d88be817@github.com> Message-ID: On Tue, 30 Sep 2025 10:45:27 GMT, Kevin Walls wrote: >> In the CSR discussion I proposed changing the method name to `getTotalGcCpuTime()` as @kevinjwalls raised concerns about conflating it with per generation CPU timings. Would the renaming to `getTotalGcCpuTime()` also solve your concern here? > > Also, genesis (Universe::genesis()?), is a VM detail that may be unclear. Do we mean: > " > Returns the CPU time used by all garbage collection threads. > > This includes time for all driver threads, workers, VM operations > on the VM thread, and the string deduplication thread (if enabled). > Therefore the value can be non-zero even if no garbage collection cycles have occurred. > > This method returns {@code -1} if the platform does not support this operation, or if called during shutdown. > " I meant genesis in the literal sense i.e. since thread creation not relating to `Universe::genesis`. It may be non-zero since each there may do some initialization work and thus CPU time would be non-zero. However given @AlanBateman comment about being HotSpot VM specific should we avoid talking about these specific details here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2391079350 From kevinw at openjdk.org Tue Sep 30 11:53:23 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 30 Sep 2025 11:53:23 GMT Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time In-Reply-To: References: <2OpfdNirFyJ5McqqMwVXNgb4-pmc3SHGxoymu8_bHs4=.18923437-25ec-48f0-8828-d13e30bd5dd7@github.com> <_q3wTgvwPMDMZn38MGoyw2pxM3Xf7zrhsNqG14Sw2VM=.95496553-d01e-4d89-99b4-4933d88be817@github.com> Message-ID: On Tue, 30 Sep 2025 11:41:58 GMT, Jonas Norlinder wrote: >> Also, genesis (Universe::genesis()?), is a VM detail that may be unclear. Do we mean: >> " >> Returns the CPU time used by all garbage collection threads. >> >> This includes time for all driver threads, workers, VM operations >> on the VM thread, and the string deduplication thread (if enabled). >> Therefore the value can be non-zero even if no garbage collection cycles have occurred. >> >> This method returns {@code -1} if the platform does not support this operation, or if called during shutdown. >> " > > I meant genesis in the literal sense i.e. since thread creation not relating to `Universe::genesis`. It may be non-zero since each there may do some initialization work and thus CPU time would be non-zero. However given @AlanBateman comment about being HotSpot VM specific should we avoid talking about these specific details here? "CPU time used by all garbage collection threads" or even "Accumulated CPU time..." would seem clear that we mean these threads, in this process. We can leave genesis out of it, whether it meant start of process or dawn of time. 8-) Yes, might be better as just, "This may include some startup work and overhead, therefore the value can be non-zero even...". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2391101498 From alanb at openjdk.org Tue Sep 30 12:40:47 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 30 Sep 2025 12:40:47 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v4] In-Reply-To: References: Message-ID: <1OsIi7Uhc9LLVO4yaVCan9KoOHUytGdXU7YVKTltW7U=.783dce5a-392f-4d56-9884-25743c383d52@github.com> On Mon, 29 Sep 2025 10:08:58 GMT, Volkan Yazici wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> RemoveFields(duration) and filter internal frames > > test/jdk/java/lang/reflect/Field/mutateFinals/jar/ExecutableJarTest.java line 110: > >> 108: */ >> 109: @Test >> 110: void testFieldSetWithAddOpens1() throws Exception { > > Suggestion: > > * with the Add-Opens attribute. This test uses --add-opens rather than the JAR file Add-Opens attributes so I think the comment is okay. > test/jdk/java/lang/reflect/Field/mutateFinals/jar/ExecutableJarTest.java line 129: > >> 127: void testFieldSetWithAddOpens2() throws Exception { >> 128: String jarFile = createExecutableJar(Map.of( >> 129: "Enable-Final-Field-Mutation", "ALL-UNNAMED", > > Instead of `BadValue`, shall we use a valid module name here to stress the following specification from the JEP: > >> The only supported value for the `Enable-Final-Field-Mutation` >> manifest entry is `ALL-UNNAMED`; other values cause an >> exception to be thrown. Okay, we can use a ValueSource here to have it test with a module name and other random strings. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2391269150 PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2391260982 From fbredberg at openjdk.org Tue Sep 30 12:44:11 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Tue, 30 Sep 2025 12:44:11 GMT Subject: RFR: 8367601: Remove held_monitor_count 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. ------------- Commit messages: - 8367601: Remove held_monitor_count Changes: https://git.openjdk.org/jdk/pull/27570/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27570&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367601 Stats: 385 lines in 25 files changed: 0 ins; 378 del; 7 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 Tue Sep 30 12:44:11 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Tue, 30 Sep 2025 12:44:11 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. @TheRealMDoerr, @RealFYang I've run rudimentary tests using QEMU, but it would be nice if you guys (or any of your friends) could take it for a spin on real hardware. Thanks in advance. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27570#issuecomment-3351884174 From alanb at openjdk.org Tue Sep 30 13:01:06 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 30 Sep 2025 13:01:06 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v4] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 10:09:44 GMT, Volkan Yazici wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> RemoveFields(duration) and filter internal frames > > test/jdk/java/lang/reflect/Field/mutateFinals/jar/ExecutableJarTest.java line 121: > >> 119: } >> 120: >> 121: /** > > Why don't we verify the output (i.e., no warnings) in this case? These two run with `--illegal-final-field-mutation=deny` and are testing that Enable-Final-Field-Mutation: ALL-UNNAMED is effective. They could also test that there aren't any warnings but this is secondary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2391342932 From alanb at openjdk.org Tue Sep 30 13:04:30 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 30 Sep 2025 13:04:30 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v4] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 19:47:45 GMT, Volkan Yazici wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> RemoveFields(duration) and filter internal frames > > test/micro/org/openjdk/bench/java/lang/reflect/FieldSet.java line 1: > >> 1: /* > > Do we need to extend the benchmark cases for a `static` field, and MH too? Field.set throws for static final fields so not worthing benchmrking. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25115#discussion_r2391358376 From mli at openjdk.org Tue Sep 30 13:26:03 2025 From: mli at openjdk.org (Hamlin Li) Date: Tue, 30 Sep 2025 13:26:03 GMT Subject: RFR: 8368722: RISC-V: Several vector load/store tests fail due to lack of support for misaligned vector access [v2] In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 03:01:10 GMT, Dingli Zhang wrote: >> Hi, >> Can you help to review this patch? Thanks! >> >> In `*VectorLoadStoreTests.java`, `loadMemorySegmentMaskIOOBE` and `storeMemorySegmentMaskIOOBE` may fail because `int index = fi.apply((int) a.byteSize())` can generate random indices that result in misaligned addresses, leading to SIGBUS on hardware that disallows misaligned vector accesses. >> >> Some RISC-V hardware supports fast misaligned scalar accesses but not vector ones, which causes SIGBUS when executing these tests with misaligned vector memory operations. >> >> After [JDK-8368732](https://bugs.openjdk.org/browse/JDK-8368732), we can use `AlignVector` to check the result on platforms with or without fast misaligned vector accesses. When misaligned vector accesses are not supported, it is possible to completely disable the VM?s VectorAPI support by setting `EnableVectorSupport`, without affecting auto-vectorization. >> >> In addition, after running fastdebug tests including `jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization`, we found that some IR-related tests require EnableVectorSupport. Therefore, we added `@requires vm.opt.EnableVectorSupport == true` to skip these tests. >> >> We can check the status of EnableVectorSupport as follows: >> >> On k1 >> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version >> [0.737s][info][compilation] EnableVectorSupport=false >> [0.738s][info][compilation] EnableVectorReboxing=false >> [0.738s][info][compilation] EnableVectorAggressiveReboxing=false >> >> On qemu >> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version >> [3.048s][info][compilation] EnableVectorSupport=true >> [3.050s][info][compilation] EnableVectorReboxing=true >> [3.051s][info][compilation] EnableVectorAggressiveReboxing=true >> >> >> ### Test (fastdebug) >> - [x] Run jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization on k1 > > Dingli Zhang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8368722: RISC-V: Several vector load/store tests fail without support for misaligned vector access src/hotspot/share/classfile/modules.cpp line 459: > 457: // Special handling of jdk.incubator.vector > 458: if (strcmp(module_name, "jdk.incubator.vector") == 0) { > 459: if (FLAG_IS_DEFAULT(EnableVectorSupport) RISCV64_ONLY(&& !AlignVector)) { I'm not quite sure, but seems this is not an issue only on riscv? It might be better to get more attention from other developers working on other platforms, could you modify the subject of this bug/pr? Sorry for previous suggestion to change the subject name. test/hotspot/jtreg/compiler/rangechecks/TestRangeCheckHoistingScaledIV.java line 33: > 31: * @requires vm.debug & vm.compiler2.enabled > 32: * @requires os.simpleArch == "x64" | os.arch == "aarch64" | (os.arch == "riscv64" & vm.cpu.features ~= ".*rvv.*") > 33: * @requires vm.opt.EnableVectorSupport == true BTW, I see more tests using jdk.incubator.vector besides of tests under test/hotspot/jtreg/compiler/vectorapi, like this test. Could they also face the similar issue? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27506#discussion_r2391436371 PR Review Comment: https://git.openjdk.org/jdk/pull/27506#discussion_r2391446846 From mdoerr at openjdk.org Tue Sep 30 13:35:28 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 30 Sep 2025 13:35:28 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. 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! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27570#issuecomment-3352190916 From tschatzl at openjdk.org Tue Sep 30 13:45:28 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 30 Sep 2025 13:45:28 GMT Subject: RFR: 8236073: G1: Use SoftMaxHeapSize to guide GC heuristics Message-ID: <8jjBh52pZlAjsLJ4ce1oacnDVdu8qCe2pJYApXsU5HM=.462adbdd-e3b7-4d4a-a130-aecadba36b00@github.com> Hi all, please review this change to implement `SoftMaxHeapSize` for G1. Main change is that `SoftMaxHeapSize` now impacts the `G1IHOPControl::target_occupancy()`, i.e. the amount of bytes G1 when reclaim should start. Most of the other changes are just about updating logging/JFR and making sure that the `SoftMaxHeapSize` values are consistent across calls. Testing: tier1-5 Thanks, Thomas ------------- Commit messages: - * add test showing that the GC responds to changes of the SoftMaxHeapSize variable - * some comment update for target_occupancy() - * fix gtests - * observe MinHeapSize for `G1CollectedHeap::soft_max_capacity()` - * updates - initial version Changes: https://git.openjdk.org/jdk/pull/27524/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27524&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8236073 Stats: 123 lines in 10 files changed: 82 ins; 4 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/27524.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27524/head:pull/27524 PR: https://git.openjdk.org/jdk/pull/27524 From aph at openjdk.org Tue Sep 30 13:47:25 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 30 Sep 2025 13:47:25 GMT Subject: RFR: 8328306: AArch64: MacOS lazy JIT "write xor execute" switching [v3] In-Reply-To: References: <3IdZZGAKHVuMXfeM10Z-VSDNlJmcu5XFilLQfEKb9OY=.5213f5ca-2bca-41eb-b7ce-7621510552be@github.com> <46wGhDJsIWHOyJnk-fwdcgBbQjUwqbGEs5yKH1Zm_sk=.64386c7e-15f4-40e7-a128-7b4c1adda63b@github.com> Message-ID: <9Ux-DS0epJG53wnO9lic6YLRb21HFhA0ncu5lNqXylw=.48c4cc57-eb88-48c6-b43f-fff42f0c7a7f@github.com> On Fri, 15 Aug 2025 01:09:18 GMT, Dean Long wrote: >> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp >> >> Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com> > > src/hotspot/share/runtime/javaCalls.cpp line 330: > >> 328: >> 329: JavaThread* thread = THREAD; >> 330: MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, THREAD)); > > JavaCallWrapper::JavaCallWrapper() is already calling enable_wx(WXExec), and JavaCallWrapper::~JavaCallWrapper() is calling enable_wx(WXWrite), so we have double coverage. Can we remove the calls from JavaCallWrapper and just keep this one, and maybe move it down closer to the StubRoutines::call_stub()? Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26562#discussion_r2391540275 From alanb at openjdk.org Tue Sep 30 14:36:06 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 30 Sep 2025 14:36:06 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v5] In-Reply-To: References: Message-ID: > Implementation changes for [JEP 500: Prepare to Make Final Mean Final](https://openjdk.org/jeps/500). > > Field.set (and Lookup.unreflectSetter) are changed to allow/warn/debug/deny when mutating a final instance field. JFR event recorded if final field mutated. Spec updates to Field.set, Field.setAccessible and Module.addOpens to align with the proposal in the JEP. > > HotSpot is updated to add support for the new command line options. To aid diagnosability, -Xcheck:jni reports a fatal error when a mutating a final field with JNI, and -Xlog:jni=debug can help identity when JNI code mutates finals. For now, JNI code is allowed to set the "write-protected" fields System.in/out/err, we can re-visit once we change the System.setIn/setOut/setErr methods to not use JNI (I prefer to keep this separate to this PR because there is a small startup regression to address when changing System.setXXX). > > There are many new tests. A small number of existing tests are changed to run /othervm as reflectively opening a package isn't sufficient. Changing the tests to /othervm means that jtreg will launch the agent with the command line options to open the package. > > Testing: tier1-6 Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: - Merge branch 'master' into JDK-8353835 - Test updates based on reviewer feedback - RemoveFields(duration) and filter internal frames - Merge branch 'master' into JDK-8353835 - Merge branch 'master' into JDK-8353835 - Improve setters and test cleanup - Merge branch 'master' into JDK-8353835 - Merge branch 'master' into JDK-8353835 - Review feedback - Change ciField::initialize_from to use is_mutable_static_final, suggested by Vladimir Ivanov - ... and 16 more: https://git.openjdk.org/jdk/compare/444007fc...abbb744c ------------- Changes: https://git.openjdk.org/jdk/pull/25115/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25115&range=04 Stats: 4600 lines in 61 files changed: 4423 ins; 54 del; 123 mod Patch: https://git.openjdk.org/jdk/pull/25115.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25115/head:pull/25115 PR: https://git.openjdk.org/jdk/pull/25115 From tschatzl at openjdk.org Tue Sep 30 14:56:03 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 30 Sep 2025 14:56:03 GMT Subject: RFR: 8236073: G1: Use SoftMaxHeapSize to guide GC heuristics [v2] In-Reply-To: <8jjBh52pZlAjsLJ4ce1oacnDVdu8qCe2pJYApXsU5HM=.462adbdd-e3b7-4d4a-a130-aecadba36b00@github.com> References: <8jjBh52pZlAjsLJ4ce1oacnDVdu8qCe2pJYApXsU5HM=.462adbdd-e3b7-4d4a-a130-aecadba36b00@github.com> Message-ID: > Hi all, > > please review this change to implement `SoftMaxHeapSize` for G1. > > Main change is that `SoftMaxHeapSize` now impacts the `G1IHOPControl::target_occupancy()`, i.e. the amount of bytes G1 when reclaim should start. > > Most of the other changes are just about updating logging/JFR and making sure that the `SoftMaxHeapSize` values are consistent across calls. > > Testing: tier1-5 > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * actually add test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27524/files - new: https://git.openjdk.org/jdk/pull/27524/files/cc240b6a..ec1ccb7f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27524&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27524&range=00-01 Stats: 138 lines in 2 files changed: 135 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27524.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27524/head:pull/27524 PR: https://git.openjdk.org/jdk/pull/27524 From mhaessig at openjdk.org Tue Sep 30 14:59:12 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Tue, 30 Sep 2025 14:59:12 GMT Subject: RFR: 8360389: Support printing from C2 compiled code [v11] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 15:06:51 GMT, Beno?t Maillard wrote: >> This PR adds support for printf-style debugging from C2 compiled code. This is implemented as a runtime call to a C++ method that prints the values of the nodes passed as arguments. The runtime C++ method is implemented with the help of variadic templates, as it is expected to support various combinations of argument types. >> >> ## Usage >> >> Suppose we have this piece of Java code, that simply computes an arithmetic operation, and >> that we compile `square` with C2. >> >> class Square { >> static int square(int a) { >> return a * a; >> } >> >> public static void main(String[] args) { >> square(9); >> } >> } >> >> >> We would like to inspect the node that contains the value returned in this method. >> We can add a call to `Compile::make_debug_print` and pass a message, the IGVN instance, as well as the node(s) that we would like to inspect. >> >> ```c++ >> void Compile::return_values(JVMState* jvms) { >> GraphKit kit(jvms); >> Node* ret = new ReturnNode(TypeFunc::Parms, >> kit.control(), >> kit.i_o(), >> kit.reset_memory(), >> kit.frameptr(), >> kit.returnadr()); >> // Add zero or 1 return values >> int ret_size = tf()->range()->cnt() - TypeFunc::Parms; >> >> >> Node* return_value; >> if (ret_size > 0) { >> kit.inc_sp(-ret_size); // pop the return value(s) >> kit.sync_jvms(); >> return_value = kit.argument(0); >> ret->add_req(return_value); >> >> // <-------------------- Simply insert this >> C->make_debug_print("return: ", initial_gvn(), return_value); >> } >> >> // bind it to root >> root()->add_req(ret); >> record_for_igvn(ret); >> initial_gvn()->transform(ret); >> } >> >> >> We can then call run our code with `-XX:CompileCommand="compileonly,Square::square` >> and we get the following output: >> >> >> return: >> int 81 >> >> >> This case is of course trivial, but more useful examples are shown later. >> >> ## Implementation >> >> The debugging capability is implemented as a runtime call to a C++ printing method. For this, `Compile::make_debug_print` inserts a `CallLeafNode` into the graph and rewires control flow as needed. >> >> The actual printing is handled by the `SharedRuntime::debug_print` method, written with a variadic template to support various argument type combinations. A pointer to this runtime method is obtained at compile time and is passed to the ... > > Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision: > > Remove implicit null check Looks good now. Thank you for the improvements. ------------- Marked as reviewed by mhaessig (Committer). PR Review: https://git.openjdk.org/jdk/pull/26475#pullrequestreview-3285436770 From alanb at openjdk.org Tue Sep 30 15:09:04 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 30 Sep 2025 15:09:04 GMT Subject: RFR: 8353835: Implement JEP 500: Prepare to Make Final Mean Final [v4] In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 07:28:50 GMT, Volkan Yazici wrote: > I've read the JEP, and reviewed the tests. I hope I manage to contribute meaningfully. @vy Thank you very much for your thorough review and walk through of all of the tests. You clearly spent a lot of time on this. I went through your comments and pushed an update [5acb1d727c5e0feee52c7a1f47665264eb534489]( https://github.com/openjdk/jdk/pull/25115/commits/5acb1d727c5e0feee52c7a1f47665264eb534489) to add more tests, improves some comments, and remove the unused setInt methods that you spotted in the x-module test. Many of the tests are focused on specific parts of the solution (APIs, access checks, CLI options, JAR file manifest, JNI, ...) and I've resisted going further with some of these tests to avoid too much overlap. You have rightly identified a few opportunities for more tests, e.g. JNI attached thread doing upcall to mutate a final field in named module as the tests only checks the unnamed module case right now. This are good suggestions but they require a good bit of setup, I'll try to get to it (or find someone) so that we have more tests before we are done. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3352650793 From rehn at openjdk.org Tue Sep 30 15:14:39 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 30 Sep 2025 15:14:39 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v7] In-Reply-To: References: Message-ID: > Hi please, consider. > > As ziccif require instructions to natural aligned to be atomic the 4 byte post call nop must be aligned. > But I don't want to add a c.nop(2b) to align the nop(4b) which means the jal(r) must also be algined. > As we have no utility to aligned the end of an instruction sequence the call it self is aligned and uses only 4 byte instructions. Only in the case where we could use an two c-instruction we may loose space. > > Thanks, Robbin Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge branch 'master' into align_post_nops - Merge branch 'master' into align_post_nops - Use relocation spec as marker. - Revert "Removed relocate for post call nops" This reverts commit 033ecd4ab3d62c1ccc7845d8bc9e62fc6574e05d. - Removed relocate for post call nops - Merge branch 'master' into align_post_nops - Review comments - init ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27467/files - new: https://git.openjdk.org/jdk/pull/27467/files/76c4f861..aedba042 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27467&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27467&range=05-06 Stats: 1972 lines in 99 files changed: 908 ins; 305 del; 759 mod Patch: https://git.openjdk.org/jdk/pull/27467.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27467/head:pull/27467 PR: https://git.openjdk.org/jdk/pull/27467 From rehn at openjdk.org Tue Sep 30 15:14:41 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 30 Sep 2025 15:14:41 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v6] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 13:30:44 GMT, Hamlin Li wrote: > I got another question, it' not a comment on this pr. > > In `nmethod::make_deoptimized`, it will only `make_deopt` virtual_call_type/static_call_type/opt_virtual_call_type. But in riscv.ad, `post_call_nop`s are appended to calls which are not virtual_call_type/static_call_type/opt_virtual_call_type, are all these `post_call_nop`s necessary? I don't think so, but I may be missing something. It needs to be investigated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27467#issuecomment-3352655180 From rehn at openjdk.org Tue Sep 30 15:14:44 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 30 Sep 2025 15:14:44 GMT Subject: RFR: 8367692: RISC-V: Align post call nop [v6] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 09:17:02 GMT, Robbin Ehn wrote: >> Hi please, consider. >> >> As ziccif require instructions to natural aligned to be atomic the 4 byte post call nop must be aligned. >> But I don't want to add a c.nop(2b) to align the nop(4b) which means the jal(r) must also be algined. >> As we have no utility to aligned the end of an instruction sequence the call it self is aligned and uses only 4 byte instructions. Only in the case where we could use an two c-instruction we may loose space. >> >> Thanks, Robbin > > Robbin Ehn 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 'master' into align_post_nops > - Use relocation spec as marker. > - Revert "Removed relocate for post call nops" > > This reverts commit 033ecd4ab3d62c1ccc7845d8bc9e62fc6574e05d. > - Removed relocate for post call nops > - Merge branch 'master' into align_post_nops > - Review comments > - init Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27467#issuecomment-3352674044 From lmesnik at openjdk.org Tue Sep 30 15:18:57 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 30 Sep 2025 15:18:57 GMT Subject: RFR: 8355631: The events might be generated after VM_DEATH event In-Reply-To: <9Pt3r-dYcnG_IOpxWynEIWfl4EF0ZQVVoQ1CHbstwRo=.ea9be3fe-1143-4615-a26d-8c51f0adbfc0@github.com> References: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com> <9Pt3r-dYcnG_IOpxWynEIWfl4EF0ZQVVoQ1CHbstwRo=.ea9be3fe-1143-4615-a26d-8c51f0adbfc0@github.com> Message-ID: On Tue, 30 Sep 2025 06:11:14 GMT, David Holmes wrote: >> The JVMTI spec says: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#VMDeath >> `The VM death event notifies the agent of the termination of the VM. No events will occur after the VMDeath event.` >> >> However, current implementation changes state and only after this start disabling events. >> >> It might be not a conformance issue, because there is no way to get thread state in the very beginning of event. >> The main practical issue is that currently certain events are generated when VM is becoming dead. So any function in event should check error against JVMTI_PHASE_DEAD. We can easily trigger it by running tests with enabled https://bugs.openjdk.org/browse/JDK-8352654 >> >> The proposed fix to disable all event generation and then post the last (VMDeath) event. After this event is completed change VM phase to death. It's guaranteed that no any events are generated after VMDeath completion. >> >> After this fix the VMDeath callback also can't generate any events. >> The alternative is to disable events posting after VMDeath completion and before changing VM state. However, seems it is still a gap between vm death event completion and disabling events. So user can see events after VMDeath completion. >> >> It might be still possible also to wait while all currently executing events are completed. It is not required be specification, might add unneeded complexity. So I want to apply this fix first and then to check if we still any problems. >> Then, I plan to wait with timeout until all current (and queued) jvmti events are completed with some reasonable timeout. >> Currently, I haven't seen problems with this fix and https://bugs.openjdk.org/browse/JDK-8352654. > > src/hotspot/share/prims/jvmtiEventController.cpp line 1060: > >> 1058: void >> 1059: JvmtiEventControllerPrivate::vm_death() { >> 1060: _execution_finished = true; > > Unless there is some lock guarding this that I cannot see in this diff, if you want to ensure this will be seen as soon as possible then you need a `store_fence` (and the variable should be `volatile` - and will be a candidate for `Atomic`). You are still racing with others threads but this would at least attempt to minimise the window. I forgot to put this in description and mentioned the first comment. The access to variable is protected with JvmtiThreadState_lock. Am I understand correctly, that it is enough to correctly synchronize it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27504#discussion_r2391984202 From rehn at openjdk.org Tue Sep 30 15:14:46 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 30 Sep 2025 15:14:46 GMT Subject: Integrated: 8367692: RISC-V: Align post call nop In-Reply-To: References: Message-ID: <5sfKEgXkR9_IYatjlpHaQAlQT6jDtltC71k8-bXnAi0=.a234b32b-39a4-439b-9588-88eb2dae84ee@github.com> On Wed, 24 Sep 2025 11:52:20 GMT, Robbin Ehn wrote: > Hi please, consider. > > As ziccif require instructions to natural aligned to be atomic the 4 byte post call nop must be aligned. > But I don't want to add a c.nop(2b) to align the nop(4b) which means the jal(r) must also be algined. > As we have no utility to aligned the end of an instruction sequence the call it self is aligned and uses only 4 byte instructions. Only in the case where we could use an two c-instruction we may loose space. > > Thanks, Robbin This pull request has now been integrated. Changeset: 07ecc93d Author: Robbin Ehn URL: https://git.openjdk.org/jdk/commit/07ecc93dbd0b74e2362d369e22b5141289eb1f76 Stats: 144 lines in 7 files changed: 76 ins; 29 del; 39 mod 8367692: RISC-V: Align post call nop Reviewed-by: fyang, fjiang, mli ------------- PR: https://git.openjdk.org/jdk/pull/27467 From lmesnik at openjdk.org Tue Sep 30 15:41:43 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 30 Sep 2025 15:41:43 GMT Subject: RFR: 8355631: The events might be generated after VM_DEATH event In-Reply-To: <9Pt3r-dYcnG_IOpxWynEIWfl4EF0ZQVVoQ1CHbstwRo=.ea9be3fe-1143-4615-a26d-8c51f0adbfc0@github.com> References: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com> <9Pt3r-dYcnG_IOpxWynEIWfl4EF0ZQVVoQ1CHbstwRo=.ea9be3fe-1143-4615-a26d-8c51f0adbfc0@github.com> Message-ID: On Tue, 30 Sep 2025 06:28:15 GMT, David Holmes wrote: > > After this fix the VMDeath callback also can't generate any events. > > I think this needs a CSR request and likely a release note. Though if you plan to later wait for all event processing to complete, is it even necessary to make the current change? The spec is very imprecise when it comes to when exactly no further events will be processed, but it seems reasonable to expect that the callback for VM_DEATH is the last thing that should generate events. Though unless event processing is fully synchronized with locks (which I'm pretty sure it isn't) then you have races no matter what you do. I am concerned that, given you cannot completely prevent events from being generated "after" VM_DEATH, the change may "break" more code than it "fixes". ?? This change completely prevents generation of events after VM Death is posted. While the callback execution is might be in the progress. I plan to fix this later. The main problem would be dealing with long-processing events in daemon threads. Right now I am not sure if CSR is needed. The new behaviour doesn't require specification changes. I want to implement this fix separately to ensure that it doesn't break anything. Then I plan to add synchronization separately. This fix also doesn't change specification, because spec is very 'imprecise' as you mentioned. It might be makes sense to amend specification saying explicitly that VM Death is the last event generated in the VM. But is it needed? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27504#issuecomment-3352791338 From pchilanomate at openjdk.org Tue Sep 30 15:53:49 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 30 Sep 2025 15:53:49 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. 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). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27570#discussion_r2392098950 From tschatzl at openjdk.org Tue Sep 30 15:57:49 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 30 Sep 2025 15:57:49 GMT Subject: RFR: 8236073: G1: Use SoftMaxHeapSize to guide GC heuristics [v3] In-Reply-To: <8jjBh52pZlAjsLJ4ce1oacnDVdu8qCe2pJYApXsU5HM=.462adbdd-e3b7-4d4a-a130-aecadba36b00@github.com> References: <8jjBh52pZlAjsLJ4ce1oacnDVdu8qCe2pJYApXsU5HM=.462adbdd-e3b7-4d4a-a130-aecadba36b00@github.com> Message-ID: > Hi all, > > please review this change to implement `SoftMaxHeapSize` for G1. > > Main change is that `SoftMaxHeapSize` now impacts the `G1IHOPControl::target_occupancy()`, i.e. the amount of bytes G1 when reclaim should start. > > Most of the other changes are just about updating logging/JFR and making sure that the `SoftMaxHeapSize` values are consistent across calls. > > Testing: tier1-5 > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * fix whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27524/files - new: https://git.openjdk.org/jdk/pull/27524/files/ec1ccb7f..390e70ca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27524&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27524&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27524.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27524/head:pull/27524 PR: https://git.openjdk.org/jdk/pull/27524 From kvn at openjdk.org Tue Sep 30 16:06:00 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 30 Sep 2025 16:06:00 GMT Subject: RFR: 8364929: Assign unique id to each AdapterBlob stored in AOTCodeCache In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 16:22:45 GMT, Ashutosh Mehra wrote: > This patch assigns unique id to each AdapterHandlerEntry so as to avoid using hash computed from AdapterFingerPrint which may not be unique. Unique id allows AOTCodeCache to locate the AdapterBlob being requested to be loaded. > > Testing: > Before this patch `runtime/cds/appcds/aotClassLinking/StringConcatStress.java` emits warning messages in the production run: > > [0.009s][warning][aot,codecache,stubs] Saved blob's name 'LIIDIIIDL' is different from the expected name 'LIIDIIDL' > [0.009s][warning][aot ] Failed to link AdapterHandlerEntry (fp=LIIDIIDL) to its code in the AOT code cache > [0.009s][warning][aot,codecache,stubs] Saved blob's name 'IILLLLIIIIII' is different from the expected name 'IILLLLLILIII' > [0.009s][warning][aot ] Failed to link AdapterHandlerEntry (fp=IILLLLLILIII) to its code in the AOT code cache > > With this patch, such warnings are not seen at all How you insure that the order of adapters generation is the same in assembly and production runs? ------------- PR Review: https://git.openjdk.org/jdk/pull/27553#pullrequestreview-3285741851 From asmehra at openjdk.org Tue Sep 30 16:37:23 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 30 Sep 2025 16:37:23 GMT Subject: RFR: 8364929: Assign unique id to each AdapterBlob stored in AOTCodeCache In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 16:03:38 GMT, Vladimir Kozlov wrote: > How you insure that the order of adapters generation is the same in assembly and production runs? Adapters are not generated again in the production run. The adapter id is part of the AdapterHandlerEntry and they are stored in the AOTCache in the assembly run. In the production run when they are loaded back, we get the max id and use it populate the running id counter. Any new adapter generated in the production run gets the next id. Does that help? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27553#issuecomment-3352982897 From fandreuzzi at openjdk.org Tue Sep 30 16:42:35 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Tue, 30 Sep 2025 16:42:35 GMT Subject: RFR: 8368966: Remove spurious VMStructs friends Message-ID: <8OJWg3O52vyoX_mFGHHpTsBmWvHeBVJC3Pq8IYKY2rk=.205ce94a-a9c8-4d85-8321-9268b1a29b68@github.com> In this PR I propose a small clean up to remove several spurious friends of `VMStructs`. I could not find any reference to them in `vmStructs*`, or private symbols are not mentioned so the friendship can be removed. Passes tier1 and tier2 (fastdebug). ------------- Commit messages: - Merge branch 'master' into cleanup-vmstructs - nn Changes: https://git.openjdk.org/jdk/pull/27583/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27583&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368966 Stats: 80 lines in 47 files changed: 1 ins; 78 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27583.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27583/head:pull/27583 PR: https://git.openjdk.org/jdk/pull/27583 From kvn at openjdk.org Tue Sep 30 16:43:27 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 30 Sep 2025 16:43:27 GMT Subject: RFR: 8364929: Assign unique id to each AdapterBlob stored in AOTCodeCache In-Reply-To: References: Message-ID: <-osiIm6pwcrg3vjP_8d_Wo7DyEl2Pfkwa7KVI1Y6VBQ=.c21e7415-6106-457e-9037-9e314ab492e0@github.com> On Tue, 30 Sep 2025 16:35:01 GMT, Ashutosh Mehra wrote: > Adapters are not generated again in the production run. The adapter id is part of the AdapterHandlerEntry and they are stored in the AOTCache in the assembly run. In the production run when they are loaded back, we get the max id and use it populate the running id counter. Any new adapter generated in the production run gets the next id. Does that help? Do we have guarantee that we load AOT adapters before any new adapter is generated? Also if hash is not used we don't need related methods. Right? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27553#issuecomment-3353002107 From asmehra at openjdk.org Tue Sep 30 17:03:00 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 30 Sep 2025 17:03:00 GMT Subject: RFR: 8364929: Assign unique id to each AdapterBlob stored in AOTCodeCache In-Reply-To: <-osiIm6pwcrg3vjP_8d_Wo7DyEl2Pfkwa7KVI1Y6VBQ=.c21e7415-6106-457e-9037-9e314ab492e0@github.com> References: <-osiIm6pwcrg3vjP_8d_Wo7DyEl2Pfkwa7KVI1Y6VBQ=.c21e7415-6106-457e-9037-9e314ab492e0@github.com> Message-ID: On Tue, 30 Sep 2025 16:41:16 GMT, Vladimir Kozlov wrote: > Do we have guarantee that we load AOT adapters before any new adapter is generated? There is no check for that as such. The adapters are loaded in `AdapterHandlerLibrary::initialize()` and I think there is already an assumption that `AdapterHandlerLibrary::initialize()` would be called before any adapters are created. I can add an assert that `id_counter` is 0 in `AdapterHandlerLibrary::initialize()` to make it more explicit. Would that be sufficient? > Also if hash is not used we don't need related methods. Right? Hash is still needed to look up an adapter in the runtime table based on the fingerprint obtained from method signature. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27553#issuecomment-3353060980 From kvn at openjdk.org Tue Sep 30 18:05:42 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 30 Sep 2025 18:05:42 GMT Subject: RFR: 8364929: Assign unique id to each AdapterBlob stored in AOTCodeCache In-Reply-To: References: <-osiIm6pwcrg3vjP_8d_Wo7DyEl2Pfkwa7KVI1Y6VBQ=.c21e7415-6106-457e-9037-9e314ab492e0@github.com> Message-ID: <-LVGxDzKpnd2MizZ43LbKXrTU7wInHJMW0QW944SAWY=.cce33b3b-88d0-4c71-a4e0-6610835ecf32@github.com> On Tue, 30 Sep 2025 17:00:05 GMT, Ashutosh Mehra wrote: > I can add an assert that id_counter is 0 in AdapterHandlerLibrary::initialize() to make it more explicit. Would that be sufficient? Yes. Adapters can't be requested when `AdapterHandlerLibrary::initialize()` is executed (we still running in one thread). And after `AdapterHandlerLibrary::initialize()` it is okay. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27553#issuecomment-3353257617 From kvn at openjdk.org Tue Sep 30 18:05:45 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 30 Sep 2025 18:05:45 GMT Subject: RFR: 8364929: Assign unique id to each AdapterBlob stored in AOTCodeCache In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 16:22:45 GMT, Ashutosh Mehra wrote: > This patch assigns unique id to each AdapterHandlerEntry so as to avoid using hash computed from AdapterFingerPrint which may not be unique. Unique id allows AOTCodeCache to locate the AdapterBlob being requested to be loaded. > > Testing: > Before this patch `runtime/cds/appcds/aotClassLinking/StringConcatStress.java` emits warning messages in the production run: > > [0.009s][warning][aot,codecache,stubs] Saved blob's name 'LIIDIIIDL' is different from the expected name 'LIIDIIDL' > [0.009s][warning][aot ] Failed to link AdapterHandlerEntry (fp=LIIDIIDL) to its code in the AOT code cache > [0.009s][warning][aot,codecache,stubs] Saved blob's name 'IILLLLIIIIII' is different from the expected name 'IILLLLLILIII' > [0.009s][warning][aot ] Failed to link AdapterHandlerEntry (fp=IILLLLLILIII) to its code in the AOT code cache > > With this patch, such warnings are not seen at all src/hotspot/share/runtime/sharedRuntime.cpp line 3008: > 3006: }); > 3007: // Set adapter id to the maximum id found in the AOTCache > 3008: _id_counter = max_id; Is this number the same as number of AOT adapter entries in AdapterHandlerEntry? Do we need `max_id`? In which case they could be different? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27553#discussion_r2392423283 From asmehra at openjdk.org Tue Sep 30 18:32:02 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 30 Sep 2025 18:32:02 GMT Subject: RFR: 8364929: Assign unique id to each AdapterBlob stored in AOTCodeCache In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 18:03:28 GMT, Vladimir Kozlov wrote: > Is this number the same as number of AOT adapter entries in AdapterHandlerEntry? Do we need max_id? In which case they could be different? I thought about this. It is possible that some adapters generated in assembly phase are not stored in the cache. So there may be gaps in the adapter ids of the adapters in the cache. In such case using the number of entries to decide next adapter id can result in clash of adapter id with the runtime generated adapters. But the maximum id ensures adapter ids are never reused. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27553#discussion_r2392480023 From tschatzl at openjdk.org Tue Sep 30 19:32:37 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 30 Sep 2025 19:32:37 GMT Subject: RFR: 8236073: G1: Use SoftMaxHeapSize to guide GC heuristics [v4] In-Reply-To: <8jjBh52pZlAjsLJ4ce1oacnDVdu8qCe2pJYApXsU5HM=.462adbdd-e3b7-4d4a-a130-aecadba36b00@github.com> References: <8jjBh52pZlAjsLJ4ce1oacnDVdu8qCe2pJYApXsU5HM=.462adbdd-e3b7-4d4a-a130-aecadba36b00@github.com> Message-ID: > Hi all, > > please review this change to implement `SoftMaxHeapSize` for G1. > > Main change is that `SoftMaxHeapSize` now impacts the `G1IHOPControl::target_occupancy()`, i.e. the amount of bytes G1 when reclaim should start. > > Most of the other changes are just about updating logging/JFR and making sure that the `SoftMaxHeapSize` values are consistent across calls. > > Testing: tier1-5 > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * align MinHeapSize to heap alignment to avoid issues with conflicting MinHeapSize and SoftMaxHeapSize ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27524/files - new: https://git.openjdk.org/jdk/pull/27524/files/390e70ca..edfcca13 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27524&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27524&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27524.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27524/head:pull/27524 PR: https://git.openjdk.org/jdk/pull/27524 From kvn at openjdk.org Tue Sep 30 19:55:33 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 30 Sep 2025 19:55:33 GMT Subject: RFR: 8364929: Assign unique id to each AdapterBlob stored in AOTCodeCache In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 18:28:41 GMT, Ashutosh Mehra wrote: >> src/hotspot/share/runtime/sharedRuntime.cpp line 3008: >> >>> 3006: }); >>> 3007: // Set adapter id to the maximum id found in the AOTCache >>> 3008: _id_counter = max_id; >> >> Is this number the same as number of AOT adapter entries in AdapterHandlerEntry? Do we need `max_id`? In which case they could be different? > >> Is this number the same as number of AOT adapter entries in AdapterHandlerEntry? Do we need max_id? In which case they could be different? > > I thought about this. It is possible that some adapters generated in assembly phase are not stored in the cache. So there may be gaps in the adapter ids of the adapters in the cache. In such case using the number of entries to decide next adapter id can result in clash of adapter id with the runtime generated adapters. But the maximum id ensures adapter ids are never reused. Please add comment about that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27553#discussion_r2392674339 From asmehra at openjdk.org Tue Sep 30 20:25:44 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 30 Sep 2025 20:25:44 GMT Subject: RFR: 8364929: Assign unique id to each AdapterBlob stored in AOTCodeCache [v2] In-Reply-To: References: Message-ID: > This patch assigns unique id to each AdapterHandlerEntry so as to avoid using hash computed from AdapterFingerPrint which may not be unique. Unique id allows AOTCodeCache to locate the AdapterBlob being requested to be loaded. > > Testing: > Before this patch `runtime/cds/appcds/aotClassLinking/StringConcatStress.java` emits warning messages in the production run: > > [0.009s][warning][aot,codecache,stubs] Saved blob's name 'LIIDIIIDL' is different from the expected name 'LIIDIIDL' > [0.009s][warning][aot ] Failed to link AdapterHandlerEntry (fp=LIIDIIDL) to its code in the AOT code cache > [0.009s][warning][aot,codecache,stubs] Saved blob's name 'IILLLLIIIIII' is different from the expected name 'IILLLLLILIII' > [0.009s][warning][aot ] Failed to link AdapterHandlerEntry (fp=IILLLLLILIII) to its code in the AOT code cache > > With this patch, such warnings are not seen at all Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: Add comment explaining the reason for using largest adapter id of the AOT stored handlers to initialize _id_counter Signed-off-by: Ashutosh Mehra ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27553/files - new: https://git.openjdk.org/jdk/pull/27553/files/737b9088..93906b1e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27553&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27553&range=00-01 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27553.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27553/head:pull/27553 PR: https://git.openjdk.org/jdk/pull/27553 From asmehra at openjdk.org Tue Sep 30 20:25:45 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 30 Sep 2025 20:25:45 GMT Subject: RFR: 8364929: Assign unique id to each AdapterBlob stored in AOTCodeCache [v2] In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 19:52:49 GMT, Vladimir Kozlov wrote: >>> Is this number the same as number of AOT adapter entries in AdapterHandlerEntry? Do we need max_id? In which case they could be different? >> >> I thought about this. It is possible that some adapters generated in assembly phase are not stored in the cache. So there may be gaps in the adapter ids of the adapters in the cache. In such case using the number of entries to decide next adapter id can result in clash of adapter id with the runtime generated adapters. But the maximum id ensures adapter ids are never reused. > > Please add comment about that. Done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27553#discussion_r2392741060 From kvn at openjdk.org Tue Sep 30 20:51:59 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 30 Sep 2025 20:51:59 GMT Subject: RFR: 8364929: Assign unique id to each AdapterBlob stored in AOTCodeCache [v2] In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 20:20:14 GMT, Ashutosh Mehra wrote: >> Please add comment about that. > > Done Now only assert(_id_counter ==0) is missing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27553#discussion_r2392801767 From vlivanov at openjdk.org Tue Sep 30 21:13:28 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 30 Sep 2025 21:13:28 GMT Subject: RFR: 8368722: RISC-V: Several vector load/store tests fail due to lack of support for misaligned vector access [v2] In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 03:01:10 GMT, Dingli Zhang wrote: >> Hi, >> Can you help to review this patch? Thanks! >> >> In `*VectorLoadStoreTests.java`, `loadMemorySegmentMaskIOOBE` and `storeMemorySegmentMaskIOOBE` may fail because `int index = fi.apply((int) a.byteSize())` can generate random indices that result in misaligned addresses, leading to SIGBUS on hardware that disallows misaligned vector accesses. >> >> Some RISC-V hardware supports fast misaligned scalar accesses but not vector ones, which causes SIGBUS when executing these tests with misaligned vector memory operations. >> >> After [JDK-8368732](https://bugs.openjdk.org/browse/JDK-8368732), we can use `AlignVector` to check the result on platforms with or without fast misaligned vector accesses. When misaligned vector accesses are not supported, it is possible to completely disable the VM?s VectorAPI support by setting `EnableVectorSupport`, without affecting auto-vectorization. >> >> In addition, after running fastdebug tests including `jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization`, we found that some IR-related tests require EnableVectorSupport. Therefore, we added `@requires vm.opt.EnableVectorSupport == true` to skip these tests. >> >> We can check the status of EnableVectorSupport as follows: >> >> On k1 >> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version >> [0.737s][info][compilation] EnableVectorSupport=false >> [0.738s][info][compilation] EnableVectorReboxing=false >> [0.738s][info][compilation] EnableVectorAggressiveReboxing=false >> >> On qemu >> $ java --add-modules=jdk.incubator.vector -Xlog:compilation -version >> [3.048s][info][compilation] EnableVectorSupport=true >> [3.050s][info][compilation] EnableVectorReboxing=true >> [3.051s][info][compilation] EnableVectorAggressiveReboxing=true >> >> >> ### Test (fastdebug) >> - [x] Run jdk_vector, jdk_vector_sanity, hotspot_vector_1, hotspot_vector_2, compiler/vectorapi, compiler/vectorization on k1 > > Dingli Zhang 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 one additional commit since the last revision: > > 8368722: RISC-V: Several vector load/store tests fail without support for misaligned vector access src/hotspot/share/classfile/modules.cpp line 459: > 457: // Special handling of jdk.incubator.vector > 458: if (strcmp(module_name, "jdk.incubator.vector") == 0) { > 459: if (FLAG_IS_DEFAULT(EnableVectorSupport) RISCV64_ONLY(&& !AlignVector)) { `AlignVector` doesn't look appropriate here (and in other places). If hardware doesn't support misaligned vector accesses, then there shouldn't be a way to set `AlignVector = false`. The JVM should issue a warning and unconditionally set both `EnableVectorSupport = false` and `AlignVector = true` irrespective of what is specified on the command line. Also, the problem is not specific to C2. There are vectorized VM stubs which can be affected by absence of hardware misaligned vector access support. I suggest to introduce a cross-platform `VM_Version::supports_misaligned_vector_accesses()` which affects `AlignVector`, `EnableVectorSupport`, `AvoidUnalignedAccesses` (maybe even supersedes it?), and eventually all usages of vector memory accesses in VM code. Speaking of aligned/misaligned vector accesses, does RISC-V distinguish them on ISA level (with different instructions)? If that's the case, then it makes sense to add asserts in corresponding Assembler/MacroAssembler methods. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27506#discussion_r2392844433 From asmehra at openjdk.org Tue Sep 30 21:32:40 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 30 Sep 2025 21:32:40 GMT Subject: RFR: 8364929: Assign unique id to each AdapterBlob stored in AOTCodeCache [v3] In-Reply-To: References: Message-ID: <9wddk1obRVfS_B8Kq8KgK8ZYtaVfv1R855dtW5PWHwQ=.ac08aecc-5f27-444a-9ae7-8ad8d17f829f@github.com> > This patch assigns unique id to each AdapterHandlerEntry so as to avoid using hash computed from AdapterFingerPrint which may not be unique. Unique id allows AOTCodeCache to locate the AdapterBlob being requested to be loaded. > > Testing: > Before this patch `runtime/cds/appcds/aotClassLinking/StringConcatStress.java` emits warning messages in the production run: > > [0.009s][warning][aot,codecache,stubs] Saved blob's name 'LIIDIIIDL' is different from the expected name 'LIIDIIDL' > [0.009s][warning][aot ] Failed to link AdapterHandlerEntry (fp=LIIDIIDL) to its code in the AOT code cache > [0.009s][warning][aot,codecache,stubs] Saved blob's name 'IILLLLIIIIII' is different from the expected name 'IILLLLLILIII' > [0.009s][warning][aot ] Failed to link AdapterHandlerEntry (fp=IILLLLLILIII) to its code in the AOT code cache > > With this patch, such warnings are not seen at all Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: Add assert for _id_counter == 0 Signed-off-by: Ashutosh Mehra ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27553/files - new: https://git.openjdk.org/jdk/pull/27553/files/93906b1e..84edc05e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27553&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27553&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27553.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27553/head:pull/27553 PR: https://git.openjdk.org/jdk/pull/27553 From asmehra at openjdk.org Tue Sep 30 21:32:41 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 30 Sep 2025 21:32:41 GMT Subject: RFR: 8364929: Assign unique id to each AdapterBlob stored in AOTCodeCache [v3] In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 20:49:20 GMT, Vladimir Kozlov wrote: >> Done > > Now only assert(_id_counter ==0) is missing. Added the assert before `_id_counter = max_id` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27553#discussion_r2392873946 From manc at openjdk.org Tue Sep 30 22:07:10 2025 From: manc at openjdk.org (Man Cao) Date: Tue, 30 Sep 2025 22:07:10 GMT Subject: RFR: 8236073: G1: Use SoftMaxHeapSize to guide GC heuristics [v4] In-Reply-To: References: <8jjBh52pZlAjsLJ4ce1oacnDVdu8qCe2pJYApXsU5HM=.462adbdd-e3b7-4d4a-a130-aecadba36b00@github.com> Message-ID: On Tue, 30 Sep 2025 19:32:37 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to implement `SoftMaxHeapSize` for G1. >> >> Main change is that `SoftMaxHeapSize` now impacts the `G1IHOPControl::target_occupancy()`, i.e. the amount of bytes G1 when reclaim should start. >> >> Most of the other changes are just about updating logging/JFR and making sure that the `SoftMaxHeapSize` values are consistent across calls. >> >> Testing: tier1-5 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > * align MinHeapSize to heap alignment to avoid issues with conflicting MinHeapSize and SoftMaxHeapSize Responding to @tschatzl's comment in https://bugs.openjdk.org/browse/JDK-8236073: > SoftMaxHeapSize just affects the target heap size for scheduling concurrent marks. GCTimeRatio sets the target as well, so the result is basically MIN(SoftMaxHeapSize, GCTimeRatio-based-target). I have not verified, but could this problematic feedback loop happen? User sets a **low** `SoftMaxHeapSize` value, then G1 starts to trigger more concurrent marks and incremental collections, then GC overhead becomes higher. Then G1 observes that the actual GC overhead is above the `GCTimeRatio` target, so it **expands** the heap. Thus, setting a small `SoftMaxHeapSize` makes G1 expand the heap further, ------------- PR Comment: https://git.openjdk.org/jdk/pull/27524#issuecomment-3353942624 From kvn at openjdk.org Tue Sep 30 22:57:08 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 30 Sep 2025 22:57:08 GMT Subject: RFR: 8364929: Assign unique id to each AdapterBlob stored in AOTCodeCache [v3] In-Reply-To: <9wddk1obRVfS_B8Kq8KgK8ZYtaVfv1R855dtW5PWHwQ=.ac08aecc-5f27-444a-9ae7-8ad8d17f829f@github.com> References: <9wddk1obRVfS_B8Kq8KgK8ZYtaVfv1R855dtW5PWHwQ=.ac08aecc-5f27-444a-9ae7-8ad8d17f829f@github.com> Message-ID: On Tue, 30 Sep 2025 21:32:40 GMT, Ashutosh Mehra wrote: >> This patch assigns unique id to each AdapterHandlerEntry so as to avoid using hash computed from AdapterFingerPrint which may not be unique. Unique id allows AOTCodeCache to locate the AdapterBlob being requested to be loaded. >> >> Testing: >> Before this patch `runtime/cds/appcds/aotClassLinking/StringConcatStress.java` emits warning messages in the production run: >> >> [0.009s][warning][aot,codecache,stubs] Saved blob's name 'LIIDIIIDL' is different from the expected name 'LIIDIIDL' >> [0.009s][warning][aot ] Failed to link AdapterHandlerEntry (fp=LIIDIIDL) to its code in the AOT code cache >> [0.009s][warning][aot,codecache,stubs] Saved blob's name 'IILLLLIIIIII' is different from the expected name 'IILLLLLILIII' >> [0.009s][warning][aot ] Failed to link AdapterHandlerEntry (fp=IILLLLLILIII) to its code in the AOT code cache >> >> With this patch, such warnings are not seen at all > > Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: > > Add assert for _id_counter == 0 > > Signed-off-by: Ashutosh Mehra src/hotspot/share/runtime/sharedRuntime.cpp line 2608: > 2606: // id_counter overflow > 2607: return nullptr; > 2608: } I think it will cause issue with `ubsan` because we don't check for `nullptr` returned from this method. May be use `guarantee(id > 0);` instead ? 2^32 -1 is big number. We can't have so much method's signatures combinations. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27553#discussion_r2393009381