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. @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 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 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: