From amenkov at openjdk.org Tue Jul 1 00:33:40 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 1 Jul 2025 00:33:40 GMT Subject: RFR: 8360664: Null pointer dereference in src/hotspot/share/prims/jvmtiTagMap.cpp in IterateOverHeapObjectClosure::do_object() [v3] In-Reply-To: References: Message-ID: <8PM6VY6Iuchg8hMcU9iyivsQmZ2x17vqbsH0pQ1IUZg=.88904f1c-a9d3-48e0-88d7-a7417ee5496c@github.com> On Mon, 30 Jun 2025 13:03:23 GMT, Artem Semenov wrote: >> The defect has been detected and confirmed in the function ```IterateOverHeapObjectClosure::do_object()``` located in the file ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis. This defect can potentially lead to a null pointer dereference. >> >> The pointer ```oop o``` is passed to the constructor of the CallbackWrapper class, where it is dereferenced without a null check. > > Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: > > changed if tu assert Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26002#pullrequestreview-2973134141 From cjplummer at openjdk.org Tue Jul 1 00:48:39 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 1 Jul 2025 00:48:39 GMT Subject: RFR: 8360664: Null pointer dereference in src/hotspot/share/prims/jvmtiTagMap.cpp in IterateOverHeapObjectClosure::do_object() [v3] In-Reply-To: References: Message-ID: On Mon, 30 Jun 2025 13:03:23 GMT, Artem Semenov wrote: >> The defect has been detected and confirmed in the function ```IterateOverHeapObjectClosure::do_object()``` located in the file ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis. This defect can potentially lead to a null pointer dereference. >> >> The pointer ```oop o``` is passed to the constructor of the CallbackWrapper class, where it is dereferenced without a null check. > > Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: > > changed if tu assert The fix looks good, but I assume that the static analysis tool that reported the false warning is still going to report it, or at least do so in product builds where the assert code is not included. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26002#pullrequestreview-2973147893 From amenkov at openjdk.org Tue Jul 1 01:02:01 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 1 Jul 2025 01:02:01 GMT Subject: RFR: 8359958: Cleanup "local" debuggee references after JDK-8333117 removed support for non-local debuggees [v2] In-Reply-To: <8qFFnwzJwKtq1uKNtPINZE80QDx7t9IeQlR4LBg4rOo=.1375d71e-f7cb-4506-af13-60be46c24cb0@github.com> References: <8qFFnwzJwKtq1uKNtPINZE80QDx7t9IeQlR4LBg4rOo=.1375d71e-f7cb-4506-af13-60be46c24cb0@github.com> Message-ID: On Thu, 19 Jun 2025 00:33:42 GMT, Chris Plummer wrote: >> [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117) removed support for non-local debuggees, so now only local debuggees are supported. However, there are now a lot of references to the "local" debuggee mode which are not necessary because "local" is implied. These references are in comments and API names and should be removed. >> >> Also, after [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117), DebugeeProcess no longer needs to be considered abstract. It has no abstract methods. >> >> Tested nsk/jdi, nsk/jdb, and nsk/jdwp locally. Will run tier5 CI to get better coverage. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > startLocalDebugee renamed to startDebugee Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25887#pullrequestreview-2973161889 From coleenp at openjdk.org Tue Jul 1 01:55:48 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 1 Jul 2025 01:55:48 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v12] In-Reply-To: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: <6WPU5dGPFJ38KnDO88FvRIqQsclgmajiQ2RRKVm0ZCw=.3575812c-b388-42e6-8396-8c39162b6dc0@github.com> > I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. > Tested with test. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Remove comment. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25857/files - new: https://git.openjdk.org/jdk/pull/25857/files/791f2146..9b704274 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25857&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25857.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25857/head:pull/25857 PR: https://git.openjdk.org/jdk/pull/25857 From coleenp at openjdk.org Tue Jul 1 01:55:50 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 1 Jul 2025 01:55:50 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v11] In-Reply-To: References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: On Mon, 30 Jun 2025 23:26:17 GMT, Leonid Mesnik wrote: >> Coleen Phillimore has updated the pull request incrementally with three additional commits since the last revision: >> >> - Update test/lib/RedefineClassHelper.java >> >> Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> >> - Update test/lib/RedefineClassHelper.java >> >> Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> >> - Update test/lib/RedefineClassHelper.java >> >> Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> > > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/ClassVersionAfterRedefine.java line 45: > >> 43: ClassVersionAfterRedefine cvar = new ClassVersionAfterRedefine(); >> 44: >> 45: // Poor man's renaming of class "TestClassOld" to "TestClassXXX" > > It is not "poor man's" renaming anymore and RedefineClassHelper.replaceClassName() is self-explanable. So this comment could be just removed. Okay. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25857#discussion_r2176243389 From dholmes at openjdk.org Tue Jul 1 02:30:40 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 1 Jul 2025 02:30:40 GMT Subject: RFR: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in JvmtiBreakpoints::clearall_in_class_at_safepoint [v2] In-Reply-To: References: Message-ID: On Mon, 30 Jun 2025 21:20:55 GMT, Leonid Mesnik wrote: >> The segv/eav happens in the case if JvmtiBreakpoint::_method's class redefined old between getting the Method* from jmethodid in the >> JvmtiEnv::SetBreakpoint(Method* method, jlocation location) {..} and >> and actual setting breakpoint in the VM operation VM_ChangeBreakpoints. >> >> Here are details: >> The breakpoint is set in 2 steps. >> 1) method jvmti_SetBreakpoint(jvmtiEnv* env, jmethodID method, jlocation location) convert jmethodID to Method* and call >> JvmtiEnv::SetBreakpoint(Method* method, jlocation location) >> where >> JvmtiBreakpoint bp(method, location); >> is created with this Method* >> Note: it is done while thread is in VM state, so Method can't become is_old while this is done. >> >> 2) The VMOp is used to add breakpoint into the list >> VM_ChangeBreakpoints set_breakpoint(VM_ChangeBreakpoints::SET_BREAKPOINT, &bp); >> VMThread::execute(&set_breakpoint); >> to call JvmtiBreakpoints::set_at_safepoint() >> that can modify JvmtiBreakpoints list and set breakpoint in safepoint without synchronization. >> >> So it might be possible that class redefinition VM_RedefineClasses operation that redefine the class with this breakpoint happens between steps 1) and 2) >> VM_RedefineClasses::redefine_single_class() >> clear all class-related breakpoints in the JvmtiBreakpoints, however the "problematic" breakpoint is in VMThread queue and thus we are still continue to do this operation. >> So in the step 2) the the JvmtiBreakpoint with 'is_old' method is added to the JvmtiBreakpoints and breakpoint is set. >> >> Then old method mights be purged any time once they are not on the stack and any access to this breakpoint could lead to usage of Metthod* _method pointing to deallocated metaspace. >> >> The VM_RedefineClasses clear all breakpoints so it is correct just to don't proceed with current breakpoint also. >> >> Looks, like very unlikely but reproducing with stress test after some time. >> Verified that the crash is not reproduced anymore with corresponding test after the fix. >> >> Many thanks to Coleen for detailed explanation of class redefinition. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > changed jmethodid to methodHandle. `methodHandle` form seems okay to me too. src/hotspot/share/prims/jvmtiImpl.cpp line 192: > 190: void VM_ChangeBreakpoints::doit() { > 191: if (_bp->method()->is_old()) { > 192: // The bp->_method become old because VMOp with class redefinition happened for this class Suggestion: // The bp->_method became old because VMOp with class redefinition happened for this class src/hotspot/share/prims/jvmtiImpl.cpp line 193: > 191: if (_bp->method()->is_old()) { > 192: // The bp->_method become old because VMOp with class redefinition happened for this class > 193: // fter JvmtBreakpoint was created but before JVM_ChangeBreakpoints started. Suggestion: // after JvmtiBreakpoint was created but before JVM_ChangeBreakpoints started. ------------- PR Review: https://git.openjdk.org/jdk/pull/26031#pullrequestreview-2973294055 PR Review Comment: https://git.openjdk.org/jdk/pull/26031#discussion_r2176290929 PR Review Comment: https://git.openjdk.org/jdk/pull/26031#discussion_r2176291229 From dholmes at openjdk.org Tue Jul 1 02:33:42 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 1 Jul 2025 02:33:42 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v12] In-Reply-To: <6WPU5dGPFJ38KnDO88FvRIqQsclgmajiQ2RRKVm0ZCw=.3575812c-b388-42e6-8396-8c39162b6dc0@github.com> References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> <6WPU5dGPFJ38KnDO88FvRIqQsclgmajiQ2RRKVm0ZCw=.3575812c-b388-42e6-8396-8c39162b6dc0@github.com> Message-ID: On Tue, 1 Jul 2025 01:55:48 GMT, Coleen Phillimore wrote: >> I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. >> Tested with test. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove comment. LGTM! ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2973299545 From dholmes at openjdk.org Tue Jul 1 03:08:42 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 1 Jul 2025 03:08:42 GMT Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch [v7] In-Reply-To: References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com> Message-ID: On Mon, 30 Jun 2025 11:24:28 GMT, Kevin Walls wrote: >> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread. This is hard to reproduce but a thread that has since terminated can provoke a crash. Recognise this and return a null ThreadSnapshot. > > Kevin Walls 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 13 additional commits since the last revision: > > - remove test definition changes > - TLH: use cv_internal_thread_to_JavaThread() > - Merge remote-tracking branch 'upstream/master' into 8359870_threadexited > - Test requires: permit linux debug testing > - comment update > - comment update > - newline > - Test fails on minimal VM: require jvmti feature > - Correct THROW macro > - ThreadDumper thread count > - ... and 3 more: https://git.openjdk.org/jdk/compare/393efb22...e2043438 Some minor nits/suggestions but generally looks good. src/hotspot/share/services/threadService.cpp line 1445: > 1443: JavaThread* java_thread = nullptr; > 1444: oop thread_oop; > 1445: bool has_javathread = tlh.cv_internal_thread_to_JavaThread(jthread, &java_thread, &thread_oop); Suggestion: bool has_javathread = tlh.cv_internal_thread_to_JavaThread(jthread, &java_thread, &thread_oop); assert((has_javathread && thread_oop != nullptr) || !has_javathread, "Missing Thread oop"); src/hotspot/share/services/threadService.cpp line 1447: > 1445: bool has_javathread = tlh.cv_internal_thread_to_JavaThread(jthread, &java_thread, &thread_oop); > 1446: Handle thread_h(THREAD, thread_oop); > 1447: bool is_virtual = java_lang_VirtualThread::is_instance(thread_h()); Suggestion: bool is_virtual = java_lang_VirtualThread::is_instance(thread_h()); // Deals with null Just to make it clear we don't need an external null check here. src/hotspot/share/services/threadService.cpp line 1450: > 1448: > 1449: if (!has_javathread && !is_virtual) { > 1450: return nullptr; // thread terminated Suggestion: return nullptr; // thread terminated so not of interest It took me a lot of backtracking in the Java code to find ThreadContainer which finally stated that only live threads are of interest, so an expanded comment here would help me. ( I was ready to suggest we should be creating a `ThreadSnapshot` that represents the terminated thread.) src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java line 313: > 311: * @throws UncheckedIOException if an I/O error occurs > 312: */ > 313: private static boolean dumpThread(Thread thread, JsonWriter jsonWriter) { Please document the return value in the javadoc comment. src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 56: > 54: * Take a snapshot of a Thread to get all information about the thread. > 55: * Return null if a ThreadSnapshot cannot be created, for example if the > 56: * thread has terminated. Strictly speaking we can create a snapshot for a terminated thread, but our only client doesn't care about them so we don't. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25958#pullrequestreview-2973312048 PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2176304440 PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2176303308 PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2176318110 PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2176319448 PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2176320553 From dholmes at openjdk.org Tue Jul 1 03:15:40 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 1 Jul 2025 03:15:40 GMT Subject: RFR: 8360664: Null pointer dereference in src/hotspot/share/prims/jvmtiTagMap.cpp in IterateOverHeapObjectClosure::do_object() [v3] In-Reply-To: References: Message-ID: On Mon, 30 Jun 2025 13:03:23 GMT, Artem Semenov wrote: >> The defect has been detected and confirmed in the function ```IterateOverHeapObjectClosure::do_object()``` located in the file ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis. This defect can potentially lead to a null pointer dereference. >> >> The pointer ```oop o``` is passed to the constructor of the CallbackWrapper class, where it is dereferenced without a null check. > > Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: > > changed if tu assert src/hotspot/share/prims/jvmtiTagMap.cpp line 947: > 945: // invoked for each object in the heap > 946: void IterateOverHeapObjectClosure::do_object(oop o) { > 947: assert(o != nullptr, "Parameter 'o' must not be null!"); Suggestion: assert(o != nullptr, "Heap iteration should never produce null"); Same with the other assertion please. Though as @plummercj states I don't see how this will help with the static analysis tool. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26002#discussion_r2176326686 From lmesnik at openjdk.org Tue Jul 1 03:17:41 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 1 Jul 2025 03:17:41 GMT Subject: RFR: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in JvmtiBreakpoints::clearall_in_class_at_safepoint [v3] In-Reply-To: References: Message-ID: > The segv/eav happens in the case if JvmtiBreakpoint::_method's class redefined old between getting the Method* from jmethodid in the > JvmtiEnv::SetBreakpoint(Method* method, jlocation location) {..} and > and actual setting breakpoint in the VM operation VM_ChangeBreakpoints. > > Here are details: > The breakpoint is set in 2 steps. > 1) method jvmti_SetBreakpoint(jvmtiEnv* env, jmethodID method, jlocation location) convert jmethodID to Method* and call > JvmtiEnv::SetBreakpoint(Method* method, jlocation location) > where > JvmtiBreakpoint bp(method, location); > is created with this Method* > Note: it is done while thread is in VM state, so Method can't become is_old while this is done. > > 2) The VMOp is used to add breakpoint into the list > VM_ChangeBreakpoints set_breakpoint(VM_ChangeBreakpoints::SET_BREAKPOINT, &bp); > VMThread::execute(&set_breakpoint); > to call JvmtiBreakpoints::set_at_safepoint() > that can modify JvmtiBreakpoints list and set breakpoint in safepoint without synchronization. > > So it might be possible that class redefinition VM_RedefineClasses operation that redefine the class with this breakpoint happens between steps 1) and 2) > VM_RedefineClasses::redefine_single_class() > clear all class-related breakpoints in the JvmtiBreakpoints, however the "problematic" breakpoint is in VMThread queue and thus we are still continue to do this operation. > So in the step 2) the the JvmtiBreakpoint with 'is_old' method is added to the JvmtiBreakpoints and breakpoint is set. > > Then old method mights be purged any time once they are not on the stack and any access to this breakpoint could lead to usage of Metthod* _method pointing to deallocated metaspace. > > The VM_RedefineClasses clear all breakpoints so it is correct just to don't proceed with current breakpoint also. > > Looks, like very unlikely but reproducing with stress test after some time. > Verified that the crash is not reproduced anymore with corresponding test after the fix. > > Many thanks to Coleen for detailed explanation of class redefinition. Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: - Update src/hotspot/share/prims/jvmtiImpl.cpp Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> - Update src/hotspot/share/prims/jvmtiImpl.cpp Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26031/files - new: https://git.openjdk.org/jdk/pull/26031/files/e1524bbd..c7aaa804 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26031&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26031&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26031.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26031/head:pull/26031 PR: https://git.openjdk.org/jdk/pull/26031 From dholmes at openjdk.org Tue Jul 1 03:50:39 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 1 Jul 2025 03:50:39 GMT Subject: RFR: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in JvmtiBreakpoints::clearall_in_class_at_safepoint [v3] In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 03:17:41 GMT, Leonid Mesnik wrote: >> The segv/eav happens in the case if JvmtiBreakpoint::_method's class redefined old between getting the Method* from jmethodid in the >> JvmtiEnv::SetBreakpoint(Method* method, jlocation location) {..} and >> and actual setting breakpoint in the VM operation VM_ChangeBreakpoints. >> >> Here are details: >> The breakpoint is set in 2 steps. >> 1) method jvmti_SetBreakpoint(jvmtiEnv* env, jmethodID method, jlocation location) convert jmethodID to Method* and call >> JvmtiEnv::SetBreakpoint(Method* method, jlocation location) >> where >> JvmtiBreakpoint bp(method, location); >> is created with this Method* >> Note: it is done while thread is in VM state, so Method can't become is_old while this is done. >> >> 2) The VMOp is used to add breakpoint into the list >> VM_ChangeBreakpoints set_breakpoint(VM_ChangeBreakpoints::SET_BREAKPOINT, &bp); >> VMThread::execute(&set_breakpoint); >> to call JvmtiBreakpoints::set_at_safepoint() >> that can modify JvmtiBreakpoints list and set breakpoint in safepoint without synchronization. >> >> So it might be possible that class redefinition VM_RedefineClasses operation that redefine the class with this breakpoint happens between steps 1) and 2) >> VM_RedefineClasses::redefine_single_class() >> clear all class-related breakpoints in the JvmtiBreakpoints, however the "problematic" breakpoint is in VMThread queue and thus we are still continue to do this operation. >> So in the step 2) the the JvmtiBreakpoint with 'is_old' method is added to the JvmtiBreakpoints and breakpoint is set. >> >> Then old method mights be purged any time once they are not on the stack and any access to this breakpoint could lead to usage of Metthod* _method pointing to deallocated metaspace. >> >> The VM_RedefineClasses clear all breakpoints so it is correct just to don't proceed with current breakpoint also. >> >> Looks, like very unlikely but reproducing with stress test after some time. >> Verified that the crash is not reproduced anymore with corresponding test after the fix. >> >> Many thanks to Coleen for detailed explanation of class redefinition. > > Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/hotspot/share/prims/jvmtiImpl.cpp > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> > - Update src/hotspot/share/prims/jvmtiImpl.cpp > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> Seems fine to me. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26031#pullrequestreview-2973380226 From dfuchs at openjdk.org Tue Jul 1 07:35:40 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 1 Jul 2025 07:35:40 GMT Subject: RFR: 8351413: Remove XML interchange in java.management/javax/management/modelmbean/DescriptorSupport In-Reply-To: <2rJne6yOnugYd-8O9FcZisLuyooQjTspKz0FUDfEYzw=.0c64bc01-3ffe-4f51-93c3-d81ed91ca325@github.com> References: <2rJne6yOnugYd-8O9FcZisLuyooQjTspKz0FUDfEYzw=.0c64bc01-3ffe-4f51-93c3-d81ed91ca325@github.com> Message-ID: On Mon, 9 Jun 2025 17:37:16 GMT, Kevin Walls wrote: > Removal of an obscure historical feature, following on from its deprecation for removal in: > > 8347433: Deprecate XML interchange in java.management/javax/management/modelmbean/DescriptorSupport for removal The changes look reasonable. Please get a Reviewer from serviceability too before integrating. ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25697#pullrequestreview-2973919189 From asemenov at openjdk.org Tue Jul 1 07:38:31 2025 From: asemenov at openjdk.org (Artem Semenov) Date: Tue, 1 Jul 2025 07:38:31 GMT Subject: RFR: 8360664: Null pointer dereference in src/hotspot/share/prims/jvmtiTagMap.cpp in IterateOverHeapObjectClosure::do_object() [v4] In-Reply-To: References: Message-ID: > The defect has been detected and confirmed in the function ```IterateOverHeapObjectClosure::do_object()``` located in the file ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis. This defect can potentially lead to a null pointer dereference. > > The pointer ```oop o``` is passed to the constructor of the CallbackWrapper class, where it is dereferenced without a null check. Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: Updated the text of assert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26002/files - new: https://git.openjdk.org/jdk/pull/26002/files/88f1e494..3c810260 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26002&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26002&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26002.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26002/head:pull/26002 PR: https://git.openjdk.org/jdk/pull/26002 From sspitsyn at openjdk.org Tue Jul 1 08:41:41 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 1 Jul 2025 08:41:41 GMT Subject: RFR: 8284016: Normalize handshake closure names [v3] In-Reply-To: References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com> Message-ID: On Mon, 30 Jun 2025 11:53:36 GMT, Anton Artemov wrote: > I reverted closure names changes in JVMT files. Thanks! Unification is good in general but there is a price to pay. So, we are normally balancing among different requirements. :) The `HSClosure` suffix is not perfect either because `HS` normally stands for HotSpot. But I can be wrong with this assumption. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2176851022 From kevinw at openjdk.org Tue Jul 1 08:52:56 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 1 Jul 2025 08:52:56 GMT Subject: RFR: 8359809: AttributeList, RoleList and UnresolvedRoleList should never accept other types of Object [v5] In-Reply-To: References: Message-ID: > The classes javax.management.AttributeList, and javax.management.relation.RoleList and UnresolvedRoleList, have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called. > > This feature should be removed, and these classes should never accept the wrong kind of Object. Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: - Further doc update - Test udpate (listIterator) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25856/files - new: https://git.openjdk.org/jdk/pull/25856/files/8b36d3e5..a2a28dde Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25856&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25856&range=03-04 Stats: 17 lines in 4 files changed: 14 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25856.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25856/head:pull/25856 PR: https://git.openjdk.org/jdk/pull/25856 From sspitsyn at openjdk.org Tue Jul 1 09:02:41 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 1 Jul 2025 09:02:41 GMT Subject: RFR: 8284016: Normalize handshake closure names [v3] In-Reply-To: <9DJF2VLI5jAPld-i8CiS7Dq-1cboTORtVdHzgNRLhpo=.fc678446-b706-49f9-9cdb-7fb97eeaf24d@github.com> References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com> <9DJF2VLI5jAPld-i8CiS7Dq-1cboTORtVdHzgNRLhpo=.fc678446-b706-49f9-9cdb-7fb97eeaf24d@github.com> Message-ID: On Mon, 30 Jun 2025 11:57:23 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> There are many classes inherited from the `HandshakeClosure` class, but they do not follow the same naming convention. In this PR we address this issue, all names are normalized in the following way: >> >> `XXXDummyClassNameClosure -> XXXDummyClassNameHandshakeClosure` >> >> or >> >> `XXXDummyClassNameHandshake -> XXXDummyClassNameHandshakeClosure` >> >> or >> >> `XXXStrangeClassName -> SomewhatSimilarNameHandshakeClosure` >> >> Tested in GHA and tiers 1 - 3. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8284016: Reverted closure names in JVMTI This looks okay in general. I've posted several nits though. src/hotspot/share/classfile/javaClasses.cpp line 1980: > 1978: ResourceMark rm(THREAD); > 1979: HandleMark hm(THREAD); > 1980: GetStackTraceHandshakeClosure gstc(Handle(THREAD, java_thread)); Nit: A suggestion to rename: `gstc` => `gsthc` or `gstc` => `hc` or `gstc` => `cl`. src/hotspot/share/prims/whitebox.cpp line 2288: > 2286: }; > 2287: > 2288: ReadMonitorsHandshakeClosure rmc; Nit: A suggestion to rename: `rmc` => `rmhc` or `rmc` => `cl`. src/hotspot/share/prims/whitebox.cpp line 2319: > 2317: jint num_threads_completed() const { return _num_threads_completed; } > 2318: }; > 2319: TraceSelfHandshakeClosure tsc(Thread::current()); Nit: A suggestion to rename: `tsc` => `tshc` or `tsc` => `cl`. src/hotspot/share/prims/whitebox.cpp line 2357: > 2355: bool is_alive = tlh.cv_internal_thread_to_JavaThread(thread_handle, &target, nullptr); > 2356: if (is_alive) { > 2357: TraceSelfHandshakeClosure* tsc = new TraceSelfHandshakeClosure(target); Nit: A suggestion to rename: `tsc` => `tshc` or `tsc` => `cl`. src/hotspot/share/runtime/synchronizer.cpp line 1837: > 1835: // A JavaThread needs to handshake in order to safely free the > 1836: // ObjectMonitors that were deflated in this cycle. > 1837: DeflationHandshakeClosure hfd_hc; Nit: Rename: `hfd_hc` => `dhc` or `hfd_hc` => `cl`. src/hotspot/share/runtime/vmThread.cpp line 456: > 454: if (HandshakeALot) { > 455: MutexUnlocker mul(VMOperation_lock); > 456: ALotOfHandshakeClosure hal_cl; Nit: Rename: `hal_cl` => `aohc` or `hfd_hc` => `cl`. ------------- PR Review: https://git.openjdk.org/jdk/pull/26014#pullrequestreview-2974276487 PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2176875478 PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2176885943 PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2176889645 PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2176891619 PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2176908630 PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2176911514 From sspitsyn at openjdk.org Tue Jul 1 09:13:40 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 1 Jul 2025 09:13:40 GMT Subject: RFR: 8360664: Null pointer dereference in src/hotspot/share/prims/jvmtiTagMap.cpp in IterateOverHeapObjectClosure::do_object() [v4] In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 07:38:31 GMT, Artem Semenov wrote: >> The defect has been detected and confirmed in the function ```IterateOverHeapObjectClosure::do_object()``` located in the file ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis. This defect can potentially lead to a null pointer dereference. >> >> The pointer ```oop o``` is passed to the constructor of the CallbackWrapper class, where it is dereferenced without a null check. > > Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: > > Updated the text of assert This looks okay. However, I agree with David it is not going to address the issue with static analysis tool. Is it right? Also, why are there two bugs associated with this PR? ------------- PR Review: https://git.openjdk.org/jdk/pull/26002#pullrequestreview-2974392851 From sspitsyn at openjdk.org Tue Jul 1 09:19:40 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 1 Jul 2025 09:19:40 GMT Subject: RFR: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in JvmtiBreakpoints::clearall_in_class_at_safepoint [v3] In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 03:17:41 GMT, Leonid Mesnik wrote: >> The segv/eav happens in the case if JvmtiBreakpoint::_method's class redefined old between getting the Method* from jmethodid in the >> JvmtiEnv::SetBreakpoint(Method* method, jlocation location) {..} and >> and actual setting breakpoint in the VM operation VM_ChangeBreakpoints. >> >> Here are details: >> The breakpoint is set in 2 steps. >> 1) method jvmti_SetBreakpoint(jvmtiEnv* env, jmethodID method, jlocation location) convert jmethodID to Method* and call >> JvmtiEnv::SetBreakpoint(Method* method, jlocation location) >> where >> JvmtiBreakpoint bp(method, location); >> is created with this Method* >> Note: it is done while thread is in VM state, so Method can't become is_old while this is done. >> >> 2) The VMOp is used to add breakpoint into the list >> VM_ChangeBreakpoints set_breakpoint(VM_ChangeBreakpoints::SET_BREAKPOINT, &bp); >> VMThread::execute(&set_breakpoint); >> to call JvmtiBreakpoints::set_at_safepoint() >> that can modify JvmtiBreakpoints list and set breakpoint in safepoint without synchronization. >> >> So it might be possible that class redefinition VM_RedefineClasses operation that redefine the class with this breakpoint happens between steps 1) and 2) >> VM_RedefineClasses::redefine_single_class() >> clear all class-related breakpoints in the JvmtiBreakpoints, however the "problematic" breakpoint is in VMThread queue and thus we are still continue to do this operation. >> So in the step 2) the the JvmtiBreakpoint with 'is_old' method is added to the JvmtiBreakpoints and breakpoint is set. >> >> Then old method mights be purged any time once they are not on the stack and any access to this breakpoint could lead to usage of Metthod* _method pointing to deallocated metaspace. >> >> The VM_RedefineClasses clear all breakpoints so it is correct just to don't proceed with current breakpoint also. >> >> Looks, like very unlikely but reproducing with stress test after some time. >> Verified that the crash is not reproduced anymore with corresponding test after the fix. >> >> Many thanks to Coleen for detailed explanation of class redefinition. > > Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/hotspot/share/prims/jvmtiImpl.cpp > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> > - Update src/hotspot/share/prims/jvmtiImpl.cpp > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> Looks good. Please, ignore my previous comment as I agree with current approach. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26031#pullrequestreview-2974422198 From asemenov at openjdk.org Tue Jul 1 09:30:48 2025 From: asemenov at openjdk.org (Artem Semenov) Date: Tue, 1 Jul 2025 09:30:48 GMT Subject: RFR: 8360664: Null pointer dereference in src/hotspot/share/prims/jvmtiTagMap.cpp in IterateOverHeapObjectClosure::do_object() [v4] In-Reply-To: References: Message-ID: <-TxHtvHHWA__8tvyNl39JXzfsGaKoL3uqDSwc7qIGqA=.d1d78d29-9a83-4d10-bb9a-5579d91a8b63@github.com> On Tue, 1 Jul 2025 09:11:06 GMT, Serguei Spitsyn wrote: > This looks okay. However, I agree with David it is not going to address the issue with static analysis tool. Is it right? Also, why are there two bugs associated with this PR? Because there are two identical analyzer detections in similar code sections of this file. I created one ticket for each detection. However, I fixed both issues with a single PR. Regarding the analyzer, we will rerun the analysis with assert enabled and check if it helps to suppress the analyzer warnings ------------- PR Comment: https://git.openjdk.org/jdk/pull/26002#issuecomment-3022949352 From sspitsyn at openjdk.org Tue Jul 1 09:33:31 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 1 Jul 2025 09:33:31 GMT Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch [v7] In-Reply-To: References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com> Message-ID: On Mon, 30 Jun 2025 11:24:28 GMT, Kevin Walls wrote: >> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread. This is hard to reproduce but a thread that has since terminated can provoke a crash. Recognise this and return a null ThreadSnapshot. > > Kevin Walls 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 13 additional commits since the last revision: > > - remove test definition changes > - TLH: use cv_internal_thread_to_JavaThread() > - Merge remote-tracking branch 'upstream/master' into 8359870_threadexited > - Test requires: permit linux debug testing > - comment update > - comment update > - newline > - Test fails on minimal VM: require jvmti feature > - Correct THROW macro > - ThreadDumper thread count > - ... and 3 more: https://git.openjdk.org/jdk/compare/88ec329a...e2043438 Looks good. test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java line 172: > 170: } > 171: } > 172: Nit: It seems that an unneeded extra empty line was added at the end of file. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25958#pullrequestreview-2974497586 PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2176996670 From kevinw at openjdk.org Tue Jul 1 09:33:29 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 1 Jul 2025 09:33:29 GMT Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch [v8] In-Reply-To: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com> References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com> Message-ID: <877zCTrsEsy0Onpp7jSkwb7fnRLJyiy6vi-5Z2Gfl7A=.3764d4da-6373-4c52-bca9-c38b3534339d@github.com> > ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread. This is hard to reproduce but a thread that has since terminated can provoke a crash. Recognise this and return a null ThreadSnapshot. Kevin Walls has updated the pull request incrementally with three additional commits since the last revision: - Update src/hotspot/share/services/threadService.cpp Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> - Update src/hotspot/share/services/threadService.cpp Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> - Update src/hotspot/share/services/threadService.cpp Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25958/files - new: https://git.openjdk.org/jdk/pull/25958/files/e2043438..d56e9d16 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25958&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25958&range=06-07 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25958.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25958/head:pull/25958 PR: https://git.openjdk.org/jdk/pull/25958 From kevinw at openjdk.org Tue Jul 1 09:33:31 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 1 Jul 2025 09:33:31 GMT Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch [v7] In-Reply-To: References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com> Message-ID: On Tue, 1 Jul 2025 03:01:24 GMT, David Holmes wrote: >> Kevin Walls 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 13 additional commits since the last revision: >> >> - remove test definition changes >> - TLH: use cv_internal_thread_to_JavaThread() >> - Merge remote-tracking branch 'upstream/master' into 8359870_threadexited >> - Test requires: permit linux debug testing >> - comment update >> - comment update >> - newline >> - Test fails on minimal VM: require jvmti feature >> - Correct THROW macro >> - ThreadDumper thread count >> - ... and 3 more: https://git.openjdk.org/jdk/compare/88ec329a...e2043438 > > src/hotspot/share/services/threadService.cpp line 1450: > >> 1448: >> 1449: if (!has_javathread && !is_virtual) { >> 1450: return nullptr; // thread terminated > > Suggestion: > > return nullptr; // thread terminated so not of interest > > It took me a lot of backtracking in the Java code to find ThreadContainer which finally stated that only live threads are of interest, so an expanded comment here would help me. ( I was ready to suggest we should be creating a `ThreadSnapshot` that represents the terminated thread.) Yes, although we could return _something_ for a terminated thread, that seems like a fiction that might do us no good, forgetting it and moving on seems good... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25958#discussion_r2176995651 From duke at openjdk.org Tue Jul 1 09:39:22 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 1 Jul 2025 09:39:22 GMT Subject: RFR: 8284016: Normalize handshake closure names [v4] In-Reply-To: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com> References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com> Message-ID: > Hi, please consider the following changes: > > There are many classes inherited from the `HandshakeClosure` class, but they do not follow the same naming convention. In this PR we address this issue, all names are normalized in the following way: > > `XXXDummyClassNameClosure -> XXXDummyClassNameHandshakeClosure` > > or > > `XXXDummyClassNameHandshake -> XXXDummyClassNameHandshakeClosure` > > or > > `XXXStrangeClassName -> SomewhatSimilarNameHandshakeClosure` > > Tested in GHA and tiers 1 - 3. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8284016: Addressed reviewer's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26014/files - new: https://git.openjdk.org/jdk/pull/26014/files/65b9ecc5..bb95404c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26014&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26014&range=02-03 Stats: 32 lines in 5 files changed: 0 ins; 0 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/26014.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26014/head:pull/26014 PR: https://git.openjdk.org/jdk/pull/26014 From duke at openjdk.org Tue Jul 1 09:39:22 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 1 Jul 2025 09:39:22 GMT Subject: RFR: 8284016: Normalize handshake closure names [v3] In-Reply-To: References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com> <9DJF2VLI5jAPld-i8CiS7Dq-1cboTORtVdHzgNRLhpo=.fc678446-b706-49f9-9cdb-7fb97eeaf24d@github.com> Message-ID: On Tue, 1 Jul 2025 08:46:37 GMT, Serguei Spitsyn wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8284016: Reverted closure names in JVMTI > > src/hotspot/share/classfile/javaClasses.cpp line 1980: > >> 1978: ResourceMark rm(THREAD); >> 1979: HandleMark hm(THREAD); >> 1980: GetStackTraceHandshakeClosure gstc(Handle(THREAD, java_thread)); > > Nit: A suggestion to rename: `gstc` => `gsthc` or `gstc` => `hc` or `gstc` => `cl`. Thanks, makes sense, addressed in the latest commit. > src/hotspot/share/prims/whitebox.cpp line 2288: > >> 2286: }; >> 2287: >> 2288: ReadMonitorsHandshakeClosure rmc; > > Nit: A suggestion to rename: `rmc` => `rmhc` or `rmc` => `cl`. Thanks, makes sense, addressed in the latest commit. > src/hotspot/share/prims/whitebox.cpp line 2357: > >> 2355: bool is_alive = tlh.cv_internal_thread_to_JavaThread(thread_handle, &target, nullptr); >> 2356: if (is_alive) { >> 2357: TraceSelfHandshakeClosure* tsc = new TraceSelfHandshakeClosure(target); > > Nit: A suggestion to rename: `tsc` => `tshc` or `tsc` => `cl`. Thanks, makes sense, addressed in the latest commit. > src/hotspot/share/runtime/vmThread.cpp line 456: > >> 454: if (HandshakeALot) { >> 455: MutexUnlocker mul(VMOperation_lock); >> 456: ALotOfHandshakeClosure hal_cl; > > Nit: Rename: `hal_cl` => `aohc` or `hfd_hc` => `cl`. Thanks, makes sense, addressed in the latest commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2177016990 PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2177017247 PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2177017485 PR Review Comment: https://git.openjdk.org/jdk/pull/26014#discussion_r2177017688 From sspitsyn at openjdk.org Tue Jul 1 09:49:42 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 1 Jul 2025 09:49:42 GMT Subject: RFR: 8360664: Null pointer dereference in src/hotspot/share/prims/jvmtiTagMap.cpp in IterateOverHeapObjectClosure::do_object() [v4] In-Reply-To: <-TxHtvHHWA__8tvyNl39JXzfsGaKoL3uqDSwc7qIGqA=.d1d78d29-9a83-4d10-bb9a-5579d91a8b63@github.com> References: <-TxHtvHHWA__8tvyNl39JXzfsGaKoL3uqDSwc7qIGqA=.d1d78d29-9a83-4d10-bb9a-5579d91a8b63@github.com> Message-ID: On Tue, 1 Jul 2025 09:26:59 GMT, Artem Semenov wrote: > Because there are two identical analyzer detections in similar code sections of this file. I created one ticket for each detection. However, I fixed both issues with a single PR. Is it a specific requirement to create a separate bug for each complain? Normally, one bug for both has to be enough. One bug would be even enough for multiple complains in several files of the same development area. > Regarding the analyzer, we will rerun the analysis with assert enabled and check if it helps to suppress the analyzer warnings Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26002#issuecomment-3023050372 PR Comment: https://git.openjdk.org/jdk/pull/26002#issuecomment-3023059816 From sspitsyn at openjdk.org Tue Jul 1 09:53:39 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 1 Jul 2025 09:53:39 GMT Subject: RFR: 8284016: Normalize handshake closure names [v4] In-Reply-To: References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com> Message-ID: <0t5vpK_Z-2WRiRvG6gUsq-wfR6_CUUG4yAwPcxNnPmw=.5c6ef9ce-6fdd-469d-a4c8-bdf8d4eea82d@github.com> On Tue, 1 Jul 2025 09:39:22 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> There are many classes inherited from the `HandshakeClosure` class, but they do not follow the same naming convention. In this PR we address this issue, all names are normalized in the following way: >> >> `XXXDummyClassNameClosure -> XXXDummyClassNameHandshakeClosure` >> >> or >> >> `XXXDummyClassNameHandshake -> XXXDummyClassNameHandshakeClosure` >> >> or >> >> `XXXStrangeClassName -> SomewhatSimilarNameHandshakeClosure` >> >> Tested in GHA and tiers 1 - 3. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8284016: Addressed reviewer's comments Thank you for the update. Looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26014#pullrequestreview-2974608407 From asemenov at openjdk.org Tue Jul 1 10:14:40 2025 From: asemenov at openjdk.org (Artem Semenov) Date: Tue, 1 Jul 2025 10:14:40 GMT Subject: RFR: 8360664: Null pointer dereference in src/hotspot/share/prims/jvmtiTagMap.cpp in IterateOverHeapObjectClosure::do_object() [v4] In-Reply-To: References: <-TxHtvHHWA__8tvyNl39JXzfsGaKoL3uqDSwc7qIGqA=.d1d78d29-9a83-4d10-bb9a-5579d91a8b63@github.com> Message-ID: On Tue, 1 Jul 2025 09:45:21 GMT, Serguei Spitsyn wrote: > > Because there are two identical analyzer detections in similar code sections of this file. I created one ticket for each detection. However, I fixed both issues with a single PR. > > Is it a specific requirement to create a separate bug for each complain? Normally, one bug for both has to be enough. One bug would be even enough for multiple complains in several files of the same development area. TNX ------------- PR Comment: https://git.openjdk.org/jdk/pull/26002#issuecomment-3023162703 From sspitsyn at openjdk.org Tue Jul 1 10:15:42 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 1 Jul 2025 10:15:42 GMT Subject: RFR: 8351413: Remove XML interchange in java.management/javax/management/modelmbean/DescriptorSupport In-Reply-To: <2rJne6yOnugYd-8O9FcZisLuyooQjTspKz0FUDfEYzw=.0c64bc01-3ffe-4f51-93c3-d81ed91ca325@github.com> References: <2rJne6yOnugYd-8O9FcZisLuyooQjTspKz0FUDfEYzw=.0c64bc01-3ffe-4f51-93c3-d81ed91ca325@github.com> Message-ID: <5KWnC8pnEXr4Vo_kL09Zn6fvR5AeszMX2APiogVLwmQ=.3902890e-16aa-4430-b252-3a2978fcfe42@github.com> On Mon, 9 Jun 2025 17:37:16 GMT, Kevin Walls wrote: > Removal of an obscure historical feature, following on from its deprecation for removal in: > > 8347433: Deprecate XML interchange in java.management/javax/management/modelmbean/DescriptorSupport for removal This looks okay. The CSR's "Compatibility Risk Description" should not be empty. Also reviewed the RN and added a minor suggestion. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25697#pullrequestreview-2974681915 From kevinw at openjdk.org Tue Jul 1 10:20:12 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 1 Jul 2025 10:20:12 GMT Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch [v9] In-Reply-To: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com> References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com> Message-ID: > ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread. This is hard to reproduce but a thread that has since terminated can provoke a crash. Recognise this and return a null ThreadSnapshot. Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: - Merge branch '8359870_threadexited' of https://github.com/kevinjwalls/jdk into 8359870_threadexited - Feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25958/files - new: https://git.openjdk.org/jdk/pull/25958/files/d56e9d16..93ad155d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25958&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25958&range=07-08 Stats: 3 lines in 3 files changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25958.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25958/head:pull/25958 PR: https://git.openjdk.org/jdk/pull/25958 From kevinw at openjdk.org Tue Jul 1 10:37:38 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 1 Jul 2025 10:37:38 GMT Subject: RFR: 8351413: Remove XML interchange in java.management/javax/management/modelmbean/DescriptorSupport In-Reply-To: <2rJne6yOnugYd-8O9FcZisLuyooQjTspKz0FUDfEYzw=.0c64bc01-3ffe-4f51-93c3-d81ed91ca325@github.com> References: <2rJne6yOnugYd-8O9FcZisLuyooQjTspKz0FUDfEYzw=.0c64bc01-3ffe-4f51-93c3-d81ed91ca325@github.com> Message-ID: On Mon, 9 Jun 2025 17:37:16 GMT, Kevin Walls wrote: > Removal of an obscure historical feature, following on from its deprecation for removal in: > > 8347433: Deprecate XML interchange in java.management/javax/management/modelmbean/DescriptorSupport for removal Thanks Daniel! Thanks Serguei, have addressed those points. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25697#issuecomment-3023296826 From coleenp at openjdk.org Tue Jul 1 11:23:45 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 1 Jul 2025 11:23:45 GMT Subject: RFR: 8284016: Normalize handshake closure names [v4] In-Reply-To: References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com> Message-ID: On Tue, 1 Jul 2025 09:39:22 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> There are many classes inherited from the `HandshakeClosure` class, but they do not follow the same naming convention. In this PR we address this issue, all names are normalized in the following way: >> >> `XXXDummyClassNameClosure -> XXXDummyClassNameHandshakeClosure` >> >> or >> >> `XXXDummyClassNameHandshake -> XXXDummyClassNameHandshakeClosure` >> >> or >> >> `XXXStrangeClassName -> SomewhatSimilarNameHandshakeClosure` >> >> Tested in GHA and tiers 1 - 3. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8284016: Addressed reviewer's comments Still looks good. So the pattern is that something that inherits directly from HandshakeClosure is TheThingHandshakeClosure and in the case of JVMTI further inheritance has a shorter name. Seems fine. So many handshakes! ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26014#pullrequestreview-2974982990 From coleenp at openjdk.org Tue Jul 1 11:56:43 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 1 Jul 2025 11:56:43 GMT Subject: RFR: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in JvmtiBreakpoints::clearall_in_class_at_safepoint [v3] In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 03:17:41 GMT, Leonid Mesnik wrote: >> The segv/eav happens in the case if JvmtiBreakpoint::_method's class redefined old between getting the Method* from jmethodid in the >> JvmtiEnv::SetBreakpoint(Method* method, jlocation location) {..} and >> and actual setting breakpoint in the VM operation VM_ChangeBreakpoints. >> >> Here are details: >> The breakpoint is set in 2 steps. >> 1) method jvmti_SetBreakpoint(jvmtiEnv* env, jmethodID method, jlocation location) convert jmethodID to Method* and call >> JvmtiEnv::SetBreakpoint(Method* method, jlocation location) >> where >> JvmtiBreakpoint bp(method, location); >> is created with this Method* >> Note: it is done while thread is in VM state, so Method can't become is_old while this is done. >> >> 2) The VMOp is used to add breakpoint into the list >> VM_ChangeBreakpoints set_breakpoint(VM_ChangeBreakpoints::SET_BREAKPOINT, &bp); >> VMThread::execute(&set_breakpoint); >> to call JvmtiBreakpoints::set_at_safepoint() >> that can modify JvmtiBreakpoints list and set breakpoint in safepoint without synchronization. >> >> So it might be possible that class redefinition VM_RedefineClasses operation that redefine the class with this breakpoint happens between steps 1) and 2) >> VM_RedefineClasses::redefine_single_class() >> clear all class-related breakpoints in the JvmtiBreakpoints, however the "problematic" breakpoint is in VMThread queue and thus we are still continue to do this operation. >> So in the step 2) the the JvmtiBreakpoint with 'is_old' method is added to the JvmtiBreakpoints and breakpoint is set. >> >> Then old method mights be purged any time once they are not on the stack and any access to this breakpoint could lead to usage of Metthod* _method pointing to deallocated metaspace. >> >> The VM_RedefineClasses clear all breakpoints so it is correct just to don't proceed with current breakpoint also. >> >> Looks, like very unlikely but reproducing with stress test after some time. >> Verified that the crash is not reproduced anymore with corresponding test after the fix. >> >> Many thanks to Coleen for detailed explanation of class redefinition. > > Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/hotspot/share/prims/jvmtiImpl.cpp > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> > - Update src/hotspot/share/prims/jvmtiImpl.cpp > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> This looks great. Thank you for sorting through all this code and my speculation about the problem to find the real problem. For the record, I don't think my change to remove is_running_emcp() caused this or any bug. I wrote a test case for it yesterday and that code seems fine. Nice work finding the real problem here and the straightforward solution. There are several places in the JVM where we have to check for is_old() methods to exclude them for various things. is_old() methods leaking into places is a common bug pattern. This change is consistent with this approach of fixing this. src/hotspot/share/prims/jvmtiImpl.cpp line 262: > 260: } > 261: > 262: // ensure that bp._method is not deallocated before VM_ChangeBreakpoints::doit() Suggestion: // Ensure that bp._method is not deallocated before VM_ChangeBreakpoints::doit(). src/hotspot/share/prims/jvmtiImpl.cpp line 274: > 272: } > 273: > 274: // ensure that bp._method is not deallocated before VM_ChangeBreakpoints::doit() Suggestion: // Ensure that bp._method is not deallocated before VM_ChangeBreakpoints::doit(). ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26031#pullrequestreview-2975077594 PR Review Comment: https://git.openjdk.org/jdk/pull/26031#discussion_r2177385911 PR Review Comment: https://git.openjdk.org/jdk/pull/26031#discussion_r2177386666 From duke at openjdk.org Tue Jul 1 12:19:41 2025 From: duke at openjdk.org (duke) Date: Tue, 1 Jul 2025 12:19:41 GMT Subject: RFR: 8284016: Normalize handshake closure names [v4] In-Reply-To: References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com> Message-ID: On Tue, 1 Jul 2025 09:39:22 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> There are many classes inherited from the `HandshakeClosure` class, but they do not follow the same naming convention. In this PR we address this issue, all names are normalized in the following way: >> >> `XXXDummyClassNameClosure -> XXXDummyClassNameHandshakeClosure` >> >> or >> >> `XXXDummyClassNameHandshake -> XXXDummyClassNameHandshakeClosure` >> >> or >> >> `XXXStrangeClassName -> SomewhatSimilarNameHandshakeClosure` >> >> Tested in GHA and tiers 1 - 3. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8284016: Addressed reviewer's comments @toxaart Your change (at version bb95404ced78f32f161bc1982def196a6bde6f30) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26014#issuecomment-3023766086 From asemenov at openjdk.org Tue Jul 1 12:49:39 2025 From: asemenov at openjdk.org (Artem Semenov) Date: Tue, 1 Jul 2025 12:49:39 GMT Subject: RFR: 8360664: Null pointer dereference in src/hotspot/share/prims/jvmtiTagMap.cpp in IterateOverHeapObjectClosure::do_object() [v3] In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 03:13:06 GMT, David Holmes wrote: > Same with the other assertion please. Though as @plummercj states I don't see how this will help with the static analysis tool. done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26002#discussion_r2177518930 From lmesnik at openjdk.org Tue Jul 1 16:01:10 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 1 Jul 2025 16:01:10 GMT Subject: RFR: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in JvmtiBreakpoints::clearall_in_class_at_safepoint [v4] In-Reply-To: References: Message-ID: <3z3NAFRDRuiYSdzCva5L7_4s3xWtaWtj74vEnJW7Tpc=.dc62ff8d-589d-4437-959c-82a84e0bec9e@github.com> > The segv/eav happens in the case if JvmtiBreakpoint::_method's class redefined old between getting the Method* from jmethodid in the > JvmtiEnv::SetBreakpoint(Method* method, jlocation location) {..} and > and actual setting breakpoint in the VM operation VM_ChangeBreakpoints. > > Here are details: > The breakpoint is set in 2 steps. > 1) method jvmti_SetBreakpoint(jvmtiEnv* env, jmethodID method, jlocation location) convert jmethodID to Method* and call > JvmtiEnv::SetBreakpoint(Method* method, jlocation location) > where > JvmtiBreakpoint bp(method, location); > is created with this Method* > Note: it is done while thread is in VM state, so Method can't become is_old while this is done. > > 2) The VMOp is used to add breakpoint into the list > VM_ChangeBreakpoints set_breakpoint(VM_ChangeBreakpoints::SET_BREAKPOINT, &bp); > VMThread::execute(&set_breakpoint); > to call JvmtiBreakpoints::set_at_safepoint() > that can modify JvmtiBreakpoints list and set breakpoint in safepoint without synchronization. > > So it might be possible that class redefinition VM_RedefineClasses operation that redefine the class with this breakpoint happens between steps 1) and 2) > VM_RedefineClasses::redefine_single_class() > clear all class-related breakpoints in the JvmtiBreakpoints, however the "problematic" breakpoint is in VMThread queue and thus we are still continue to do this operation. > So in the step 2) the the JvmtiBreakpoint with 'is_old' method is added to the JvmtiBreakpoints and breakpoint is set. > > Then old method mights be purged any time once they are not on the stack and any access to this breakpoint could lead to usage of Metthod* _method pointing to deallocated metaspace. > > The VM_RedefineClasses clear all breakpoints so it is correct just to don't proceed with current breakpoint also. > > Looks, like very unlikely but reproducing with stress test after some time. > Verified that the crash is not reproduced anymore with corresponding test after the fix. > > Many thanks to Coleen for detailed explanation of class redefinition. Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: - Update src/hotspot/share/prims/jvmtiImpl.cpp Co-authored-by: Coleen Phillimore - Update src/hotspot/share/prims/jvmtiImpl.cpp Co-authored-by: Coleen Phillimore ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26031/files - new: https://git.openjdk.org/jdk/pull/26031/files/c7aaa804..242880c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26031&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26031&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26031.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26031/head:pull/26031 PR: https://git.openjdk.org/jdk/pull/26031 From lmesnik at openjdk.org Tue Jul 1 16:02:53 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 1 Jul 2025 16:02:53 GMT Subject: RFR: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in JvmtiBreakpoints::clearall_in_class_at_safepoint [v3] In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 11:54:00 GMT, Coleen Phillimore wrote: >> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update src/hotspot/share/prims/jvmtiImpl.cpp >> >> Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> >> - Update src/hotspot/share/prims/jvmtiImpl.cpp >> >> Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> > > This looks great. Thank you for sorting through all this code and my speculation about the problem to find the real problem. For the record, I don't think my change to remove is_running_emcp() caused this or any bug. I wrote a test case for it yesterday and that code seems fine. Nice work finding the real problem here and the straightforward solution. > There are several places in the JVM where we have to check for is_old() methods to exclude them for various things. is_old() methods leaking into places is a common bug pattern. This change is consistent with this approach of fixing this. @coleenp Thanks. When I mention that your change is related to this problem, I meant related to this area. The change was correct and bug existed before. @dholmes-ora , @sspitsyn Thank you for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26031#issuecomment-3024630778 From lmesnik at openjdk.org Tue Jul 1 17:07:41 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 1 Jul 2025 17:07:41 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v12] In-Reply-To: <6WPU5dGPFJ38KnDO88FvRIqQsclgmajiQ2RRKVm0ZCw=.3575812c-b388-42e6-8396-8c39162b6dc0@github.com> References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> <6WPU5dGPFJ38KnDO88FvRIqQsclgmajiQ2RRKVm0ZCw=.3575812c-b388-42e6-8396-8c39162b6dc0@github.com> Message-ID: On Tue, 1 Jul 2025 01:55:48 GMT, Coleen Phillimore wrote: >> I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. >> Tested with test. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove comment. Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25857#pullrequestreview-2976286692 From coleenp at openjdk.org Tue Jul 1 17:10:39 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 1 Jul 2025 17:10:39 GMT Subject: RFR: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in JvmtiBreakpoints::clearall_in_class_at_safepoint [v4] In-Reply-To: <3z3NAFRDRuiYSdzCva5L7_4s3xWtaWtj74vEnJW7Tpc=.dc62ff8d-589d-4437-959c-82a84e0bec9e@github.com> References: <3z3NAFRDRuiYSdzCva5L7_4s3xWtaWtj74vEnJW7Tpc=.dc62ff8d-589d-4437-959c-82a84e0bec9e@github.com> Message-ID: <4ExBfUTBQLZWCprnXZKNIkm-62cqdVmFQ2yu2ki6L_M=.b507f587-58c6-4003-845a-bdfca6844302@github.com> On Tue, 1 Jul 2025 16:01:10 GMT, Leonid Mesnik wrote: >> The segv/eav happens in the case if JvmtiBreakpoint::_method's class redefined old between getting the Method* from jmethodid in the >> JvmtiEnv::SetBreakpoint(Method* method, jlocation location) {..} and >> and actual setting breakpoint in the VM operation VM_ChangeBreakpoints. >> >> Here are details: >> The breakpoint is set in 2 steps. >> 1) method jvmti_SetBreakpoint(jvmtiEnv* env, jmethodID method, jlocation location) convert jmethodID to Method* and call >> JvmtiEnv::SetBreakpoint(Method* method, jlocation location) >> where >> JvmtiBreakpoint bp(method, location); >> is created with this Method* >> Note: it is done while thread is in VM state, so Method can't become is_old while this is done. >> >> 2) The VMOp is used to add breakpoint into the list >> VM_ChangeBreakpoints set_breakpoint(VM_ChangeBreakpoints::SET_BREAKPOINT, &bp); >> VMThread::execute(&set_breakpoint); >> to call JvmtiBreakpoints::set_at_safepoint() >> that can modify JvmtiBreakpoints list and set breakpoint in safepoint without synchronization. >> >> So it might be possible that class redefinition VM_RedefineClasses operation that redefine the class with this breakpoint happens between steps 1) and 2) >> VM_RedefineClasses::redefine_single_class() >> clear all class-related breakpoints in the JvmtiBreakpoints, however the "problematic" breakpoint is in VMThread queue and thus we are still continue to do this operation. >> So in the step 2) the the JvmtiBreakpoint with 'is_old' method is added to the JvmtiBreakpoints and breakpoint is set. >> >> Then old method mights be purged any time once they are not on the stack and any access to this breakpoint could lead to usage of Metthod* _method pointing to deallocated metaspace. >> >> The VM_RedefineClasses clear all breakpoints so it is correct just to don't proceed with current breakpoint also. >> >> Looks, like very unlikely but reproducing with stress test after some time. >> Verified that the crash is not reproduced anymore with corresponding test after the fix. >> >> Many thanks to Coleen for detailed explanation of class redefinition. > > Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/hotspot/share/prims/jvmtiImpl.cpp > > Co-authored-by: Coleen Phillimore > - Update src/hotspot/share/prims/jvmtiImpl.cpp > > Co-authored-by: Coleen Phillimore Looks good. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26031#pullrequestreview-2976297700 From coleenp at openjdk.org Tue Jul 1 17:17:50 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 1 Jul 2025 17:17:50 GMT Subject: RFR: 8359707: Add classfile modification code to RedefineClassHelper [v12] In-Reply-To: <6WPU5dGPFJ38KnDO88FvRIqQsclgmajiQ2RRKVm0ZCw=.3575812c-b388-42e6-8396-8c39162b6dc0@github.com> References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> <6WPU5dGPFJ38KnDO88FvRIqQsclgmajiQ2RRKVm0ZCw=.3575812c-b388-42e6-8396-8c39162b6dc0@github.com> Message-ID: On Tue, 1 Jul 2025 01:55:48 GMT, Coleen Phillimore wrote: >> I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. >> Tested with test. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove comment. Thanks for the reviews Leonid, Serguei and David, and thanks for the help with ClassFile API Chen. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25857#issuecomment-3024888621 From coleenp at openjdk.org Tue Jul 1 17:17:51 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 1 Jul 2025 17:17:51 GMT Subject: Integrated: 8359707: Add classfile modification code to RedefineClassHelper In-Reply-To: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> References: <8en07k_m9sn6hOGto1UTTebvbH-9RamaW3mykHNoXpA=.4ed53870-b338-43e0-8f09-7be8487e2b12@github.com> Message-ID: On Tue, 17 Jun 2025 17:11:01 GMT, Coleen Phillimore wrote: > I copied this code for another test in the Valhalla repo and thought it would be a good utility function. It might be better written using the Classfile API. > Tested with test. This pull request has now been integrated. Changeset: e7a45003 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/e7a450038a47a76d2e616ebce2a7fa8a51e36ea4 Stats: 91 lines in 2 files changed: 44 ins; 43 del; 4 mod 8359707: Add classfile modification code to RedefineClassHelper Reviewed-by: lmesnik, dholmes, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/25857 From lmesnik at openjdk.org Tue Jul 1 17:25:44 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 1 Jul 2025 17:25:44 GMT Subject: Integrated: 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in JvmtiBreakpoints::clearall_in_class_at_safepoint In-Reply-To: References: Message-ID: <8IAR00IghKe6-kHzqImCF0nEG0EV-q6bkf5XeWR5ctA=.68e19495-8c9e-4844-98f7-60c355ea8fa9@github.com> On Sat, 28 Jun 2025 05:02:56 GMT, Leonid Mesnik wrote: > The segv/eav happens in the case if JvmtiBreakpoint::_method's class redefined old between getting the Method* from jmethodid in the > JvmtiEnv::SetBreakpoint(Method* method, jlocation location) {..} and > and actual setting breakpoint in the VM operation VM_ChangeBreakpoints. > > Here are details: > The breakpoint is set in 2 steps. > 1) method jvmti_SetBreakpoint(jvmtiEnv* env, jmethodID method, jlocation location) convert jmethodID to Method* and call > JvmtiEnv::SetBreakpoint(Method* method, jlocation location) > where > JvmtiBreakpoint bp(method, location); > is created with this Method* > Note: it is done while thread is in VM state, so Method can't become is_old while this is done. > > 2) The VMOp is used to add breakpoint into the list > VM_ChangeBreakpoints set_breakpoint(VM_ChangeBreakpoints::SET_BREAKPOINT, &bp); > VMThread::execute(&set_breakpoint); > to call JvmtiBreakpoints::set_at_safepoint() > that can modify JvmtiBreakpoints list and set breakpoint in safepoint without synchronization. > > So it might be possible that class redefinition VM_RedefineClasses operation that redefine the class with this breakpoint happens between steps 1) and 2) > VM_RedefineClasses::redefine_single_class() > clear all class-related breakpoints in the JvmtiBreakpoints, however the "problematic" breakpoint is in VMThread queue and thus we are still continue to do this operation. > So in the step 2) the the JvmtiBreakpoint with 'is_old' method is added to the JvmtiBreakpoints and breakpoint is set. > > Then old method mights be purged any time once they are not on the stack and any access to this breakpoint could lead to usage of Metthod* _method pointing to deallocated metaspace. > > The VM_RedefineClasses clear all breakpoints so it is correct just to don't proceed with current breakpoint also. > > Looks, like very unlikely but reproducing with stress test after some time. > Verified that the crash is not reproduced anymore with corresponding test after the fix. > > Many thanks to Coleen for detailed explanation of class redefinition. This pull request has now been integrated. Changeset: 282ee40a Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/282ee40a56af46521b94fe6e4c90e78b8f513b29 Stats: 14 lines in 1 file changed: 14 ins; 0 del; 0 mod 8359366: RunThese30M.java EXCEPTION_ACCESS_VIOLATION in JvmtiBreakpoints::clearall_in_class_at_safepoint Reviewed-by: coleenp, dholmes, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/26031 From kevinw at openjdk.org Tue Jul 1 18:20:41 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 1 Jul 2025 18:20:41 GMT Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch [v9] In-Reply-To: References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com> Message-ID: On Tue, 1 Jul 2025 10:20:12 GMT, Kevin Walls wrote: >> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread. This is hard to reproduce but a thread that has since terminated can provoke a crash. Recognise this and return a null ThreadSnapshot. > > Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch '8359870_threadexited' of https://github.com/kevinjwalls/jdk into 8359870_threadexited > - Feedback Thanks for all the feedback and reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25958#issuecomment-3025066011 From amenkov at openjdk.org Tue Jul 1 19:07:42 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 1 Jul 2025 19:07:42 GMT Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch [v9] In-Reply-To: References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com> Message-ID: On Tue, 1 Jul 2025 10:20:12 GMT, Kevin Walls wrote: >> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread. This is hard to reproduce but a thread that has since terminated can provoke a crash. Recognise this and return a null ThreadSnapshot. > > Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch '8359870_threadexited' of https://github.com/kevinjwalls/jdk into 8359870_threadexited > - Feedback Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25958#pullrequestreview-2976663584 From kevinw at openjdk.org Tue Jul 1 19:10:47 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 1 Jul 2025 19:10:47 GMT Subject: Integrated: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch In-Reply-To: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com> References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com> Message-ID: On Tue, 24 Jun 2025 17:00:19 GMT, Kevin Walls wrote: > ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread. This is hard to reproduce but a thread that has since terminated can provoke a crash. Recognise this and return a null ThreadSnapshot. This pull request has now been integrated. Changeset: 13a39278 Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/13a3927855da61fe27f3b43e5e4755d0c5ac5a16 Stats: 32 lines in 5 files changed: 22 ins; 2 del; 8 mod 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch Reviewed-by: amenkov, dholmes, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/25958 From amenkov at openjdk.org Wed Jul 2 01:55:48 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 2 Jul 2025 01:55:48 GMT Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with -fno-elide-constructors Message-ID: Currently jvmtiAgentList keeps agents in reversed order (new agents are added to the head of the list). To restore original order JvmtiAgentList::Iterator uses GrowableArray allocated in heap. Iterators for different agent types are returned by value, and the iterator class nas no custom copy ctor, so if the constructor not elides, GrowableArray is deallocated twice. The fix updates jvmtiAgentList to keep agents in the original order, agents are added to the tail. Iterator now needs only single pointer to next agent. Additionally removed `JvmtiAgentList::Iterator::next() const` method (it looks very strange as `next()` is expected to change state of the iterator). Testing: tier1..4,hs-tier5-svc ------------- Commit messages: - fix Changes: https://git.openjdk.org/jdk/pull/26083/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26083&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355960 Stats: 83 lines in 5 files changed: 27 ins; 28 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/26083.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26083/head:pull/26083 PR: https://git.openjdk.org/jdk/pull/26083 From duke at openjdk.org Wed Jul 2 06:52:48 2025 From: duke at openjdk.org (Anton Artemov) Date: Wed, 2 Jul 2025 06:52:48 GMT Subject: Integrated: 8284016: Normalize handshake closure names In-Reply-To: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com> References: <3MZO_Y636hhLaFN_TEP5GIPHS3ZD3UVV14nzmWexwP0=.72af617d-aac2-46c9-b825-9b5704061a75@github.com> Message-ID: On Fri, 27 Jun 2025 09:10:26 GMT, Anton Artemov wrote: > Hi, please consider the following changes: > > There are many classes inherited from the `HandshakeClosure` class, but they do not follow the same naming convention. In this PR we address this issue, all names are normalized in the following way: > > `XXXDummyClassNameClosure -> XXXDummyClassNameHandshakeClosure` > > or > > `XXXDummyClassNameHandshake -> XXXDummyClassNameHandshakeClosure` > > or > > `XXXStrangeClassName -> SomewhatSimilarNameHandshakeClosure` > > Tested in GHA and tiers 1 - 3. This pull request has now been integrated. Changeset: 0f1cd987 Author: Anton Artemov Committer: David Holmes URL: https://git.openjdk.org/jdk/commit/0f1cd987b3520eaeab31e9faf782d6f81050803a Stats: 116 lines in 18 files changed: 0 ins; 0 del; 116 mod 8284016: Normalize handshake closure names Reviewed-by: coleenp, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/26014 From dholmes at openjdk.org Wed Jul 2 07:19:43 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 2 Jul 2025 07:19:43 GMT Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with -fno-elide-constructors In-Reply-To: References: Message-ID: <_5NwWIsGk5KAsowrz20u62ynfb23KW_XIKlofA3Att0=.c40d9c15-5572-4187-ad15-490900c6b9b2@github.com> On Wed, 2 Jul 2025 01:47:59 GMT, Alex Menkov wrote: > Currently jvmtiAgentList keeps agents in reversed order (new agents are added to the head of the list). > To restore original order JvmtiAgentList::Iterator uses GrowableArray allocated in heap. > Iterators for different agent types are returned by value, and the iterator class nas no custom copy ctor, so if the constructor not elides, GrowableArray is deallocated twice. > > The fix updates jvmtiAgentList to keep agents in the original order, agents are added to the tail. > Iterator now needs only single pointer to next agent. > Additionally removed `JvmtiAgentList::Iterator::next() const` method (it looks very strange as `next()` is expected to change state of the iterator). > > Testing: tier1..4,hs-tier5-svc I'm not very familiar with these aspects of C++ but this seems to be a very complex solution to what sounds in JBS to be a pretty straight-forward problem. src/hotspot/share/prims/jvmtiAgentList.cpp line 35: > 33: > 34: JvmtiAgent* JvmtiAgentList::_head = nullptr; > 35: JvmtiAgent** JvmtiAgentList::_tail = nullptr; Why is the tail a pointer to a pointer? Sorry I'm not understanding how your list is being managed here. I'm trying to work out where you need acquire/release because I'm pretty sure it is missing where needed, but again I can't understand how you are actually constructing and using the list. src/hotspot/share/prims/jvmtiAgentList.cpp line 105: > 103: while (true) { > 104: // set _tail to address of agent->_next > 105: JvmtiAgent** tail = Atomic::load_acquire(&_tail); You don't need acquire semantics here as you are not doing anything with the `_tail` pointer value other than use it in relation to cmpxchg which provides fully memory barriers. ------------- PR Review: https://git.openjdk.org/jdk/pull/26083#pullrequestreview-2977985314 PR Review Comment: https://git.openjdk.org/jdk/pull/26083#discussion_r2179305538 PR Review Comment: https://git.openjdk.org/jdk/pull/26083#discussion_r2179284415 From dholmes at openjdk.org Wed Jul 2 07:43:48 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 2 Jul 2025 07:43:48 GMT Subject: RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch [v9] In-Reply-To: References: <0Q1PsFVW1d6lcQrKVhdLaNgHpLJXo2WusX6L9UOe5zo=.8903b8aa-57aa-4c5b-90c6-bd0f9c31de90@github.com> Message-ID: On Tue, 1 Jul 2025 10:20:12 GMT, Kevin Walls wrote: >> ThreadDumper/ThreadSnapshot need to handle a failure to resolve the native VM JavaThread from a java.lang.Thread. This is hard to reproduce but a thread that has since terminated can provoke a crash. Recognise this and return a null ThreadSnapshot. > > Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch '8359870_threadexited' of https://github.com/kevinjwalls/jdk into 8359870_threadexited > - Feedback Belated thumbs up from me too. ------------- PR Review: https://git.openjdk.org/jdk/pull/25958#pullrequestreview-2978088296 From kevinw at openjdk.org Wed Jul 2 09:04:51 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 2 Jul 2025 09:04:51 GMT Subject: [jdk25] RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch Message-ID: Clean backport to JDK 25. This change recently integrated in JDK 26 and is through tiers 1 - 4 so far. ------------- Commit messages: - Backport 13a3927855da61fe27f3b43e5e4755d0c5ac5a16 Changes: https://git.openjdk.org/jdk/pull/26088/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26088&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359870 Stats: 32 lines in 5 files changed: 22 ins; 2 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/26088.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26088/head:pull/26088 PR: https://git.openjdk.org/jdk/pull/26088 From iwalulya at openjdk.org Wed Jul 2 09:27:46 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 2 Jul 2025 09:27:46 GMT Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v19] In-Reply-To: References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com> Message-ID: On Mon, 30 Jun 2025 10:24:58 GMT, Albert Mingkun Yang wrote: >> This patch refines Parallel's sizing strategy to improve overall memory management and performance. >> >> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`. >> >> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`. >> >> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`. >> >> ## Performance evaluation >> >> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)). >> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html). >> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing. >> >> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging. >> >> Test: tier1-8 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review LGTM! very nice overhaul. ------------- Marked as reviewed by iwalulya (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25000#pullrequestreview-2978420691 From rrich at openjdk.org Wed Jul 2 09:36:15 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Wed, 2 Jul 2025 09:36:15 GMT Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails because of unstable inlining Message-ID: This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis. Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled. Testing: x86_64, ppc64 Failed inlining on x86_64 with TieredCompilation disabled: make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1 [...] STDOUT: CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true @ 1 java.util.concurrent.atomic.AtomicBoolean::get (13 bytes) inline (hot) @ 11 java.lang.StringBuffer:: (7 bytes) inline (hot) late inline succeeded (string method) @ 3 java.lang.AbstractStringBuilder:: (39 bytes) inline (hot) @ 1 java.lang.Object:: (1 bytes) inline (hot) @ 16 java.lang.System::currentTimeMillis (0 bytes) (intrinsic) s @ 19 java.lang.StringBuffer::append (13 bytes) failed to inline: already compiled into a big method s @ 24 java.lang.StringBuffer::toString (44 bytes) inline (hot) late inline succeeded (string method) s @ 1 java.lang.StringBuffer::length (5 bytes) accessor @ 24 java.lang.String:: (98 bytes) failed to inline: already compiled into a big method @ 30 java.util.concurrent.atomic.AtomicReference::set (6 bytes) accessor 2025-07-02T09:25:53.396634900Z Attempt 1, found: false 2025-07-02T09:25:53.415673072Z Attempt 2, found: false 2025-07-02T09:25:53.418876867Z Attempt 3, found: false [...] ------------- Commit messages: - Force inlining of String*.* methods - Force inlining of StringBuffer methods Changes: https://git.openjdk.org/jdk/pull/26033/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26033&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360599 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26033.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26033/head:pull/26033 PR: https://git.openjdk.org/jdk/pull/26033 From rrich at openjdk.org Wed Jul 2 09:36:15 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Wed, 2 Jul 2025 09:36:15 GMT Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails because of unstable inlining In-Reply-To: References: Message-ID: On Sun, 29 Jun 2025 15:26:14 GMT, Richard Reingruber wrote: > This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis. > > Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled. > > Testing: x86_64, ppc64 > > Failed inlining on x86_64 with TieredCompilation disabled: > > > make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1 > > [...] > > STDOUT: > CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true > @ 1 java.util.concurrent.atomic.AtomicBoolean::get (13 bytes) inline (hot) > @ 11 java.lang.StringBuffer:: (7 bytes) inline (hot) late inline succeeded (string method) > @ 3 java.lang.AbstractStringBuilder:: (39 bytes) inline (hot) > @ 1 java.lang.Object:: (1 bytes) inline (hot) > @ 16 java.lang.System::currentTimeMillis (0 bytes) (intrinsic) > s @ 19 java.lang.StringBuffer::append (13 bytes) failed to inline: already compiled into a big method > s @ 24 java.lang.StringBuffer::toString (44 bytes) inline (hot) late inline succeeded (string method) > s @ 1 java.lang.StringBuffer::length (5 bytes) accessor > @ 24 java.lang.String:: (98 bytes) failed to inline: already compiled into a big method > @ 30 java.util.concurrent.atomic.AtomicReference::set (6 bytes) accessor > 2025-07-02T09:25:53.396634900Z Attempt 1, found: false > 2025-07-02T09:25:53.415673072Z Attempt 2, found: false > 2025-07-02T09:25:53.418876867Z Attempt 3, found: false > > [...] Jit compiler folks might want to have a look at this pr. Maybe there's a better for having the StringBuilder locks eliminated deterministically. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26033#issuecomment-3027054192 From mdoerr at openjdk.org Wed Jul 2 09:54:41 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 2 Jul 2025 09:54:41 GMT Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails because of unstable inlining In-Reply-To: References: Message-ID: On Sun, 29 Jun 2025 15:26:14 GMT, Richard Reingruber wrote: > This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis. > > Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled. > > Testing: x86_64, ppc64 > > Failed inlining on x86_64 with TieredCompilation disabled: > > > make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1 > > [...] > > STDOUT: > CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true > @ 1 java.util.concurrent.atomic.AtomicBoolean::get (13 bytes) inline (hot) > @ 11 java.lang.StringBuffer:: (7 bytes) inline (hot) late inline succeeded (string method) > @ 3 java.lang.AbstractStringBuilder:: (39 bytes) inline (hot) > @ 1 java.lang.Object:: (1 bytes) inline (hot) > @ 16 java.lang.System::currentTimeMillis (0 bytes) (intrinsic) > s @ 19 java.lang.StringBuffer::append (13 bytes) failed to inline: already compiled into a big method > s @ 24 java.lang.StringBuffer::toString (44 bytes) inline (hot) late inline succeeded (string method) > s @ 1 java.lang.StringBuffer::length (5 bytes) accessor > @ 24 java.lang.String:: (98 bytes) failed to inline: already compiled into a big method > @ 30 java.util.concurrent.atomic.AtomicReference::set (6 bytes) accessor > 2025-07-02T09:25:53.396634900Z Attempt 1, found: false > 2025-07-02T09:25:53.415673072Z Attempt 2, found: false > 2025-07-02T09:25:53.418876867Z Attempt 3, found: false > > [...] LGTM. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26033#pullrequestreview-2978510981 From alanb at openjdk.org Wed Jul 2 10:58:39 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 2 Jul 2025 10:58:39 GMT Subject: [jdk25] RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 08:42:22 GMT, Kevin Walls wrote: > Clean backport to JDK 25. > > This change recently integrated in JDK 26 and is through tiers 1 - 4 so far. Clean backport . ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26088#pullrequestreview-2978690636 From sspitsyn at openjdk.org Wed Jul 2 11:19:39 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 2 Jul 2025 11:19:39 GMT Subject: [jdk25] RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch In-Reply-To: References: Message-ID: <7-mQC-lrxpz1sZQSy4RcpUl_kO0uX_mHuvUkMc40EvM=.02acae01-8078-4f88-82da-1712da475ef4@github.com> On Wed, 2 Jul 2025 08:42:22 GMT, Kevin Walls wrote: > Clean backport to JDK 25. > > This change recently integrated in JDK 26 and is through tiers 1 - 4 so far. It is a clean backport. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26088#pullrequestreview-2978748931 From sspitsyn at openjdk.org Wed Jul 2 11:23:44 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 2 Jul 2025 11:23:44 GMT Subject: RFR: 8360664: Null pointer dereference in src/hotspot/share/prims/jvmtiTagMap.cpp in IterateOverHeapObjectClosure::do_object() [v4] In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 07:38:31 GMT, Artem Semenov wrote: >> The defect has been detected and confirmed in the function ```IterateOverHeapObjectClosure::do_object()``` located in the file ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis. This defect can potentially lead to a null pointer dereference. >> >> The pointer ```oop o``` is passed to the constructor of the CallbackWrapper class, where it is dereferenced without a null check. > > Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: > > Updated the text of assert I'm suggesting to close [JDK-8360670](https://bugs.openjdk.org/browse/JDK-8360670) as a dup of [JDK-8360664](https://bugs.openjdk.org/browse/JDK-8360664). ------------- PR Comment: https://git.openjdk.org/jdk/pull/26002#issuecomment-3027493740 From kevinw at openjdk.org Wed Jul 2 11:59:20 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 2 Jul 2025 11:59:20 GMT Subject: RFR: 8305567: serviceability/tmtools/jstat/GcTest01.java failed utils.JstatGcResults.assertConsistency Message-ID: There is no guarantee of consistency when sampling jstat data, and we're asserting these figures are always consistent. Tests should retry some small number of times, rerunning the jstat tool to recapture data. ------------- Commit messages: - (C) - Common base class for Jstat tests - GCPerfTests retry Changes: https://git.openjdk.org/jdk/pull/26094/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26094&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305567 Stats: 98 lines in 9 files changed: 60 ins; 12 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/26094.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26094/head:pull/26094 PR: https://git.openjdk.org/jdk/pull/26094 From kevinw at openjdk.org Wed Jul 2 11:59:20 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 2 Jul 2025 11:59:20 GMT Subject: RFR: 8305567: serviceability/tmtools/jstat/GcTest01.java failed utils.JstatGcResults.assertConsistency In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 11:42:23 GMT, Kevin Walls wrote: > There is no guarantee of consistency when sampling jstat data, and we're asserting these figures are always consistent. > Tests should retry some small number of times, rerunning the jstat tool to recapture data. jstat reads PerfData counters, at random times (as designed), and tests assert that they are always consistent. But PerfData counters are written individually and may not always be consistent. e.g. 296 void G1MonitoringSupport::update_sizes() { ... 303 _to_space_counters->update_capacity(_survivor_space_committed); 304 _to_space_counters->update_used(_survivor_space_used); If a space shrinks, we write a new capacity which might be lower than the previous-and-still-visible used value (for a very small time). There has to be a small window where the assertions do not hold, and we seem to hit these occasionally over a period of years, e.g. java.lang.RuntimeException: S1U > S1C (utilization > capacity) at utils.JstatResults.assertThat(JstatResults.java:172) at utils.JstatGcResults.assertConsistency(JstatGcResults.java:89) at GcTest01.main(GcTest01.java:52) The other known failure is: java.lang.RuntimeException: GCT != (YGCT + CGCT + FGCT) (GCT = 0.051, YGCT = 0.008, CGCT = 0.026, FGCT = 0.0, (YCGT + CGCT + FGCT) = 0.034) at utils.JstatResults.assertThat(JstatResults.java:172) at utils.JstatGcResults.assertConsistency(JstatGcResults.java:123) at GcTest01.main(GcTest01.java:52) ...where again there must be small windows for a problem when stats are updated. The assertion of consistency should retry some limited number of times on inconsistent data. If jstat data fetching is truly broken, or the data is truly incorrect, the test will hit the small retry limit and fail. serviceability/tmtools/jstat/GcTest01.java and serviceability/tmtools/jstat/GcTest02.java are known to fail occasionally. The known failures have commonly been with -Xcomp which can mean a slow test, but this does not reproduce on demand. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26094#issuecomment-3027592580 From asemenov at openjdk.org Wed Jul 2 12:10:39 2025 From: asemenov at openjdk.org (Artem Semenov) Date: Wed, 2 Jul 2025 12:10:39 GMT Subject: RFR: 8360664: Null pointer dereference in src/hotspot/share/prims/jvmtiTagMap.cpp in IterateOverHeapObjectClosure::do_object() [v4] In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 11:21:29 GMT, Serguei Spitsyn wrote: > I'm suggesting to close [JDK-8360670](https://bugs.openjdk.org/browse/JDK-8360670) as a dup of [JDK-8360664](https://bugs.openjdk.org/browse/JDK-8360664). Ok. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26002#issuecomment-3027629174 From kevinw at openjdk.org Wed Jul 2 16:59:39 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 2 Jul 2025 16:59:39 GMT Subject: [jdk25] RFR: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 08:42:22 GMT, Kevin Walls wrote: > Clean backport to JDK 25. > > This change recently integrated in JDK 26 and is through tiers 1 - 4 so far. Thanks Alan and Serguei, will integrate this clean backport to 25. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26088#issuecomment-3028589723 From kevinw at openjdk.org Wed Jul 2 17:02:44 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 2 Jul 2025 17:02:44 GMT Subject: [jdk25] Integrated: 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 08:42:22 GMT, Kevin Walls wrote: > Clean backport to JDK 25. > > This change recently integrated in JDK 26 and is through tiers 1 - 4 so far. This pull request has now been integrated. Changeset: 92268e17 Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/92268e17beec15f3fefa6784a48d6f0e1bb9c67a Stats: 32 lines in 5 files changed: 22 ins; 2 del; 8 mod 8359870: JVM crashes in AccessInternal::PostRuntimeDispatch Reviewed-by: alanb, sspitsyn Backport-of: 13a3927855da61fe27f3b43e5e4755d0c5ac5a16 ------------- PR: https://git.openjdk.org/jdk/pull/26088 From iklam at openjdk.org Wed Jul 2 17:39:18 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 2 Jul 2025 17:39:18 GMT Subject: RFR: 8361292: Rename ModuleEntry::module() to module_oop() Message-ID: A module has both a Java and a C++ representation - C++: `ModuleEntry` - Java: `java.lang.Module` In C++, we have the following two methods - `ModuleEntry* InstanceKlass::module()` - `oop ModuleEntry::module()` This can lead to confusing code like this: InstanceKlass* ik = ...; oop module = ik->module()->module() Proposal: - Leave `InstanceKlass::module()` as is -- there's another function with the same style: `PackageEntry* InstanceKlass::package()` - Rename `ModuleEntry::module()` to `ModuleEntry::module_oop()`, so the above example can be more readable: InstanceKlass* ik = ...; oop module = ik->module()->module_oop() ------------- Commit messages: - 8361292: Rename ModuleEntry::module() to module_oop() Changes: https://git.openjdk.org/jdk/pull/26102/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26102&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361292 Stats: 35 lines in 12 files changed: 0 ins; 0 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/26102.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26102/head:pull/26102 PR: https://git.openjdk.org/jdk/pull/26102 From coleenp at openjdk.org Wed Jul 2 17:54:40 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 2 Jul 2025 17:54:40 GMT Subject: RFR: 8361292: Rename ModuleEntry::module() to module_oop() In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 17:33:40 GMT, Ioi Lam wrote: > A module has both a Java and a C++ representation > > - C++: `ModuleEntry` > - Java: `java.lang.Module` > > In C++, we have the following two methods > > - `ModuleEntry* InstanceKlass::module()` > - `oop ModuleEntry::module()` > > This can lead to confusing code like this: > > > InstanceKlass* ik = ...; > oop module = ik->module()->module() > > > Proposal: > > - Leave `InstanceKlass::module()` as is -- there's another function with the same style: `PackageEntry* InstanceKlass::package()` > - Rename `ModuleEntry::module()` to `ModuleEntry::module_oop()`, so the above example can be more readable: > > > InstanceKlass* ik = ...; > oop module = ik->module()->module_oop() I like this change other than precond(). ModuleEntry vs java.lang.Module oops is clearer with a different method name. I've been confused by this too. src/hotspot/share/runtime/reflection.cpp line 555: > 553: } else { > 554: oop module_oop = module_to->module_oop(); > 555: precond(module_oop != nullptr); I don't like precond() when you could have a useful assert message instead. src/hotspot/share/runtime/reflection.cpp line 582: > 580: } else { > 581: oop module_oop = module_from->module_oop(); > 582: precond(module_oop != nullptr); same here. "Module oop should be non-null in ModuleEntry" ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26102#pullrequestreview-2980107062 PR Review Comment: https://git.openjdk.org/jdk/pull/26102#discussion_r2180644851 PR Review Comment: https://git.openjdk.org/jdk/pull/26102#discussion_r2180646204 From iklam at openjdk.org Wed Jul 2 18:14:57 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 2 Jul 2025 18:14:57 GMT Subject: RFR: 8361292: Rename ModuleEntry::module() to module_oop() [v2] In-Reply-To: References: Message-ID: <70Nl64CPVziB0aP054IDyxJE2YC5QV55GhkxmMgQs0E=.560e3a99-5e84-4b67-be2f-10925c6367d2@github.com> On Wed, 2 Jul 2025 17:50:52 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @coleenp comments > > src/hotspot/share/runtime/reflection.cpp line 582: > >> 580: } else { >> 581: oop module_oop = module_from->module_oop(); >> 582: precond(module_oop != nullptr); > > same here. "Module oop should be non-null in ModuleEntry" We have just read the oop from the module entry and assert that it's not null, so the original message didn't add any extra information. That's why I removed it. I have added back a message, "should have been initialized". The real story is more complex, but I think this message willl give enough hints -- the module oop is usually initialized inside the ModuleEntry constructor, except for a few cases for the java.base module where the module oop is retroactively updated. In any case, by the time we reach this assert, the module oop must have been initialized in one of those possible paths. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26102#discussion_r2180678283 From iklam at openjdk.org Wed Jul 2 18:14:57 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 2 Jul 2025 18:14:57 GMT Subject: RFR: 8361292: Rename ModuleEntry::module() to module_oop() [v2] In-Reply-To: References: Message-ID: > A module has both a Java and a C++ representation > > - C++: `ModuleEntry` > - Java: `java.lang.Module` > > In C++, we have the following two methods > > - `ModuleEntry* InstanceKlass::module()` > - `oop ModuleEntry::module()` > > This can lead to confusing code like this: > > > InstanceKlass* ik = ...; > oop module = ik->module()->module() > > > Proposal: > > - Leave `InstanceKlass::module()` as is -- there's another function with the same style: `PackageEntry* InstanceKlass::package()` > - Rename `ModuleEntry::module()` to `ModuleEntry::module_oop()`, so the above example can be more readable: > > > InstanceKlass* ik = ...; > oop module = ik->module()->module_oop() Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @coleenp comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26102/files - new: https://git.openjdk.org/jdk/pull/26102/files/69b453e2..f58f2852 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26102&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26102&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26102.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26102/head:pull/26102 PR: https://git.openjdk.org/jdk/pull/26102 From coleenp at openjdk.org Wed Jul 2 19:04:38 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 2 Jul 2025 19:04:38 GMT Subject: RFR: 8361292: Rename ModuleEntry::module() to module_oop() [v2] In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 18:14:57 GMT, Ioi Lam wrote: >> A module has both a Java and a C++ representation >> >> - C++: `ModuleEntry` >> - Java: `java.lang.Module` >> >> In C++, we have the following two methods >> >> - `ModuleEntry* InstanceKlass::module()` >> - `oop ModuleEntry::module()` >> >> This can lead to confusing code like this: >> >> >> InstanceKlass* ik = ...; >> oop module = ik->module()->module() >> >> >> Proposal: >> >> - Leave `InstanceKlass::module()` as is -- there's another function with the same style: `PackageEntry* InstanceKlass::package()` >> - Rename `ModuleEntry::module()` to `ModuleEntry::module_oop()`, so the above example can be more readable: >> >> >> InstanceKlass* ik = ...; >> oop module = ik->module()->module_oop() > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @coleenp comments Marked as reviewed by coleenp (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26102#pullrequestreview-2980324205 From ccheung at openjdk.org Wed Jul 2 21:28:40 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 2 Jul 2025 21:28:40 GMT Subject: RFR: 8361292: Rename ModuleEntry::module() to module_oop() [v2] In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 18:14:57 GMT, Ioi Lam wrote: >> A module has both a Java and a C++ representation >> >> - C++: `ModuleEntry` >> - Java: `java.lang.Module` >> >> In C++, we have the following two methods >> >> - `ModuleEntry* InstanceKlass::module()` >> - `oop ModuleEntry::module()` >> >> This can lead to confusing code like this: >> >> >> InstanceKlass* ik = ...; >> oop module = ik->module()->module() >> >> >> Proposal: >> >> - Leave `InstanceKlass::module()` as is -- there's another function with the same style: `PackageEntry* InstanceKlass::package()` >> - Rename `ModuleEntry::module()` to `ModuleEntry::module_oop()`, so the above example can be more readable: >> >> >> InstanceKlass* ik = ...; >> oop module = ik->module()->module_oop() > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @coleenp comments Looks good. src/hotspot/share/classfile/moduleEntry.cpp line 52: > 50: ModuleEntry* ModuleEntryTable::_javabase_module = nullptr; > 51: > 52: oop ModuleEntry::module_oop() const { return _module_handle.resolve(); } (Pre-existing) Just wondering why this one-liner function doesn't reside in the moduleEntry.hpp? ------------- Marked as reviewed by ccheung (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26102#pullrequestreview-2980677723 PR Review Comment: https://git.openjdk.org/jdk/pull/26102#discussion_r2181000093 From sspitsyn at openjdk.org Wed Jul 2 21:46:46 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 2 Jul 2025 21:46:46 GMT Subject: RFR: 8356548: Avoid using ASM to parse latest class files in tests [v5] In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 16:11:16 GMT, Chen Liang wrote: >> For early eval; test by changing the ClassReader max accepted version of test ASM to 24 instead of 25 > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Update test/hotspot/jtreg/compiler/calls/common/InvokeDynamicPatcher.java > > Co-authored-by: Andrew Haley Thank you for making these changes! I've looked at the `jvmti` tests only and posted some questions and nits. test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/MissedStackMapFrames/MissedStackMapFrames.java line 82: > 80: }; > 81: } > 82: }; Nit: The code above is not well readable. The variable names need to be more clear, or we need some comments explaining the abbreviations. Not everyone who is reading this code is familiar with the `ClassFile` api. `cm`: codeModel `mth`: ? `optSmt`: ? test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineAnnotations.java line 88: > 86: var cf = ClassFile.of(ClassFile.ConstantPoolSharingOption.NEW_POOL); > 87: return cf.transformClass(cf.parse(classfileBuffer), new ClassTransform() { > 88: // Shuffle constant pool Q: What does `cf` mean, class file, code model or ...? test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineGenericSignatureTest.java line 151: > 149: var cf = ClassFile.of(); > 150: return cf.transformClass(cf.parse(bytecode), new ClassTransform() { > 151: private boolean sourceSet = false; Q: Same question as above. test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineObject.java line 71: > 69: } else { > 70: cb.with(ce); > 71: } Nit: I'd suggest to rename the variables with implicit types: `cb` => `builder` or `classBuilder` `ce` => `element` or `classElement` test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 102: > 100: var cm = ClassFile.of().parse(classBytes); > 101: var rvaa = cm.findAttribute(Attributes.runtimeVisibleAnnotations()).orElseThrow(); > 102: var elements = rvaa.annotations().stream().filter(anno -> anno.className().isFieldType(CD_ClassVersion)).findFirst().orElseThrow().elements(); Nit: The line above is too long. ------------- Changes requested by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25124#pullrequestreview-2980702277 PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2181014791 PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2181020007 PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2181021096 PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2181025634 PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2181026494 From sspitsyn at openjdk.org Wed Jul 2 21:52:43 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 2 Jul 2025 21:52:43 GMT Subject: RFR: 8360664: Null pointer dereference in src/hotspot/share/prims/jvmtiTagMap.cpp in IterateOverHeapObjectClosure::do_object() [v4] In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 07:38:31 GMT, Artem Semenov wrote: >> The defect has been detected and confirmed in the function ```IterateOverHeapObjectClosure::do_object()``` located in the file ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis. This defect can potentially lead to a null pointer dereference. >> >> The pointer ```oop o``` is passed to the constructor of the CallbackWrapper class, where it is dereferenced without a null check. > > Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: > > Updated the text of assert Looks good. Thank you for closing second bug as a dup. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26002#pullrequestreview-2980735724 From iklam at openjdk.org Wed Jul 2 21:52:44 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 2 Jul 2025 21:52:44 GMT Subject: RFR: 8361292: Rename ModuleEntry::module() to module_oop() [v2] In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 21:25:04 GMT, Calvin Cheung wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @coleenp comments > > src/hotspot/share/classfile/moduleEntry.cpp line 52: > >> 50: ModuleEntry* ModuleEntryTable::_javabase_module = nullptr; >> 51: >> 52: oop ModuleEntry::module_oop() const { return _module_handle.resolve(); } > > (Pre-existing) Just wondering why this one-liner function doesn't reside in the moduleEntry.hpp? I think it's because `OopHandle::resolve()` is an inline function, but we are not allowed to include `xxx.inline.hpp` in non-inlined `.hpp` files. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26102#discussion_r2181036271 From sspitsyn at openjdk.org Wed Jul 2 22:04:43 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 2 Jul 2025 22:04:43 GMT Subject: RFR: 8361292: Rename ModuleEntry::module() to module_oop() [v2] In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 18:14:57 GMT, Ioi Lam wrote: >> A module has both a Java and a C++ representation >> >> - C++: `ModuleEntry` >> - Java: `java.lang.Module` >> >> In C++, we have the following two methods >> >> - `ModuleEntry* InstanceKlass::module()` >> - `oop ModuleEntry::module()` >> >> This can lead to confusing code like this: >> >> >> InstanceKlass* ik = ...; >> oop module = ik->module()->module() >> >> >> Proposal: >> >> - Leave `InstanceKlass::module()` as is -- there's another function with the same style: `PackageEntry* InstanceKlass::package()` >> - Rename `ModuleEntry::module()` to `ModuleEntry::module_oop()`, so the above example can be more readable: >> >> >> InstanceKlass* ik = ...; >> oop module = ik->module()->module_oop() > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @coleenp comments Looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26102#pullrequestreview-2980760653 From amenkov at openjdk.org Wed Jul 2 23:34:42 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 2 Jul 2025 23:34:42 GMT Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with -fno-elide-constructors In-Reply-To: <_5NwWIsGk5KAsowrz20u62ynfb23KW_XIKlofA3Att0=.c40d9c15-5572-4187-ad15-490900c6b9b2@github.com> References: <_5NwWIsGk5KAsowrz20u62ynfb23KW_XIKlofA3Att0=.c40d9c15-5572-4187-ad15-490900c6b9b2@github.com> Message-ID: On Wed, 2 Jul 2025 07:16:57 GMT, David Holmes wrote: > I'm not very familiar with these aspects of C++ but this seems to be a very complex solution to what sounds in JBS to be a pretty straight-forward problem. Straight-forward solution would be to add copy ctor for Iterator class which clones GrowableArray (allocates new instance and copies all elements). But I'm not quite happy with the current implementation of AgentList and its iterator, so prefer to update it to keep entries in the original order (and iterator becomes much simpler). Changes in the callers are required as they used `const JvmtiAgentList::Iterator` and const `next` method is removed. > src/hotspot/share/prims/jvmtiAgentList.cpp line 35: > >> 33: >> 34: JvmtiAgent* JvmtiAgentList::_head = nullptr; >> 35: JvmtiAgent** JvmtiAgentList::_tail = nullptr; > > Why is the tail a pointer to a pointer? Sorry I'm not understanding how your list is being managed here. > > I'm trying to work out where you need acquire/release because I'm pretty sure it is missing where needed, but again I can't understand how you are actually constructing and using the list. pointer to pointer because it contains not the pointer to the last agent in the list, but address of the `JvmtiAgent::_next` field. `_tail` is for faster adding at the end of the list. Performance is not important here and number of agents is always low, so I think `_tail` can be removed to make the logic simpler. Will update the fix after testing completes > src/hotspot/share/prims/jvmtiAgentList.cpp line 105: > >> 103: while (true) { >> 104: // set _tail to address of agent->_next >> 105: JvmtiAgent** tail = Atomic::load_acquire(&_tail); > > You don't need acquire semantics here as you are not doing anything with the `_tail` pointer value other than use it in relation to cmpxchg which provides fully memory barriers. ok, thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/26083#issuecomment-3029654109 PR Review Comment: https://git.openjdk.org/jdk/pull/26083#discussion_r2181149878 PR Review Comment: https://git.openjdk.org/jdk/pull/26083#discussion_r2181149860 From amenkov at openjdk.org Thu Jul 3 01:17:56 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 3 Jul 2025 01:17:56 GMT Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with -fno-elide-constructors [v2] In-Reply-To: References: Message-ID: > Currently jvmtiAgentList keeps agents in reversed order (new agents are added to the head of the list). > To restore original order JvmtiAgentList::Iterator uses GrowableArray allocated in heap. > Iterators for different agent types are returned by value, and the iterator class nas no custom copy ctor, so if the constructor not elides, GrowableArray is deallocated twice. > > The fix updates jvmtiAgentList to keep agents in the original order, agents are added to the tail. > Iterator now needs only single pointer to next agent. > Additionally removed `JvmtiAgentList::Iterator::next() const` method (it looks very strange as `next()` is expected to change state of the iterator). > > Testing: tier1..4,hs-tier5-svc Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26083/files - new: https://git.openjdk.org/jdk/pull/26083/files/c93b598f..994ffddc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26083&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26083&range=00-01 Stats: 22 lines in 3 files changed: 1 ins; 5 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/26083.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26083/head:pull/26083 PR: https://git.openjdk.org/jdk/pull/26083 From sspitsyn at openjdk.org Thu Jul 3 02:04:46 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 3 Jul 2025 02:04:46 GMT Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with -fno-elide-constructors [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 01:17:56 GMT, Alex Menkov wrote: >> Currently jvmtiAgentList keeps agents in reversed order (new agents are added to the head of the list). >> To restore original order JvmtiAgentList::Iterator uses GrowableArray allocated in heap. >> Iterators for different agent types are returned by value, and the iterator class nas no custom copy ctor, so if the constructor not elides, GrowableArray is deallocated twice. >> >> The fix updates jvmtiAgentList to keep agents in the original order, agents are added to the tail. >> Iterator now needs only single pointer to next agent. >> Additionally removed `JvmtiAgentList::Iterator::next() const` method (it looks very strange as `next()` is expected to change state of the iterator). >> >> Testing: tier1..4,hs-tier5-svc > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > update Changes requested by sspitsyn (Reviewer). src/hotspot/share/prims/jvmtiAgentList.hpp line 30: > 28: //#include "nmt/memTag.hpp" > 29: #include "prims/jvmtiAgent.hpp" > 30: //#include "utilities/growableArray.hpp" Nit: You might want to remove unneeded headers. :) ------------- PR Review: https://git.openjdk.org/jdk/pull/26083#pullrequestreview-2981271238 PR Review Comment: https://git.openjdk.org/jdk/pull/26083#discussion_r2181383291 From sspitsyn at openjdk.org Thu Jul 3 02:16:43 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 3 Jul 2025 02:16:43 GMT Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with -fno-elide-constructors [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 01:17:56 GMT, Alex Menkov wrote: >> Currently jvmtiAgentList keeps agents in reversed order (new agents are added to the head of the list). >> To restore original order JvmtiAgentList::Iterator uses GrowableArray allocated in heap. >> Iterators for different agent types are returned by value, and the iterator class nas no custom copy ctor, so if the constructor not elides, GrowableArray is deallocated twice. >> >> The fix updates jvmtiAgentList to keep agents in the original order, agents are added to the tail. >> Iterator now needs only single pointer to next agent. >> Additionally removed `JvmtiAgentList::Iterator::next() const` method (it looks very strange as `next()` is expected to change state of the iterator). >> >> Testing: tier1..4,hs-tier5-svc > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > update The updated version without `_tail` looks better. :) You have some trailing spaces to fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26083#issuecomment-3030287828 From amenkov at openjdk.org Thu Jul 3 03:01:52 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 3 Jul 2025 03:01:52 GMT Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with -fno-elide-constructors [v3] In-Reply-To: References: Message-ID: > Currently jvmtiAgentList keeps agents in reversed order (new agents are added to the head of the list). > To restore original order JvmtiAgentList::Iterator uses GrowableArray allocated in heap. > Iterators for different agent types are returned by value, and the iterator class nas no custom copy ctor, so if the constructor not elides, GrowableArray is deallocated twice. > > The fix updates jvmtiAgentList to keep agents in the original order, agents are added to the tail. > Iterator now needs only single pointer to next agent. > Additionally removed `JvmtiAgentList::Iterator::next() const` method (it looks very strange as `next()` is expected to change state of the iterator). > > Testing: tier1..4,hs-tier5-svc Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: removed commented includes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26083/files - new: https://git.openjdk.org/jdk/pull/26083/files/994ffddc..aeb2b26c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26083&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26083&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26083.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26083/head:pull/26083 PR: https://git.openjdk.org/jdk/pull/26083 From amenkov at openjdk.org Thu Jul 3 03:08:26 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 3 Jul 2025 03:08:26 GMT Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with -fno-elide-constructors [v4] In-Reply-To: References: Message-ID: > Currently jvmtiAgentList keeps agents in reversed order (new agents are added to the head of the list). > To restore original order JvmtiAgentList::Iterator uses GrowableArray allocated in heap. > Iterators for different agent types are returned by value, and the iterator class nas no custom copy ctor, so if the constructor not elides, GrowableArray is deallocated twice. > > The fix updates jvmtiAgentList to keep agents in the original order, agents are added to the tail. > Iterator now needs only single pointer to next agent. > Additionally removed `JvmtiAgentList::Iterator::next() const` method (it looks very strange as `next()` is expected to change state of the iterator). > > Testing: tier1..4,hs-tier5-svc Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: jcheck ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26083/files - new: https://git.openjdk.org/jdk/pull/26083/files/aeb2b26c..bf91aef2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26083&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26083&range=02-03 Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/26083.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26083/head:pull/26083 PR: https://git.openjdk.org/jdk/pull/26083 From amenkov at openjdk.org Thu Jul 3 03:13:39 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 3 Jul 2025 03:13:39 GMT Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with -fno-elide-constructors [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 02:00:13 GMT, Serguei Spitsyn wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> update > > src/hotspot/share/prims/jvmtiAgentList.hpp line 30: > >> 28: //#include "nmt/memTag.hpp" >> 29: #include "prims/jvmtiAgent.hpp" >> 30: //#include "utilities/growableArray.hpp" > > Nit: You might want to remove unneeded headers. :) Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26083#discussion_r2181490591 From dholmes at openjdk.org Thu Jul 3 04:29:38 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 3 Jul 2025 04:29:38 GMT Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with -fno-elide-constructors [v4] In-Reply-To: References: Message-ID: <7ywNnlbJKAHe0pVcW-QOHUtf6b0vEFu-s3lgWOeJ-cw=.11f51596-d13a-4437-a10d-db22c5f2250d@github.com> On Thu, 3 Jul 2025 03:08:26 GMT, Alex Menkov wrote: >> Currently jvmtiAgentList keeps agents in reversed order (new agents are added to the head of the list). >> To restore original order JvmtiAgentList::Iterator uses GrowableArray allocated in heap. >> Iterators for different agent types are returned by value, and the iterator class nas no custom copy ctor, so if the constructor not elides, GrowableArray is deallocated twice. >> >> The fix updates jvmtiAgentList to keep agents in the original order, agents are added to the tail. >> Iterator now needs only single pointer to next agent. >> Additionally removed `JvmtiAgentList::Iterator::next() const` method (it looks very strange as `next()` is expected to change state of the iterator). >> >> Testing: tier1..4,hs-tier5-svc > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > jcheck Okay - still took me a little while to understand the double-indirection of the "tail ptr" in `add`, but I get it now. So looking at the acquire/release requirements: - all additions are done with `cmpxchg` which is effectively a release-store - when you iterate the list all loads of the "next" agent must be a load-acquire, this means - when you create the iterator you need a load-acquire (which you have when you pass `head()` ) - In `Iterator::next()` you need a load-acquire on each read of the `_next` field which is most simply done by defining `JvmtiAgent::next()` as a load-acquire and using that in the iterator code instead of direct field access. - `JvmtiAgent::set_next` should be a release-store though as far as I can see it is not used. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26083#pullrequestreview-2981588585 From ccheung at openjdk.org Thu Jul 3 05:27:27 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 3 Jul 2025 05:27:27 GMT Subject: RFR: 8361325: Refactor ClassLoaderExt Message-ID: After the refactoring work done via [JDK-8280682](https://bugs.openjdk.org/browse/JDK-8280682), there are only three functions remaining in the ClassLoaderExt class. This RFE is to move those remaining functions into other classes so that the ClassLoaderExt class can be eliminated. Testing: passed tiers 1 - 5. ------------- Commit messages: - 8361325: Refactor ClassLoaderExt Changes: https://git.openjdk.org/jdk/pull/26110/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26110&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361325 Stats: 228 lines in 15 files changed: 59 ins; 165 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26110.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26110/head:pull/26110 PR: https://git.openjdk.org/jdk/pull/26110 From sspitsyn at openjdk.org Thu Jul 3 06:12:13 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 3 Jul 2025 06:12:13 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method Message-ID: It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent. This impacts the following JVMTI functions: - `PopFrame` - `NotifyFramePop` - `ForceEarlyReturn` A related CSR is going to be filed for this spec update. Testing: - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe ------------- Commit messages: - 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method Changes: https://git.openjdk.org/jdk/pull/26111/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26111&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309399 Stats: 41 lines in 1 file changed: 12 ins; 12 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/26111.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26111/head:pull/26111 PR: https://git.openjdk.org/jdk/pull/26111 From asemenov at openjdk.org Thu Jul 3 07:03:44 2025 From: asemenov at openjdk.org (Artem Semenov) Date: Thu, 3 Jul 2025 07:03:44 GMT Subject: RFR: 8360664: Null pointer dereference in src/hotspot/share/prims/jvmtiTagMap.cpp in IterateOverHeapObjectClosure::do_object() [v3] In-Reply-To: <8PM6VY6Iuchg8hMcU9iyivsQmZ2x17vqbsH0pQ1IUZg=.88904f1c-a9d3-48e0-88d7-a7417ee5496c@github.com> References: <8PM6VY6Iuchg8hMcU9iyivsQmZ2x17vqbsH0pQ1IUZg=.88904f1c-a9d3-48e0-88d7-a7417ee5496c@github.com> Message-ID: On Tue, 1 Jul 2025 00:31:25 GMT, Alex Menkov wrote: >> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: >> >> changed if tu assert > > Marked as reviewed by amenkov (Reviewer). @alexmenkov @plummercj @dholmes-ora do you mind the integration? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26002#issuecomment-3031112862 From alanb at openjdk.org Thu Jul 3 08:39:40 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 3 Jul 2025 08:39:40 GMT Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails because of unstable inlining In-Reply-To: References: Message-ID: On Sun, 29 Jun 2025 15:26:14 GMT, Richard Reingruber wrote: > This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis. > > Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled. > > Testing: x86_64, ppc64 manually. Other major platforms as part of our CI testing. > > Failed inlining on x86_64 with TieredCompilation disabled: > > > make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1 > > [...] > > STDOUT: > CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true > @ 1 java.util.concurrent.atomic.AtomicBoolean::get (13 bytes) inline (hot) > @ 11 java.lang.StringBuffer:: (7 bytes) inline (hot) late inline succeeded (string method) > @ 3 java.lang.AbstractStringBuilder:: (39 bytes) inline (hot) > @ 1 java.lang.Object:: (1 bytes) inline (hot) > @ 16 java.lang.System::currentTimeMillis (0 bytes) (intrinsic) > s @ 19 java.lang.StringBuffer::append (13 bytes) failed to inline: already compiled into a big method > s @ 24 java.lang.StringBuffer::toString (44 bytes) inline (hot) late inline succeeded (string method) > s @ 1 java.lang.StringBuffer::length (5 bytes) accessor > @ 24 java.lang.String:: (98 bytes) failed to inline: already compiled into a big method > @ 30 java.util.concurrent.atomic.AtomicReference::set (6 bytes) accessor > 2025-07-02T09:25:53.396634900Z Attempt 1, found: false > 2025-07-02T09:25:53.415673072Z Attempt 2, found: false > 2025-07-02T09:25:53.418876867Z Attempt 3, found: false > > [...] Thanks for improving this, this test was intended unstable. It might be that it could be updated to work with debug or -Xcomp too, execution times would need to be checked out. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26033#pullrequestreview-2982264097 From alanb at openjdk.org Thu Jul 3 09:00:47 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 3 Jul 2025 09:00:47 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 06:05:26 GMT, Serguei Spitsyn wrote: > It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent. > This impacts the following JVMTI functions: > - `PopFrame` > - `NotifyFramePop` > - `ForceEarlyReturn` > > A related CSR is going to be filed for this spec update. > > Testing: > - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe src/hotspot/share/prims/jvmti.xml line 3082: > 3080: > 3081: The implementation is unable to provide this functionality on this frame > 3082: (e.g. the frame at depth is executing a native method). It might be better to say "unable to generate a FramePop event for the frame" rather than "unable to provide this functionality on this frame". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2182246125 From coleenp at openjdk.org Thu Jul 3 13:02:38 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 3 Jul 2025 13:02:38 GMT Subject: RFR: 8361325: Refactor ClassLoaderExt In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 05:16:54 GMT, Calvin Cheung wrote: > After the refactoring work done via [JDK-8280682](https://bugs.openjdk.org/browse/JDK-8280682), there are only three functions remaining in the ClassLoaderExt class. This RFE is to move those remaining functions into other classes so that the ClassLoaderExt class can be eliminated. > > Testing: passed tiers 1 - 5. This looks great. I never liked the Ext name. I had a tiny comment. src/hotspot/share/classfile/modules.cpp line 671: > 669: // list[3] = "" > 670: // list[4] = "" > 671: list.sort(Modules::compare_module_names); Does compare _module_names have to be an external function? ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26110#pullrequestreview-2983066152 PR Review Comment: https://git.openjdk.org/jdk/pull/26110#discussion_r2182718450 From rrich at openjdk.org Thu Jul 3 14:38:40 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Thu, 3 Jul 2025 14:38:40 GMT Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails because of unstable inlining In-Reply-To: References: Message-ID: <0p61J0DPfyHsen3r__V82eEZSPYaT9rZleHBtanKaRc=.c5f6992f-a7fe-4c95-bdcb-2887c3dbde21@github.com> On Thu, 3 Jul 2025 08:36:53 GMT, Alan Bateman wrote: > It might be that it could be updated to work with debug or -Xcomp too, execution times would need to be checked out. I found that the runtime of each test is ~300ms with a release build and ~11s with a fastdebug build on x86_64 and ppc64. If you like I can remove the requirement within this pr and do some more testing. -Xcomp doesn't seem to work. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26033#issuecomment-3032511575 From sspitsyn at openjdk.org Thu Jul 3 15:13:39 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 3 Jul 2025 15:13:39 GMT Subject: RFR: 8361325: Refactor ClassLoaderExt In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 05:16:54 GMT, Calvin Cheung wrote: > After the refactoring work done via [JDK-8280682](https://bugs.openjdk.org/browse/JDK-8280682), there are only three functions remaining in the ClassLoaderExt class. This RFE is to move those remaining functions into other classes so that the ClassLoaderExt class can be eliminated. > > Testing: passed tiers 1 - 5. It looks good to me. I like this simplification. But I'm curious what was the original reason to have the `classLoaderExt`? src/hotspot/share/cds/classListParser.cpp line 33: > 31: #include "cds/metaspaceShared.hpp" > 32: #include "cds/unregisteredClasses.hpp" > 33: #include "classfile/classLoader.hpp" Nit: I wonder if the line #33 is really needed and can be removed. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26110#pullrequestreview-2983562923 PR Review Comment: https://git.openjdk.org/jdk/pull/26110#discussion_r2183031189 From sspitsyn at openjdk.org Thu Jul 3 15:24:39 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 3 Jul 2025 15:24:39 GMT Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with -fno-elide-constructors [v4] In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 03:08:26 GMT, Alex Menkov wrote: >> Currently jvmtiAgentList keeps agents in reversed order (new agents are added to the head of the list). >> To restore original order JvmtiAgentList::Iterator uses GrowableArray allocated in heap. >> Iterators for different agent types are returned by value, and the iterator class nas no custom copy ctor, so if the constructor not elides, GrowableArray is deallocated twice. >> >> The fix updates jvmtiAgentList to keep agents in the original order, agents are added to the tail. >> Iterator now needs only single pointer to next agent. >> Additionally removed `JvmtiAgentList::Iterator::next() const` method (it looks very strange as `next()` is expected to change state of the iterator). >> >> Testing: tier1..4,hs-tier5-svc > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > jcheck This looks good to me. I hope, David will sort out where the `Atomic::` operations are needed. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26083#pullrequestreview-2983633781 From sspitsyn at openjdk.org Thu Jul 3 15:33:41 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 3 Jul 2025 15:33:41 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 08:57:34 GMT, Alan Bateman wrote: >> It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent. >> This impacts the following JVMTI functions: >> - `PopFrame` >> - `NotifyFramePop` >> - `ForceEarlyReturn` >> >> A related CSR is going to be filed for this spec update. >> >> Testing: >> - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe > > src/hotspot/share/prims/jvmti.xml line 3082: > >> 3080: >> 3081: The implementation is unable to provide this functionality on this frame >> 3082: (e.g. the frame at depth is executing a native method). > > It might be better to say "unable to generate a FramePop event for the frame" rather than "unable to provide this functionality on this frame". Good suggestion, thanks. `NotifyFramePop` does not generate the `FramePop` events by itself it is just sets or enables events. Then should we say this way: "unable to set a `FramePop` event for the frame" ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2183102777 From lmesnik at openjdk.org Thu Jul 3 16:54:43 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 3 Jul 2025 16:54:43 GMT Subject: RFR: 8305567: serviceability/tmtools/jstat/GcTest01.java failed utils.JstatGcResults.assertConsistency In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 11:42:23 GMT, Kevin Walls wrote: > There is no guarantee of consistency when sampling jstat data, and we're asserting these figures are always consistent. > Tests should retry some small number of times, rerunning the jstat tool to recapture data. Marked as reviewed by lmesnik (Reviewer). test/hotspot/jtreg/serviceability/tmtools/jstat/utils/JstatTool.java line 46: > 44: for (int i = 1; i <= TRIES; i++) { > 45: try { > 46: results = measure(); Might be the 'measure' and 'assertConsistency' might be changed to from 'public' to 'package-local` if they are not needed to be used by tests directly. ------------- PR Review: https://git.openjdk.org/jdk/pull/26094#pullrequestreview-2983899660 PR Review Comment: https://git.openjdk.org/jdk/pull/26094#discussion_r2183255118 From iklam at openjdk.org Thu Jul 3 16:55:45 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 3 Jul 2025 16:55:45 GMT Subject: RFR: 8361292: Rename ModuleEntry::module() to module_oop() [v2] In-Reply-To: References: Message-ID: <7t8AhNKgTL2MU_ba0F3rCllEqaodLFmshj_9QvGwY00=.1ba3ff82-905d-4b7a-8b4a-6944f5b22b5e@github.com> On Wed, 2 Jul 2025 19:02:30 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @coleenp comments > > Marked as reviewed by coleenp (Reviewer). Thanks @coleenp @calvinccheung @sspitsyn for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/26102#issuecomment-3032931506 From iklam at openjdk.org Thu Jul 3 16:55:46 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 3 Jul 2025 16:55:46 GMT Subject: Integrated: 8361292: Rename ModuleEntry::module() to module_oop() In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 17:33:40 GMT, Ioi Lam wrote: > A module has both a Java and a C++ representation > > - C++: `ModuleEntry` > - Java: `java.lang.Module` > > In C++, we have the following two methods > > - `ModuleEntry* InstanceKlass::module()` > - `oop ModuleEntry::module()` > > This can lead to confusing code like this: > > > InstanceKlass* ik = ...; > oop module = ik->module()->module() > > > Proposal: > > - Leave `InstanceKlass::module()` as is -- there's another function with the same style: `PackageEntry* InstanceKlass::package()` > - Rename `ModuleEntry::module()` to `ModuleEntry::module_oop()`, so the above example can be more readable: > > > InstanceKlass* ik = ...; > oop module = ik->module()->module_oop() This pull request has now been integrated. Changeset: 66836d40 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/66836d40b80f9c5482c1322d1d07f078ad9dcc02 Stats: 35 lines in 12 files changed: 0 ins; 0 del; 35 mod 8361292: Rename ModuleEntry::module() to module_oop() Reviewed-by: coleenp, ccheung, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/26102 From lmesnik at openjdk.org Thu Jul 3 16:59:40 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 3 Jul 2025 16:59:40 GMT Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails because of unstable inlining In-Reply-To: References: Message-ID: On Sun, 29 Jun 2025 15:26:14 GMT, Richard Reingruber wrote: > This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis. > > Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled. > > Testing: x86_64, ppc64 manually. Other major platforms as part of our CI testing. > > Failed inlining on x86_64 with TieredCompilation disabled: > > > make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1 > > [...] > > STDOUT: > CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true > @ 1 java.util.concurrent.atomic.AtomicBoolean::get (13 bytes) inline (hot) > @ 11 java.lang.StringBuffer:: (7 bytes) inline (hot) late inline succeeded (string method) > @ 3 java.lang.AbstractStringBuilder:: (39 bytes) inline (hot) > @ 1 java.lang.Object:: (1 bytes) inline (hot) > @ 16 java.lang.System::currentTimeMillis (0 bytes) (intrinsic) > s @ 19 java.lang.StringBuffer::append (13 bytes) failed to inline: already compiled into a big method > s @ 24 java.lang.StringBuffer::toString (44 bytes) inline (hot) late inline succeeded (string method) > s @ 1 java.lang.StringBuffer::length (5 bytes) accessor > @ 24 java.lang.String:: (98 bytes) failed to inline: already compiled into a big method > @ 30 java.util.concurrent.atomic.AtomicReference::set (6 bytes) accessor > 2025-07-02T09:25:53.396634900Z Attempt 1, found: false > 2025-07-02T09:25:53.415673072Z Attempt 2, found: false > 2025-07-02T09:25:53.418876867Z Attempt 3, found: false > > [...] Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26033#pullrequestreview-2983913131 From ccheung at openjdk.org Thu Jul 3 17:12:55 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 3 Jul 2025 17:12:55 GMT Subject: RFR: 8361325: Refactor ClassLoaderExt [v2] In-Reply-To: References: Message-ID: <57QfXghfWE9oekdPxC8wpypRtLN6T5CV6wig7-dWHqQ=.8718419b-b153-42e4-b9ab-4febbca093c0@github.com> > After the refactoring work done via [JDK-8280682](https://bugs.openjdk.org/browse/JDK-8280682), there are only three functions remaining in the ClassLoaderExt class. This RFE is to move those remaining functions into other classes so that the ClassLoaderExt class can be eliminated. > > Testing: passed tiers 1 - 5. Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: @coleenp comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26110/files - new: https://git.openjdk.org/jdk/pull/26110/files/19942e19..4cbd71fc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26110&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26110&range=00-01 Stats: 11 lines in 2 files changed: 5 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26110.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26110/head:pull/26110 PR: https://git.openjdk.org/jdk/pull/26110 From ccheung at openjdk.org Thu Jul 3 17:12:55 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 3 Jul 2025 17:12:55 GMT Subject: RFR: 8361325: Refactor ClassLoaderExt [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 15:10:12 GMT, Serguei Spitsyn wrote: > It looks good to me. I like this simplification. But I'm curious what was the original reason to have the `classLoaderExt`? I think it was created during the first revision of AppCDS back in JDK 8u. > src/hotspot/share/cds/classListParser.cpp line 33: > >> 31: #include "cds/metaspaceShared.hpp" >> 32: #include "cds/unregisteredClasses.hpp" >> 33: #include "classfile/classLoader.hpp" > > Nit: I wonder if the line #33 is really needed and can be removed. It is needed or else I got compilation error: open/src/hotspot/share/cds/classListParser.cpp:561:29: error: 'ClassLoader' has not been declared 561 | const char* source_path = ClassLoader::uri_to_path(_source); | ^~~~~~~~~~~ It worked before because classLoaderExt.hpp includes classLoader.hpp. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26110#issuecomment-3032983136 PR Review Comment: https://git.openjdk.org/jdk/pull/26110#discussion_r2183292645 From ccheung at openjdk.org Thu Jul 3 17:12:56 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 3 Jul 2025 17:12:56 GMT Subject: RFR: 8361325: Refactor ClassLoaderExt [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 12:56:44 GMT, Coleen Phillimore wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> @coleenp comment > > src/hotspot/share/classfile/modules.cpp line 671: > >> 669: // list[3] = "" >> 670: // list[4] = "" >> 671: list.sort(Modules::compare_module_names); > > Does compare _module_names have to be an external function? I've changed it to a static function in modules.cpp. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26110#discussion_r2183286022 From coleenp at openjdk.org Thu Jul 3 17:29:39 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 3 Jul 2025 17:29:39 GMT Subject: RFR: 8361325: Refactor ClassLoaderExt [v2] In-Reply-To: <57QfXghfWE9oekdPxC8wpypRtLN6T5CV6wig7-dWHqQ=.8718419b-b153-42e4-b9ab-4febbca093c0@github.com> References: <57QfXghfWE9oekdPxC8wpypRtLN6T5CV6wig7-dWHqQ=.8718419b-b153-42e4-b9ab-4febbca093c0@github.com> Message-ID: On Thu, 3 Jul 2025 17:12:55 GMT, Calvin Cheung wrote: >> After the refactoring work done via [JDK-8280682](https://bugs.openjdk.org/browse/JDK-8280682), there are only three functions remaining in the ClassLoaderExt class. This RFE is to move those remaining functions into other classes so that the ClassLoaderExt class can be eliminated. >> >> Testing: passed tiers 1 - 5. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > @coleenp comment Marked as reviewed by coleenp (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26110#pullrequestreview-2984015341 From coleenp at openjdk.org Thu Jul 3 17:29:40 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 3 Jul 2025 17:29:40 GMT Subject: RFR: 8361325: Refactor ClassLoaderExt [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 17:10:03 GMT, Calvin Cheung wrote: > It looks good to me. I like this simplification. But I'm curious what was the original reason to have the classLoaderExt? I think it was from before we settled on the Shared suffix for CDS methods. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26110#issuecomment-3033021163 From alanb at openjdk.org Thu Jul 3 17:59:44 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 3 Jul 2025 17:59:44 GMT Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails because of unstable inlining In-Reply-To: <0p61J0DPfyHsen3r__V82eEZSPYaT9rZleHBtanKaRc=.c5f6992f-a7fe-4c95-bdcb-2887c3dbde21@github.com> References: <0p61J0DPfyHsen3r__V82eEZSPYaT9rZleHBtanKaRc=.c5f6992f-a7fe-4c95-bdcb-2887c3dbde21@github.com> Message-ID: On Thu, 3 Jul 2025 14:36:15 GMT, Richard Reingruber wrote: > I found that the runtime of each test is ~300ms with a release build and ~11s with a fastdebug build on x86_64 and ppc64. If you like I can remove the requirement within this pr and do some more testing. -Xcomp doesn't seem to work. I think that would be useful, thank you. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26033#issuecomment-3033099720 From cjplummer at openjdk.org Thu Jul 3 18:52:39 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 3 Jul 2025 18:52:39 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 06:05:26 GMT, Serguei Spitsyn wrote: > It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent. > This impacts the following JVMTI functions: > - `PopFrame` > - `NotifyFramePop` > - `ForceEarlyReturn` > > A related CSR is going to be filed for this spec update. > > Testing: > - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe src/hotspot/share/prims/jvmti.xml line 2991: > 2989: > 2990: The implementation is unable to pop this frame > 2991: (e.g. called or calling method is a native method). Directly below we have special OPAQUE_FRAME language for virtual threads. Do we want to get rid of it since it is now covered by the above language? Note there is also language directly above that discusses suspended virtual threads. src/hotspot/share/prims/jvmti.xml line 3191: > 3189: > 3190: > 3191: The implementation is unable to force current frame to return Suggestion: The implementation is unable to force the current frame to return src/hotspot/share/prims/jvmti.xml line 3194: > 3192: (e.g. current frame is executing a native method). > 3193: > 3194: Do we still need this section? Same question for repeated sections below. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2183507709 PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2183513041 PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2183515227 From cjplummer at openjdk.org Thu Jul 3 18:52:39 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 3 Jul 2025 18:52:39 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 18:43:19 GMT, Chris Plummer wrote: >> It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent. >> This impacts the following JVMTI functions: >> - `PopFrame` >> - `NotifyFramePop` >> - `ForceEarlyReturn` >> >> A related CSR is going to be filed for this spec update. >> >> Testing: >> - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe > > src/hotspot/share/prims/jvmti.xml line 3191: > >> 3189: >> 3190: >> 3191: The implementation is unable to force current frame to return > > Suggestion: > > The implementation is unable to force the current frame to return Note this error repeats a few times below. I only tagged this one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2183517279 From amenkov at openjdk.org Thu Jul 3 19:13:24 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 3 Jul 2025 19:13:24 GMT Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with -fno-elide-constructors [v5] In-Reply-To: References: Message-ID: > Currently jvmtiAgentList keeps agents in reversed order (new agents are added to the head of the list). > To restore original order JvmtiAgentList::Iterator uses GrowableArray allocated in heap. > Iterators for different agent types are returned by value, and the iterator class nas no custom copy ctor, so if the constructor not elides, GrowableArray is deallocated twice. > > The fix updates jvmtiAgentList to keep agents in the original order, agents are added to the tail. > Iterator now needs only single pointer to next agent. > Additionally removed `JvmtiAgentList::Iterator::next() const` method (it looks very strange as `next()` is expected to change state of the iterator). > > Testing: tier1..4,hs-tier5-svc Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: David's feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26083/files - new: https://git.openjdk.org/jdk/pull/26083/files/bf91aef2..b1b2dc3f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26083&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26083&range=03-04 Stats: 7 lines in 3 files changed: 0 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26083.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26083/head:pull/26083 PR: https://git.openjdk.org/jdk/pull/26083 From amenkov at openjdk.org Thu Jul 3 19:15:40 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 3 Jul 2025 19:15:40 GMT Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with -fno-elide-constructors [v4] In-Reply-To: <7ywNnlbJKAHe0pVcW-QOHUtf6b0vEFu-s3lgWOeJ-cw=.11f51596-d13a-4437-a10d-db22c5f2250d@github.com> References: <7ywNnlbJKAHe0pVcW-QOHUtf6b0vEFu-s3lgWOeJ-cw=.11f51596-d13a-4437-a10d-db22c5f2250d@github.com> Message-ID: On Thu, 3 Jul 2025 04:27:13 GMT, David Holmes wrote: > Okay - still took me a little while to understand the double-indirection of the "tail ptr" in `add`, but I get it now. So looking at the acquire/release requirements: > > * all additions are done with `cmpxchg` which is effectively a release-store > > * when you iterate the list all loads of the "next" agent must be a load-acquire, this means > > * when you create the iterator you need a load-acquire (which you have when you pass `head()` ) > * In `Iterator::next()` you need a load-acquire on each read of the `_next` field which is most simply done by defining `JvmtiAgent::next()` as a load-acquire and using that in the iterator code instead of direct field access. > > * `JvmtiAgent::set_next` should be a release-store though as far as I can see it is not used. Thank you for the detailed analysis. Updated as suggested. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26083#issuecomment-3033349842 From ccheung at openjdk.org Thu Jul 3 19:42:42 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 3 Jul 2025 19:42:42 GMT Subject: RFR: 8361325: Refactor ClassLoaderExt [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 17:26:43 GMT, Coleen Phillimore wrote: >>> It looks good to me. I like this simplification. But I'm curious what was the original reason to have the `classLoaderExt`? >> >> I think it was created during the first revision of AppCDS back in JDK 8u. > >> It looks good to me. I like this simplification. But I'm curious what was the original reason to have the classLoaderExt? > > I think it was from before we settled on the Shared suffix for CDS methods. Thanks @coleenp @sspitsyn for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26110#issuecomment-3033406876 From ccheung at openjdk.org Thu Jul 3 19:42:43 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 3 Jul 2025 19:42:43 GMT Subject: Integrated: 8361325: Refactor ClassLoaderExt In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 05:16:54 GMT, Calvin Cheung wrote: > After the refactoring work done via [JDK-8280682](https://bugs.openjdk.org/browse/JDK-8280682), there are only three functions remaining in the ClassLoaderExt class. This RFE is to move those remaining functions into other classes so that the ClassLoaderExt class can be eliminated. > > Testing: passed tiers 1 - 5. This pull request has now been integrated. Changeset: 003be0de Author: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/003be0dee2f6c190697ec0a923546362c50cc0e5 Stats: 228 lines in 14 files changed: 59 ins; 165 del; 4 mod 8361325: Refactor ClassLoaderExt Reviewed-by: coleenp, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/26110 From amenkov at openjdk.org Thu Jul 3 20:21:39 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 3 Jul 2025 20:21:39 GMT Subject: RFR: 8360664: Null pointer dereference in src/hotspot/share/prims/jvmtiTagMap.cpp in IterateOverHeapObjectClosure::do_object() [v4] In-Reply-To: References: Message-ID: <8V_RMuDb8LuGqkCk6mqH7M9ZrTjzYBBu-yKx8VTtvfA=.c7ab7581-1579-4d9f-8548-21e05fd4f653@github.com> On Tue, 1 Jul 2025 07:38:31 GMT, Artem Semenov wrote: >> The defect has been detected and confirmed in the function ```IterateOverHeapObjectClosure::do_object()``` located in the file ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis. This defect can potentially lead to a null pointer dereference. >> >> The pointer ```oop o``` is passed to the constructor of the CallbackWrapper class, where it is dereferenced without a null check. > > Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: > > Updated the text of assert I'm fine with the fix, the only question if it helps with the analysis tool. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26002#issuecomment-3033515986 From cjplummer at openjdk.org Thu Jul 3 20:31:41 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 3 Jul 2025 20:31:41 GMT Subject: RFR: 8360664: Null pointer dereference in src/hotspot/share/prims/jvmtiTagMap.cpp in IterateOverHeapObjectClosure::do_object() [v4] In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 07:38:31 GMT, Artem Semenov wrote: >> The defect has been detected and confirmed in the function ```IterateOverHeapObjectClosure::do_object()``` located in the file ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis. This defect can potentially lead to a null pointer dereference. >> >> The pointer ```oop o``` is passed to the constructor of the CallbackWrapper class, where it is dereferenced without a null check. > > Artem Semenov has updated the pull request incrementally with one additional commit since the last revision: > > Updated the text of assert Same here. I just don't want to see the CR refiled if the analysis tool still complains. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26002#issuecomment-3033543386 From dholmes at openjdk.org Fri Jul 4 01:30:41 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 4 Jul 2025 01:30:41 GMT Subject: RFR: 8355960: JvmtiAgentList::Iterator dtor double free with -fno-elide-constructors [v5] In-Reply-To: References: Message-ID: <9P6FzQv_JcweZlUxC53Sc6w4IWfTm5e6uKJIUEtIkYw=.8b11c478-86e4-4f61-8002-acaec28501a4@github.com> On Thu, 3 Jul 2025 19:13:24 GMT, Alex Menkov wrote: >> Currently jvmtiAgentList keeps agents in reversed order (new agents are added to the head of the list). >> To restore original order JvmtiAgentList::Iterator uses GrowableArray allocated in heap. >> Iterators for different agent types are returned by value, and the iterator class nas no custom copy ctor, so if the constructor not elides, GrowableArray is deallocated twice. >> >> The fix updates jvmtiAgentList to keep agents in the original order, agents are added to the tail. >> Iterator now needs only single pointer to next agent. >> Additionally removed `JvmtiAgentList::Iterator::next() const` method (it looks very strange as `next()` is expected to change state of the iterator). >> >> Testing: tier1..4,hs-tier5-svc > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > David's feedback Looks good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26083#pullrequestreview-2985155397 From alanb at openjdk.org Fri Jul 4 06:18:40 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 4 Jul 2025 06:18:40 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 15:31:28 GMT, Serguei Spitsyn wrote: > Then should we say this way: "unable to set a `FramePop` event for the frame" ? The can_generate_frame_pop_events capability uses "Can set .." so I think what you propose is good. Also the temptation may be to use the word "enable" where but that risks getting confused with enabling events. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2184504203 From rrich at openjdk.org Fri Jul 4 08:14:19 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Fri, 4 Jul 2025 08:14:19 GMT Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails because of unstable inlining [v2] In-Reply-To: References: Message-ID: <5IVOmLIL__iwmhFaKEP80YNP8kIN94owhC3SIU8ZF4U=.ab4061f3-e62f-4586-9118-7f84f246078d@github.com> > This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis. > > Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled. > > Testing: x86_64, ppc64 manually. Other major platforms as part of our CI testing. > > Failed inlining on x86_64 with TieredCompilation disabled: > > > make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1 > > [...] > > STDOUT: > CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true > @ 1 java.util.concurrent.atomic.AtomicBoolean::get (13 bytes) inline (hot) > @ 11 java.lang.StringBuffer:: (7 bytes) inline (hot) late inline succeeded (string method) > @ 3 java.lang.AbstractStringBuilder:: (39 bytes) inline (hot) > @ 1 java.lang.Object:: (1 bytes) inline (hot) > @ 16 java.lang.System::currentTimeMillis (0 bytes) (intrinsic) > s @ 19 java.lang.StringBuffer::append (13 bytes) failed to inline: already compiled into a big method > s @ 24 java.lang.StringBuffer::toString (44 bytes) inline (hot) late inline succeeded (string method) > s @ 1 java.lang.StringBuffer::length (5 bytes) accessor > @ 24 java.lang.String:: (98 bytes) failed to inline: already compiled into a big method > @ 30 java.util.concurrent.atomic.AtomicReference::set (6 bytes) accessor > 2025-07-02T09:25:53.396634900Z Attempt 1, found: false > 2025-07-02T09:25:53.415673072Z Attempt 2, found: false > 2025-07-02T09:25:53.418876867Z Attempt 3, found: false > > [...] Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Allow vm.debug ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26033/files - new: https://git.openjdk.org/jdk/pull/26033/files/8561d522..a43e54db Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26033&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26033&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26033.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26033/head:pull/26033 PR: https://git.openjdk.org/jdk/pull/26033 From rrich at openjdk.org Fri Jul 4 08:14:20 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Fri, 4 Jul 2025 08:14:20 GMT Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails because of unstable inlining [v2] In-Reply-To: References: <0p61J0DPfyHsen3r__V82eEZSPYaT9rZleHBtanKaRc=.c5f6992f-a7fe-4c95-bdcb-2887c3dbde21@github.com> Message-ID: On Thu, 3 Jul 2025 17:57:27 GMT, Alan Bateman wrote: > > I found that the runtime of each test is ~300ms with a release build and ~11s with a fastdebug build on x86_64 and ppc64. If you like I can remove the requirement within this pr and do some more testing. -Xcomp doesn't seem to work. > > I think that would be useful, thank you. I've removed the `!vm.debug` requirement. I'll await our local testing of the pr on a wider range of platforms. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26033#issuecomment-3034923279 From alanb at openjdk.org Fri Jul 4 10:27:39 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 4 Jul 2025 10:27:39 GMT Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails because of unstable inlining [v2] In-Reply-To: <5IVOmLIL__iwmhFaKEP80YNP8kIN94owhC3SIU8ZF4U=.ab4061f3-e62f-4586-9118-7f84f246078d@github.com> References: <5IVOmLIL__iwmhFaKEP80YNP8kIN94owhC3SIU8ZF4U=.ab4061f3-e62f-4586-9118-7f84f246078d@github.com> Message-ID: On Fri, 4 Jul 2025 08:14:19 GMT, Richard Reingruber wrote: >> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis. >> >> Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled. >> >> Testing: x86_64, ppc64 manually. Other major platforms as part of our CI testing. >> >> Failed inlining on x86_64 with TieredCompilation disabled: >> >> >> make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1 >> >> [...] >> >> STDOUT: >> CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true >> @ 1 java.util.concurrent.atomic.AtomicBoolean::get (13 bytes) inline (hot) >> @ 11 java.lang.StringBuffer:: (7 bytes) inline (hot) late inline succeeded (string method) >> @ 3 java.lang.AbstractStringBuilder:: (39 bytes) inline (hot) >> @ 1 java.lang.Object:: (1 bytes) inline (hot) >> @ 16 java.lang.System::currentTimeMillis (0 bytes) (intrinsic) >> s @ 19 java.lang.StringBuffer::append (13 bytes) failed to inline: already compiled into a big method >> s @ 24 java.lang.StringBuffer::toString (44 bytes) inline (hot) late inline succeeded (string method) >> s @ 1 java.lang.StringBuffer::length (5 bytes) accessor >> @ 24 java.lang.String:: (98 bytes) failed to inline: already compiled into a big method >> @ 30 java.util.concurrent.atomic.AtomicReference::set (6 bytes) accessor >> 2025-07-02T09:25:53.396634900Z Attempt 1, found: false >> 2025-07-02T09:25:53.415673072Z Attempt 2, found: false >> 2025-07-02T09:25:53.418876867Z Attempt 3, found: false >> >> [...] > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Allow vm.debug Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26033#pullrequestreview-2986518539 From kevinw at openjdk.org Fri Jul 4 12:18:42 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 4 Jul 2025 12:18:42 GMT Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails because of unstable inlining [v2] In-Reply-To: <5IVOmLIL__iwmhFaKEP80YNP8kIN94owhC3SIU8ZF4U=.ab4061f3-e62f-4586-9118-7f84f246078d@github.com> References: <5IVOmLIL__iwmhFaKEP80YNP8kIN94owhC3SIU8ZF4U=.ab4061f3-e62f-4586-9118-7f84f246078d@github.com> Message-ID: On Fri, 4 Jul 2025 08:14:19 GMT, Richard Reingruber wrote: >> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis. >> >> Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled. >> >> Testing: x86_64, ppc64 manually. Other major platforms as part of our CI testing. >> >> Failed inlining on x86_64 with TieredCompilation disabled: >> >> >> make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1 >> >> [...] >> >> STDOUT: >> CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true >> @ 1 java.util.concurrent.atomic.AtomicBoolean::get (13 bytes) inline (hot) >> @ 11 java.lang.StringBuffer:: (7 bytes) inline (hot) late inline succeeded (string method) >> @ 3 java.lang.AbstractStringBuilder:: (39 bytes) inline (hot) >> @ 1 java.lang.Object:: (1 bytes) inline (hot) >> @ 16 java.lang.System::currentTimeMillis (0 bytes) (intrinsic) >> s @ 19 java.lang.StringBuffer::append (13 bytes) failed to inline: already compiled into a big method >> s @ 24 java.lang.StringBuffer::toString (44 bytes) inline (hot) late inline succeeded (string method) >> s @ 1 java.lang.StringBuffer::length (5 bytes) accessor >> @ 24 java.lang.String:: (98 bytes) failed to inline: already compiled into a big method >> @ 30 java.util.concurrent.atomic.AtomicReference::set (6 bytes) accessor >> 2025-07-02T09:25:53.396634900Z Attempt 1, found: false >> 2025-07-02T09:25:53.415673072Z Attempt 2, found: false >> 2025-07-02T09:25:53.418876867Z Attempt 3, found: false >> >> [...] > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Allow vm.debug About the test and debug mode, we had that kind of conversation in https://github.com/openjdk/jdk/pull/25958 Windows and Macosx were likely to timeout in debug builds, Linux was OK for me. Not sure if the inlining requests here affect that much, will be interesting to see. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26033#issuecomment-3035981114 From zgu at openjdk.org Sun Jul 6 20:17:44 2025 From: zgu at openjdk.org (Zhengyu Gu) Date: Sun, 6 Jul 2025 20:17:44 GMT Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v13] In-Reply-To: <76NgHH-m26Nw2paJmIQvNNqio_iKtdQ_bJ2aejMfKEI=.82ff25aa-f5c5-4146-84b5-1aaaefb5efd1@github.com> References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com> <76NgHH-m26Nw2paJmIQvNNqio_iKtdQ_bJ2aejMfKEI=.82ff25aa-f5c5-4146-84b5-1aaaefb5efd1@github.com> Message-ID: <85HD8TnSUAI0GIc_xeF7SPzT52Mv3fAO2mUlm73M4_g=.d6300d71-32c6-4cc9-af9d-97d8a66f6264@github.com> On Wed, 18 Jun 2025 09:00:58 GMT, Albert Mingkun Yang wrote: >> This patch refines Parallel's sizing strategy to improve overall memory management and performance. >> >> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`. >> >> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`. >> >> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`. >> >> ## Performance evaluation >> >> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)). >> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html). >> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing. >> >> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging. >> >> Test: tier1-8 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: > > - review > - Merge branch 'master' into pgc-size-policy > - merge > - version > - Merge branch 'master' into pgc-size-policy > - revert-aliases > - Merge branch 'master' into pgc-size-policy > - merge > - merge-fix > - merge > - ... and 9 more: https://git.openjdk.org/jdk/compare/2b94b70e...a21e5363 src/hotspot/share/gc/parallel/parallelArguments.cpp line 71: > 69: // True in product build, since tests using debug build often stress GC > 70: if (FLAG_IS_DEFAULT(UseGCOverheadLimit)) { > 71: FLAG_SET_DEFAULT(UseGCOverheadLimit, trueInProduct); Given only Parallel honors `UseGCOverheadLimit`, you may want to set the default to `trueInProduct` in `gc_globals.hpp` src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 381: > 379: HeapWord* result = young_gen()->expand_and_allocate(size); > 380: > 381: if (result == nullptr && !is_tlab && !should_alloc_in_eden(size)) { I feel that you changed intent of `should_alloc_in_eden()`. I believe the original intent is to prevent allocating large objects in eden, and here, seems to prevent allocating small objects in old gen. What benefits do you get? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2160152953 PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2160163706 From zgu at openjdk.org Sun Jul 6 20:17:44 2025 From: zgu at openjdk.org (Zhengyu Gu) Date: Sun, 6 Jul 2025 20:17:44 GMT Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3] In-Reply-To: References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com> Message-ID: On Mon, 19 May 2025 11:05:59 GMT, Guoxiong Li wrote: >> The one inside the safepoint will print sth `log_info(gc)("GCOverheadLimitThreshold ...`. There can be multiple concurrent mutators reaching here; printing here is undesirable. >> >> I don't think throwing OOM, from gc's perspective, is an "error". > >> I don't think throwing OOM, from gc's perspective, is an "error". > > Nevermind; I just obey the statement in methods `MemAllocator::Allocation::check_out_of_memory` and `Universe::out_of_memory_error_java_heap`. Returning `null` outside of a safe point does have unexpected negative effects. e.g. `HeapDumpOnOutOfMemoryError` may not get good heap dump, as other threads can come in and run additional GCs, then the heap dump may contain confusingly little live data. I wonder if you can improve this situtation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2181262727 From zgu at openjdk.org Sun Jul 6 20:17:46 2025 From: zgu at openjdk.org (Zhengyu Gu) Date: Sun, 6 Jul 2025 20:17:46 GMT Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v19] In-Reply-To: References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com> Message-ID: On Mon, 30 Jun 2025 10:24:58 GMT, Albert Mingkun Yang wrote: >> This patch refines Parallel's sizing strategy to improve overall memory management and performance. >> >> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`. >> >> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`. >> >> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`. >> >> ## Performance evaluation >> >> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)). >> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html). >> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing. >> >> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging. >> >> Test: tier1-8 > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review src/hotspot/share/gc/parallel/psParallelCompact.cpp line 898: > 896: size_t target_capacity_bytes = total_live_words * HeapWordSize > 897: + old_space->capacity_in_bytes() * (MarkSweepDeadRatio / 100.0) > 898: + SpaceAlignment; Why add `SpaceAlignment`, not `align_up` to `SpaceAlignment`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2188503009 From ayang at openjdk.org Sun Jul 6 21:10:43 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Sun, 6 Jul 2025 21:10:43 GMT Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v13] In-Reply-To: <85HD8TnSUAI0GIc_xeF7SPzT52Mv3fAO2mUlm73M4_g=.d6300d71-32c6-4cc9-af9d-97d8a66f6264@github.com> References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com> <76NgHH-m26Nw2paJmIQvNNqio_iKtdQ_bJ2aejMfKEI=.82ff25aa-f5c5-4146-84b5-1aaaefb5efd1@github.com> <85HD8TnSUAI0GIc_xeF7SPzT52Mv3fAO2mUlm73M4_g=.d6300d71-32c6-4cc9-af9d-97d8a66f6264@github.com> Message-ID: On Sat, 21 Jun 2025 20:56:37 GMT, Zhengyu Gu wrote: >> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: >> >> - review >> - Merge branch 'master' into pgc-size-policy >> - merge >> - version >> - Merge branch 'master' into pgc-size-policy >> - revert-aliases >> - Merge branch 'master' into pgc-size-policy >> - merge >> - merge-fix >> - merge >> - ... and 9 more: https://git.openjdk.org/jdk/compare/2b94b70e...a21e5363 > > src/hotspot/share/gc/parallel/parallelArguments.cpp line 71: > >> 69: // True in product build, since tests using debug build often stress GC >> 70: if (FLAG_IS_DEFAULT(UseGCOverheadLimit)) { >> 71: FLAG_SET_DEFAULT(UseGCOverheadLimit, trueInProduct); > > Given only Parallel honors `UseGCOverheadLimit`, you may want to set the default to `trueInProduct` in `gc_globals.hpp` It's indeed that only Parallel implements this flag. However, if we decide to change the default value of this flag globally, I feel we should do that in its own PR for better visibility. Currently, this changes the default value only for Parallel, as one expects in a PR titled "Parallel: ...". > src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 381: > >> 379: HeapWord* result = young_gen()->expand_and_allocate(size); >> 380: >> 381: if (result == nullptr && !is_tlab && !should_alloc_in_eden(size)) { > > I feel that you changed intent of `should_alloc_in_eden()`. I believe the original intent is to prevent allocating large objects in eden, and here, seems to prevent allocating small objects in old gen. > > What benefits do you get? I don't see how I changed the semantics. On baseline, from `mem_allocate_work`: if (result != nullptr) { return result; } // If certain conditions hold, try allocating from the old gen. if (!is_tlab) { result = mem_allocate_old_gen(size); if (result != nullptr) { return result; } } and HeapWord* ParallelScavengeHeap::mem_allocate_old_gen(size_t size) { if (!should_alloc_in_eden(size)) { // Size is too big for eden. return allocate_old_gen_and_record(size); } return nullptr; } The original logic is essentially: if (result == nullptr && !is_tlab && !should_alloc_in_eden(size)) { // allocate in old-gen } which is the same as I put here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2188594599 PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2188604946 From ayang at openjdk.org Sun Jul 6 21:10:43 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Sun, 6 Jul 2025 21:10:43 GMT Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3] In-Reply-To: References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com> Message-ID: On Thu, 3 Jul 2025 00:52:56 GMT, Zhengyu Gu wrote: >>> I don't think throwing OOM, from gc's perspective, is an "error". >> >> Nevermind; I just obey the statement in methods `MemAllocator::Allocation::check_out_of_memory` and `Universe::out_of_memory_error_java_heap`. > > Returning `null` outside of a safe point does have unexpected negative effects. e.g. `HeapDumpOnOutOfMemoryError` may not get good heap dump, as other threads can come in and run additional GCs, then the heap dump may contain confusingly little live data. > > I wonder if you can improve this situtation. Let me try to rephrase your concern to ensure that I understand you correctly -- after `_gc_overhead_counter >= GCOverheadLimitThreshold`, it's possible that another GC is triggered, which reclaims much free memory, and resets `_gc_overhead_counter` to zero. Then, `HeapDumpOnOutOfMemoryError` will not be able to get the intended heap snapshot. Is my understanding correct? (Seems that baseline resets the condition and can encounter the same problem as well.) if (limit_exceeded && softrefs_clear) { *gc_overhead_limit_was_exceeded = true; size_policy()->set_gc_overhead_limit_exceeded(false); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2188604729 From ayang at openjdk.org Sun Jul 6 21:10:45 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Sun, 6 Jul 2025 21:10:45 GMT Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v19] In-Reply-To: References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com> Message-ID: <1OgBWItLa8wkOksSxV6vcWN0Le2Z5uz5dnjIt4EGqak=.802ed747-6662-45fa-86d4-0bc1fb124022@github.com> On Sun, 6 Jul 2025 18:03:14 GMT, Zhengyu Gu wrote: >> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> review > > src/hotspot/share/gc/parallel/psParallelCompact.cpp line 898: > >> 896: size_t target_capacity_bytes = total_live_words * HeapWordSize >> 897: + old_space->capacity_in_bytes() * (MarkSweepDeadRatio / 100.0) >> 898: + SpaceAlignment; > > Why add `SpaceAlignment`, not `align_up` to `SpaceAlignment`? The alignment is handled inside the callee. I just wanna leave a minimal delta in the old-gen so that old-gen is not completely full. Otherwise, the next young-gc can not promote anything and will be upgraded to full-gc directly. This is mostly for `UseAdaptiveSizePolicy == false`; if enabled, old-gen will also be resized after full-gc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2188611386 From zgu at openjdk.org Mon Jul 7 00:42:41 2025 From: zgu at openjdk.org (Zhengyu Gu) Date: Mon, 7 Jul 2025 00:42:41 GMT Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3] In-Reply-To: References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com> Message-ID: On Sun, 6 Jul 2025 20:59:49 GMT, Albert Mingkun Yang wrote: >> Returning `null` outside of a safe point does have unexpected negative effects. e.g. `HeapDumpOnOutOfMemoryError` may not get good heap dump, as other threads can come in and run additional GCs, then the heap dump may contain confusingly little live data. >> >> I wonder if you can improve this situtation. > > Let me try to rephrase your concern to ensure that I understand you correctly -- after `_gc_overhead_counter >= GCOverheadLimitThreshold`, it's possible that another GC is triggered, which reclaims much free memory, and resets `_gc_overhead_counter` to zero. Then, `HeapDumpOnOutOfMemoryError` will not be able to get the intended heap snapshot. > > Is my understanding correct? > > (Seems that baseline resets the condition and can encounter the same problem as well.) > > > if (limit_exceeded && softrefs_clear) { > *gc_overhead_limit_was_exceeded = true; > size_policy()->set_gc_overhead_limit_exceeded(false); Yes. I don't think it is exceeding overhead limit only problem, but OOM and heap dump have to be, in a sense of `atomic`. We encountered this problem in real production system. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2188761699 From zgu at openjdk.org Mon Jul 7 00:42:41 2025 From: zgu at openjdk.org (Zhengyu Gu) Date: Mon, 7 Jul 2025 00:42:41 GMT Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v13] In-Reply-To: References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com> <76NgHH-m26Nw2paJmIQvNNqio_iKtdQ_bJ2aejMfKEI=.82ff25aa-f5c5-4146-84b5-1aaaefb5efd1@github.com> <85HD8TnSUAI0GIc_xeF7SPzT52Mv3fAO2mUlm73M4_g=.d6300d71-32c6-4cc9-af9d-97d8a66f6264@github.com> Message-ID: On Sun, 6 Jul 2025 21:00:42 GMT, Albert Mingkun Yang wrote: >> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 381: >> >>> 379: HeapWord* result = young_gen()->expand_and_allocate(size); >>> 380: >>> 381: if (result == nullptr && !is_tlab && !should_alloc_in_eden(size)) { >> >> I feel that you changed intent of `should_alloc_in_eden()`. I believe the original intent is to prevent allocating large objects in eden, and here, seems to prevent allocating small objects in old gen. >> >> What benefits do you get? > > I don't see how I changed the semantics. > > On baseline, from `mem_allocate_work`: > > > if (result != nullptr) { > return result; > } > > // If certain conditions hold, try allocating from the old gen. > if (!is_tlab) { > result = mem_allocate_old_gen(size); > if (result != nullptr) { > return result; > } > } > > > and > > > HeapWord* ParallelScavengeHeap::mem_allocate_old_gen(size_t size) { > if (!should_alloc_in_eden(size)) { > // Size is too big for eden. > return allocate_old_gen_and_record(size); > } > > return nullptr; > } > > > The original logic is essentially: > > > if (result == nullptr && !is_tlab && !should_alloc_in_eden(size)) { > // allocate in old-gen > } > > which is the same as I put here. Ah, okay. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2188761974 From zgu at openjdk.org Mon Jul 7 00:47:43 2025 From: zgu at openjdk.org (Zhengyu Gu) Date: Mon, 7 Jul 2025 00:47:43 GMT Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v19] In-Reply-To: <1OgBWItLa8wkOksSxV6vcWN0Le2Z5uz5dnjIt4EGqak=.802ed747-6662-45fa-86d4-0bc1fb124022@github.com> References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com> <1OgBWItLa8wkOksSxV6vcWN0Le2Z5uz5dnjIt4EGqak=.802ed747-6662-45fa-86d4-0bc1fb124022@github.com> Message-ID: <--1bClROkHGNgp0ZOioqohKNJU41qoL_k66W285wP70=.298c6a26-9f05-401e-96d6-afa2dacc1356@github.com> On Sun, 6 Jul 2025 21:07:26 GMT, Albert Mingkun Yang wrote: >> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 898: >> >>> 896: size_t target_capacity_bytes = total_live_words * HeapWordSize >>> 897: + old_space->capacity_in_bytes() * (MarkSweepDeadRatio / 100.0) >>> 898: + SpaceAlignment; >> >> Why add `SpaceAlignment`, not `align_up` to `SpaceAlignment`? > > The alignment is handled inside the callee. I just wanna leave a minimal delta in the old-gen so that old-gen is not completely full. Otherwise, the next young-gc can not promote anything and will be upgraded to full-gc directly. This is mostly for `UseAdaptiveSizePolicy == false`; if enabled, old-gen will also be resized after full-gc. After [JDK-8328744](https://bugs.openjdk.org/browse/JDK-8328744), it no longer uses old-gen capacity, but max old-gen size to estimate if promotion can succeed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2188764546 From asemenov at openjdk.org Mon Jul 7 06:14:45 2025 From: asemenov at openjdk.org (Artem Semenov) Date: Mon, 7 Jul 2025 06:14:45 GMT Subject: Integrated: 8360664: Null pointer dereference in src/hotspot/share/prims/jvmtiTagMap.cpp in IterateOverHeapObjectClosure::do_object() In-Reply-To: References: Message-ID: On Thu, 26 Jun 2025 13:24:31 GMT, Artem Semenov wrote: > The defect has been detected and confirmed in the function ```IterateOverHeapObjectClosure::do_object()``` located in the file ```src/hotspot/share/prims/jvmtiTagMap.cpp``` with static code analysis. This defect can potentially lead to a null pointer dereference. > > The pointer ```oop o``` is passed to the constructor of the CallbackWrapper class, where it is dereferenced without a null check. This pull request has now been integrated. Changeset: e9a43416 Author: Artem Semenov URL: https://git.openjdk.org/jdk/commit/e9a434165a6ec07cde0429c7f9823bbc5dab7857 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod 8360664: Null pointer dereference in src/hotspot/share/prims/jvmtiTagMap.cpp in IterateOverHeapObjectClosure::do_object() Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Artem Semenov . Reviewed-by: sspitsyn, amenkov, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/26002 From rrich at openjdk.org Mon Jul 7 07:44:39 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Mon, 7 Jul 2025 07:44:39 GMT Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails because of unstable inlining [v2] In-Reply-To: <5IVOmLIL__iwmhFaKEP80YNP8kIN94owhC3SIU8ZF4U=.ab4061f3-e62f-4586-9118-7f84f246078d@github.com> References: <5IVOmLIL__iwmhFaKEP80YNP8kIN94owhC3SIU8ZF4U=.ab4061f3-e62f-4586-9118-7f84f246078d@github.com> Message-ID: On Fri, 4 Jul 2025 08:14:19 GMT, Richard Reingruber wrote: >> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis. >> >> Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled. >> >> Testing: x86_64, ppc64 manually. Other major platforms as part of our CI testing. >> >> Failed inlining on x86_64 with TieredCompilation disabled: >> >> >> make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1 >> >> [...] >> >> STDOUT: >> CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true >> @ 1 java.util.concurrent.atomic.AtomicBoolean::get (13 bytes) inline (hot) >> @ 11 java.lang.StringBuffer:: (7 bytes) inline (hot) late inline succeeded (string method) >> @ 3 java.lang.AbstractStringBuilder:: (39 bytes) inline (hot) >> @ 1 java.lang.Object:: (1 bytes) inline (hot) >> @ 16 java.lang.System::currentTimeMillis (0 bytes) (intrinsic) >> s @ 19 java.lang.StringBuffer::append (13 bytes) failed to inline: already compiled into a big method >> s @ 24 java.lang.StringBuffer::toString (44 bytes) inline (hot) late inline succeeded (string method) >> s @ 1 java.lang.StringBuffer::length (5 bytes) accessor >> @ 24 java.lang.String:: (98 bytes) failed to inline: already compiled into a big method >> @ 30 java.util.concurrent.atomic.AtomicReference::set (6 bytes) accessor >> 2025-07-02T09:25:53.396634900Z Attempt 1, found: false >> 2025-07-02T09:25:53.415673072Z Attempt 2, found: false >> 2025-07-02T09:25:53.418876867Z Attempt 3, found: false >> >> [...] > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Allow vm.debug > About the test and debug mode, we had that kind of conversation in #25958 Windows and Macosx were likely to timeout in debug builds, Linux was OK for me. Not sure if the inlining requests here affect that much, will be interesting to see. You got timeouts likely because the test searched for eliminated locking in the thread dumps in an endless loop but lock elimination has failed (very early) due to unfavorable inlining. Inlining depends on timing because jit compilation runs asynchronously in the background. It affects inlining if a call target is already compiled into a big nmethod (see `failed to inline: already compiled into a big method` above). Calls critical for lock elimination will still be inlined because of the `CompileCommand` inlining requests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26033#issuecomment-3043813314 From rrich at openjdk.org Mon Jul 7 07:44:40 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Mon, 7 Jul 2025 07:44:40 GMT Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails because of unstable inlining [v2] In-Reply-To: References: <0p61J0DPfyHsen3r__V82eEZSPYaT9rZleHBtanKaRc=.c5f6992f-a7fe-4c95-bdcb-2887c3dbde21@github.com> Message-ID: On Fri, 4 Jul 2025 08:11:12 GMT, Richard Reingruber wrote: > I've removed the `!vm.debug` requirement. I'll await our local testing of the pr on a wider range of platforms. Local testing was good. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26033#issuecomment-3043828120 From ayang at openjdk.org Mon Jul 7 07:57:32 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 7 Jul 2025 07:57:32 GMT Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v20] In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com> References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com> Message-ID: > This patch refines Parallel's sizing strategy to improve overall memory management and performance. > > The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`. > > `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`. > > GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`. > > ## Performance evaluation > > - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)). > - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html). > - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing. > > PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging. > > Test: tier1-8 Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits: - review - Merge branch 'master' into pgc-size-policy - review - review - Merge branch 'master' into pgc-size-policy - Merge branch 'master' into pgc-size-policy - review - cast - remove-young-resize-after-full-gc - Merge branch 'master' into pgc-size-policy - ... and 20 more: https://git.openjdk.org/jdk/compare/d75ea7e6...2e8e19db ------------- Changes: https://git.openjdk.org/jdk/pull/25000/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=19 Stats: 4361 lines in 31 files changed: 505 ins; 3470 del; 386 mod Patch: https://git.openjdk.org/jdk/pull/25000.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000 PR: https://git.openjdk.org/jdk/pull/25000 From ayang at openjdk.org Mon Jul 7 07:57:33 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 7 Jul 2025 07:57:33 GMT Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3] In-Reply-To: References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com> Message-ID: <3TWxib1SPBfTIp1lZkywBo9ztCtH5vr8QDMO1CI7V80=.6dc5b0cc-552b-4f75-a95d-c62d6e6025f3@github.com> On Mon, 7 Jul 2025 00:39:20 GMT, Zhengyu Gu wrote: > but OOM and heap dump have to be, in a sense of atomic I see; it can indeed be annoying that heap-dump doesn't capture the intended snapshot -- a java thread can trigger a gc that changes heap-content. However, AFAICS, fixing that non-atomic issue requires updating callers of `report_java_out_of_memory`. Therefore, I am inclined to think it should be addressed in its own ticket. It's a preexisting issue on master as well, not sth newly introduced by this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2189268507 From ayang at openjdk.org Mon Jul 7 08:02:42 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 7 Jul 2025 08:02:42 GMT Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3] In-Reply-To: <3TWxib1SPBfTIp1lZkywBo9ztCtH5vr8QDMO1CI7V80=.6dc5b0cc-552b-4f75-a95d-c62d6e6025f3@github.com> References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com> <3TWxib1SPBfTIp1lZkywBo9ztCtH5vr8QDMO1CI7V80=.6dc5b0cc-552b-4f75-a95d-c62d6e6025f3@github.com> Message-ID: On Mon, 7 Jul 2025 07:53:24 GMT, Albert Mingkun Yang wrote: >> Yes. I don't think it is exceeding overhead limit only problem, but OOM and heap dump have to be, in a sense of `atomic`. We encountered this problem in real production system. > >> but OOM and heap dump have to be, in a sense of atomic > > I see; it can indeed be annoying that heap-dump doesn't capture the intended snapshot -- a java thread can trigger a gc that changes heap-content. However, AFAICS, fixing that non-atomic issue requires updating callers of `report_java_out_of_memory`. Therefore, I am inclined to think it should be addressed in its own ticket. It's a preexisting issue on master as well, not sth newly introduced by this PR. Does https://bugs.openjdk.org/browse/JDK-8347833 match the problem you have in mind? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2189284517 From kevinw at openjdk.org Mon Jul 7 09:09:31 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 7 Jul 2025 09:09:31 GMT Subject: RFR: 8305567: serviceability/tmtools/jstat/GcTest01.java failed utils.JstatGcResults.assertConsistency [v2] In-Reply-To: References: Message-ID: <722Bm9j0Zqx8Oo5no5Q-z-FhxGKkQ79HFMute4nA8AU=.6cc44a6a-4dda-46ee-ad06-ad9d338370a9@github.com> > There is no guarantee of consistency when sampling jstat data, and we're asserting these figures are always consistent. > Tests should retry some small number of times, rerunning the jstat tool to recapture data. Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: modifier order ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26094/files - new: https://git.openjdk.org/jdk/pull/26094/files/219e93ce..274b7c62 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26094&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26094&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26094.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26094/head:pull/26094 PR: https://git.openjdk.org/jdk/pull/26094 From kevinw at openjdk.org Mon Jul 7 09:09:32 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 7 Jul 2025 09:09:32 GMT Subject: RFR: 8305567: serviceability/tmtools/jstat/GcTest01.java failed utils.JstatGcResults.assertConsistency [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 16:51:34 GMT, Leonid Mesnik wrote: >> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: >> >> modifier order > > test/hotspot/jtreg/serviceability/tmtools/jstat/utils/JstatTool.java line 46: > >> 44: for (int i = 1; i <= TRIES; i++) { >> 45: try { >> 46: results = measure(); > > Might be the 'measure' and 'assertConsistency' might be changed to from 'public' to 'package-local` if they are not needed to be used by tests directly. Thanks - I left GarbageProducerTest with individual calls to measure() and assertConsistency(). This could be a small window for the same problem again. It's not one where I think we have ever seen the problem before. But it looks like that test's run() method tries to avoid a problem already, it tests if a collection has NOT happened during gathering, and only calls assertConsistency() if that's the case. But I will update additionally to put a couple of modifiers in the traditional blessed order. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26094#discussion_r2189438383 From gli at openjdk.org Mon Jul 7 10:02:05 2025 From: gli at openjdk.org (Guoxiong Li) Date: Mon, 7 Jul 2025 10:02:05 GMT Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v20] In-Reply-To: References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com> Message-ID: On Mon, 7 Jul 2025 07:57:32 GMT, Albert Mingkun Yang wrote: >> This patch refines Parallel's sizing strategy to improve overall memory management and performance. >> >> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`. >> >> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`. >> >> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`. >> >> ## Performance evaluation >> >> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)). >> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html). >> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing. >> >> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging. >> >> Test: tier1-8 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits: > > - review > - Merge branch 'master' into pgc-size-policy > - review > - review > - Merge branch 'master' into pgc-size-policy > - Merge branch 'master' into pgc-size-policy > - review > - cast > - remove-young-resize-after-full-gc > - Merge branch 'master' into pgc-size-policy > - ... and 20 more: https://git.openjdk.org/jdk/compare/d75ea7e6...2e8e19db Marked as reviewed by gli (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25000#pullrequestreview-2993059953 From mbaesken at openjdk.org Mon Jul 7 12:26:49 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 7 Jul 2025 12:26:49 GMT Subject: RFR: 8351487: [ubsan] jvmti.h runtime error: load of value which is not a valid value Message-ID: <1-9RRDL18MUUtoGa3krcB6A_An6SATisnVldYbELMFo=.86eef7ef-c4a1-4e20-97fa-1aa7d8383e57@github.com> When running with ubsan - enabled binaries, the following 2 issues are observed in jvmti.h (on macOS aarch64). jtreg test vmTestbase/nsk/jvmti/SetVerboseFlag/setvrbflag002/TestDescription.java /priv/jenkins/client-home/workspace/openjdk-jdk-weekly-macos_aarch64-opt/build/support/modules_include/java.base/jvmti.h:2645:44: runtime error: load of value 4294967295, which is not a valid value for type 'jvmtiVerboseFlag' #0 0x104453540 in _jvmtiEnv::SetVerboseFlag(jvmtiVerboseFlag, unsigned char) jvmti.h:2645 #1 0x10444ed5c in agentProc(_jvmtiEnv*, JNIEnv_*, void*) setvrbflag002.cpp:49 #2 0x10444f1c8 in agentThreadWrapper(_jvmtiEnv*, JNIEnv_*, void*) agent_tools.cpp:151 #3 0x10914895c in JvmtiAgentThread::call_start_function() jvmtiImpl.cpp:89 #4 0x108ebd7f0 in JavaThread::thread_main_inner() javaThread.cpp:776 #5 0x1096f6094 in Thread::call_run() thread.cpp:231 #6 0x10941c37c in thread_native_entry(Thread*) os_bsd.cpp:601 #7 0x1936fef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90) #8 0x1936f9d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30) vmTestbase/nsk/jvmti/GetErrorName/geterrname002/TestDescription.java /priv/jenkins/client-home/workspace/openjdk-jdk-weekly-macos_aarch64-opt/build/support/modules_include/java.base/jvmti.h:2640:42: runtime error: load of value 4294967295, which is not a valid value for type 'jvmtiError' #0 0x1002b3504 in _jvmtiEnv::GetErrorName(jvmtiError, char**) jvmti.h:2640 #1 0x1002aec9c in agentProc(_jvmtiEnv*, JNIEnv_*, void*) geterrname002.cpp:50 #2 0x1002af198 in agentThreadWrapper(_jvmtiEnv*, JNIEnv_*, void*) agent_tools.cpp:151 #3 0x104f4895c in JvmtiAgentThread::call_start_function() jvmtiImpl.cpp:89 #4 0x104cbd7f0 in JavaThread::thread_main_inner() javaThread.cpp:776 #5 0x1054f6094 in Thread::call_run() thread.cpp:231 #6 0x10521c37c in thread_native_entry(Thread*) os_bsd.cpp:601 #7 0x1936fef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90) #8 0x1936f9d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30) So the problem reported is SetVerboseFlag method (which is part of the VM) calls SetVerboseFlag function with that bad argument ; test test code seems to intentionally use 'bad' arguments . But this does not work well with ubsan ; so better exclude those tests from ubsan checking . ------------- Commit messages: - JDK-8351487 Changes: https://git.openjdk.org/jdk/pull/26159/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26159&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351487 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26159.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26159/head:pull/26159 PR: https://git.openjdk.org/jdk/pull/26159 From rrich at openjdk.org Mon Jul 7 13:23:46 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Mon, 7 Jul 2025 13:23:46 GMT Subject: RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails because of unstable inlining [v2] In-Reply-To: <5IVOmLIL__iwmhFaKEP80YNP8kIN94owhC3SIU8ZF4U=.ab4061f3-e62f-4586-9118-7f84f246078d@github.com> References: <5IVOmLIL__iwmhFaKEP80YNP8kIN94owhC3SIU8ZF4U=.ab4061f3-e62f-4586-9118-7f84f246078d@github.com> Message-ID: On Fri, 4 Jul 2025 08:14:19 GMT, Richard Reingruber wrote: >> This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis. >> >> Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled. >> >> Testing: x86_64, ppc64 manually. Other major platforms as part of our CI testing. >> >> Failed inlining on x86_64 with TieredCompilation disabled: >> >> >> make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1 >> >> [...] >> >> STDOUT: >> CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true >> @ 1 java.util.concurrent.atomic.AtomicBoolean::get (13 bytes) inline (hot) >> @ 11 java.lang.StringBuffer:: (7 bytes) inline (hot) late inline succeeded (string method) >> @ 3 java.lang.AbstractStringBuilder:: (39 bytes) inline (hot) >> @ 1 java.lang.Object:: (1 bytes) inline (hot) >> @ 16 java.lang.System::currentTimeMillis (0 bytes) (intrinsic) >> s @ 19 java.lang.StringBuffer::append (13 bytes) failed to inline: already compiled into a big method >> s @ 24 java.lang.StringBuffer::toString (44 bytes) inline (hot) late inline succeeded (string method) >> s @ 1 java.lang.StringBuffer::length (5 bytes) accessor >> @ 24 java.lang.String:: (98 bytes) failed to inline: already compiled into a big method >> @ 30 java.util.concurrent.atomic.AtomicReference::set (6 bytes) accessor >> 2025-07-02T09:25:53.396634900Z Attempt 1, found: false >> 2025-07-02T09:25:53.415673072Z Attempt 2, found: false >> 2025-07-02T09:25:53.418876867Z Attempt 3, found: false >> >> [...] > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Allow vm.debug Thanks for the reviews and feedback. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26033#issuecomment-3045085386 From rrich at openjdk.org Mon Jul 7 13:23:47 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Mon, 7 Jul 2025 13:23:47 GMT Subject: Integrated: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails because of unstable inlining In-Reply-To: References: Message-ID: On Sun, 29 Jun 2025 15:26:14 GMT, Richard Reingruber wrote: > This PR adds CompileCommands to the test DumpThreadsWithEliminatedLock.java to force inlining of java/lang/String*.* methods. This will make inlining more stable to allow for the expected lock elimination based on c2 escape analysis. > > Forcing inlining of java/lang/StringBuffer.* wasn't sufficient on x86_64. With that the test still failed with TieredCompilation disabled. > > Testing: x86_64, ppc64 manually. Other major platforms as part of our CI testing. > > Failed inlining on x86_64 with TieredCompilation disabled: > > > make test TEST=com/sun/management/HotSpotDiagnosticMXBean/DumpThreadsWithEliminatedLock.java TEST_VM_OPTS="-XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand=PrintInlining,DumpThreadsWithEliminatedLock.*" JTREG=TIMEOUT_FACTOR=0.1 > > [...] > > STDOUT: > CompileCommand: PrintInlining DumpThreadsWithEliminatedLock.* bool PrintInlining = true > @ 1 java.util.concurrent.atomic.AtomicBoolean::get (13 bytes) inline (hot) > @ 11 java.lang.StringBuffer:: (7 bytes) inline (hot) late inline succeeded (string method) > @ 3 java.lang.AbstractStringBuilder:: (39 bytes) inline (hot) > @ 1 java.lang.Object:: (1 bytes) inline (hot) > @ 16 java.lang.System::currentTimeMillis (0 bytes) (intrinsic) > s @ 19 java.lang.StringBuffer::append (13 bytes) failed to inline: already compiled into a big method > s @ 24 java.lang.StringBuffer::toString (44 bytes) inline (hot) late inline succeeded (string method) > s @ 1 java.lang.StringBuffer::length (5 bytes) accessor > @ 24 java.lang.String:: (98 bytes) failed to inline: already compiled into a big method > @ 30 java.util.concurrent.atomic.AtomicReference::set (6 bytes) accessor > 2025-07-02T09:25:53.396634900Z Attempt 1, found: false > 2025-07-02T09:25:53.415673072Z Attempt 2, found: false > 2025-07-02T09:25:53.418876867Z Attempt 3, found: false > > [...] This pull request has now been integrated. Changeset: fea73c1d Author: Richard Reingruber URL: https://git.openjdk.org/jdk/commit/fea73c1d40441561a246f2a09a739367cfc197ea Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails because of unstable inlining Reviewed-by: alanb, mdoerr, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/26033 From zgu at openjdk.org Mon Jul 7 13:32:56 2025 From: zgu at openjdk.org (Zhengyu Gu) Date: Mon, 7 Jul 2025 13:32:56 GMT Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v20] In-Reply-To: References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com> Message-ID: On Mon, 7 Jul 2025 07:57:32 GMT, Albert Mingkun Yang wrote: >> This patch refines Parallel's sizing strategy to improve overall memory management and performance. >> >> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`. >> >> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`. >> >> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`. >> >> ## Performance evaluation >> >> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)). >> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html). >> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing. >> >> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging. >> >> Test: tier1-8 > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits: > > - review > - Merge branch 'master' into pgc-size-policy > - review > - review > - Merge branch 'master' into pgc-size-policy > - Merge branch 'master' into pgc-size-policy > - review > - cast > - remove-young-resize-after-full-gc > - Merge branch 'master' into pgc-size-policy > - ... and 20 more: https://git.openjdk.org/jdk/compare/d75ea7e6...2e8e19db LGTM ------------- Marked as reviewed by zgu (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25000#pullrequestreview-2993906888 From zgu at openjdk.org Mon Jul 7 13:32:58 2025 From: zgu at openjdk.org (Zhengyu Gu) Date: Mon, 7 Jul 2025 13:32:58 GMT Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v13] In-Reply-To: References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com> <76NgHH-m26Nw2paJmIQvNNqio_iKtdQ_bJ2aejMfKEI=.82ff25aa-f5c5-4146-84b5-1aaaefb5efd1@github.com> <85HD8TnSUAI0GIc_xeF7SPzT52Mv3fAO2mUlm73M4_g=.d6300d71-32c6-4cc9-af9d-97d8a66f6264@github.com> Message-ID: On Sun, 6 Jul 2025 20:47:20 GMT, Albert Mingkun Yang wrote: >> src/hotspot/share/gc/parallel/parallelArguments.cpp line 71: >> >>> 69: // True in product build, since tests using debug build often stress GC >>> 70: if (FLAG_IS_DEFAULT(UseGCOverheadLimit)) { >>> 71: FLAG_SET_DEFAULT(UseGCOverheadLimit, trueInProduct); >> >> Given only Parallel honors `UseGCOverheadLimit`, you may want to set the default to `trueInProduct` in `gc_globals.hpp` > > It's indeed that only Parallel implements this flag. However, if we decide to change the default value of this flag globally, I feel we should do that in its own PR for better visibility. Currently, this changes the default value only for Parallel, as one expects in a PR titled "Parallel: ...". Okay. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2190120397 From zgu at openjdk.org Mon Jul 7 13:32:59 2025 From: zgu at openjdk.org (Zhengyu Gu) Date: Mon, 7 Jul 2025 13:32:59 GMT Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3] In-Reply-To: References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com> <3TWxib1SPBfTIp1lZkywBo9ztCtH5vr8QDMO1CI7V80=.6dc5b0cc-552b-4f75-a95d-c62d6e6025f3@github.com> Message-ID: On Mon, 7 Jul 2025 07:59:45 GMT, Albert Mingkun Yang wrote: >>> but OOM and heap dump have to be, in a sense of atomic >> >> I see; it can indeed be annoying that heap-dump doesn't capture the intended snapshot -- a java thread can trigger a gc that changes heap-content. However, AFAICS, fixing that non-atomic issue requires updating callers of `report_java_out_of_memory`. Therefore, I am inclined to think it should be addressed in its own ticket. It's a preexisting issue on master as well, not sth newly introduced by this PR. > > Does https://bugs.openjdk.org/browse/JDK-8347833 match the problem you have in mind? Yes. Sounds good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2190117730 From duke at openjdk.org Mon Jul 7 15:40:50 2025 From: duke at openjdk.org (Khalid Boulanouare) Date: Mon, 7 Jul 2025 15:40:50 GMT Subject: RFR: 8361188: Test java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java fails on Mac OS X Message-ID: Fixed an issue where null value component is not checked in class java/awt/Mixing/AWT_Mixing/OverlappingTestBase. Also removed test java/awt/Mixing/AWT_Mixing/JComboBoxOverlapping.java from problem list file. ------------- Depends on: https://git.openjdk.org/jdk/pull/25971 Commit messages: - Merge branch 'pr/25971' into jdk-8361188 - Merge branch 'pr/25971' into jdk-8361188 - Merge branch 'openjdk:master' into jdk-8361188 - Removes test from Problem List - Returns false if component is null, in the case of embedded frame Changes: https://git.openjdk.org/jdk/pull/26162/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26162&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361188 Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26162.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26162/head:pull/26162 PR: https://git.openjdk.org/jdk/pull/26162 From sspitsyn at openjdk.org Mon Jul 7 17:55:40 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 7 Jul 2025 17:55:40 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method In-Reply-To: References: Message-ID: On Fri, 4 Jul 2025 06:15:43 GMT, Alan Bateman wrote: >> Good suggestion, thanks. >> `NotifyFramePop` does not generate the `FramePop` events by itself it is just sets or enables events. >> Then should we say this way: "unable to set a `FramePop` event for the frame" ? > >> Then should we say this way: "unable to set a `FramePop` event for the frame" ? > > The can_generate_frame_pop_events capability uses "Can set .." so I think what you propose is good. Also the temptation may be to use the word "enable" where but that risks getting confused with enabling events. Right, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2190726907 From sspitsyn at openjdk.org Mon Jul 7 18:02:34 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 7 Jul 2025 18:02:34 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v2] In-Reply-To: References: Message-ID: > It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent. > This impacts the following JVMTI functions: > - `PopFrame` > - `NotifyFramePop` > - `ForceEarlyReturn` > > A related CSR is going to be filed for this spec update. > > Testing: > - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: tweak OPAQUE_FRAME clarification for NotifyFramePop function ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26111/files - new: https://git.openjdk.org/jdk/pull/26111/files/1d017ea8..c2cbd0d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26111&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26111&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26111.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26111/head:pull/26111 PR: https://git.openjdk.org/jdk/pull/26111 From sspitsyn at openjdk.org Mon Jul 7 18:13:19 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 7 Jul 2025 18:13:19 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v3] In-Reply-To: References: Message-ID: <8QJ2M_GNYwi50gKBHG47B_13KQ-vHU11VrOleSlrMss=.c081db9f-eda6-41f8-b927-c4d1661ddbbf@github.com> > It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent. > This impacts the following JVMTI functions: > - `PopFrame` > - `NotifyFramePop` > - `ForceEarlyReturn` > > A related CSR is going to be filed for this spec update. > > Testing: > - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: tweak the OPAQUE_FRAME clarifications for ForceEarlyReturn* functions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26111/files - new: https://git.openjdk.org/jdk/pull/26111/files/c2cbd0d3..0c6ef896 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26111&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26111&range=01-02 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26111.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26111/head:pull/26111 PR: https://git.openjdk.org/jdk/pull/26111 From sspitsyn at openjdk.org Mon Jul 7 18:13:19 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 7 Jul 2025 18:13:19 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v3] In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 18:45:04 GMT, Chris Plummer wrote: >> src/hotspot/share/prims/jvmti.xml line 3191: >> >>> 3189: >>> 3190: >>> 3191: The implementation is unable to force current frame to return >> >> Suggestion: >> >> The implementation is unable to force the current frame to return > > Note this error repeats a few times below. I only tagged this one. Thanks! Fixed now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2190751011 From cjplummer at openjdk.org Mon Jul 7 18:33:39 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 7 Jul 2025 18:33:39 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v3] In-Reply-To: References: Message-ID: On Mon, 7 Jul 2025 17:53:07 GMT, Serguei Spitsyn wrote: >>> Then should we say this way: "unable to set a `FramePop` event for the frame" ? >> >> The can_generate_frame_pop_events capability uses "Can set .." so I think what you propose is good. Also the temptation may be to use the word "enable" where but that risks getting confused with enabling events. > > Right, thanks! Fixed now. I don't think this sounds right. You don't "set" a FramePop event. You tell JVMTI to generate a FramePop event when this frame is popped. Maybe something like "A FramePop event cannot be generated for this frame". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2190788001 From sspitsyn at openjdk.org Mon Jul 7 18:43:48 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 7 Jul 2025 18:43:48 GMT Subject: RFR: 8361325: Refactor ClassLoaderExt [v2] In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 17:08:44 GMT, Calvin Cheung wrote: >> src/hotspot/share/cds/classListParser.cpp line 33: >> >>> 31: #include "cds/metaspaceShared.hpp" >>> 32: #include "cds/unregisteredClasses.hpp" >>> 33: #include "classfile/classLoader.hpp" >> >> Nit: I wonder if the line #33 is really needed and can be removed. > > It is needed or else I got compilation error: > > open/src/hotspot/share/cds/classListParser.cpp:561:29: error: 'ClassLoader' has not been declared > 561 | const char* source_path = ClassLoader::uri_to_path(_source); > | ^~~~~~~~~~~ > > It worked before because classLoaderExt.hpp includes classLoader.hpp. Okay, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26110#discussion_r2190802836 From cjplummer at openjdk.org Mon Jul 7 18:46:40 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 7 Jul 2025 18:46:40 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v3] In-Reply-To: <8QJ2M_GNYwi50gKBHG47B_13KQ-vHU11VrOleSlrMss=.c081db9f-eda6-41f8-b927-c4d1661ddbbf@github.com> References: <8QJ2M_GNYwi50gKBHG47B_13KQ-vHU11VrOleSlrMss=.c081db9f-eda6-41f8-b927-c4d1661ddbbf@github.com> Message-ID: On Mon, 7 Jul 2025 18:13:19 GMT, Serguei Spitsyn wrote: >> It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent. >> This impacts the following JVMTI functions: >> - `PopFrame` >> - `NotifyFramePop` >> - `ForceEarlyReturn` >> >> A related CSR is going to be filed for this spec update. >> >> Testing: >> - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: tweak the OPAQUE_FRAME clarifications for ForceEarlyReturn* functions src/hotspot/share/prims/jvmti.xml line 3082: > 3080: > 3081: The implementation is unable to set a event for the frame > 3082: (e.g. the frame at depth is executing a native method). I don't think this sounds right. You don't "set" a FramePop event. You tell JVMTI to generate a FramePop event when this frame is popped. Maybe something like "A FramePop event cannot be generated for this frame". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2190807109 From cjplummer at openjdk.org Mon Jul 7 18:52:45 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 7 Jul 2025 18:52:45 GMT Subject: RFR: 8359958: Cleanup "local" debuggee references after JDK-8333117 removed support for non-local debuggees [v2] In-Reply-To: <8qFFnwzJwKtq1uKNtPINZE80QDx7t9IeQlR4LBg4rOo=.1375d71e-f7cb-4506-af13-60be46c24cb0@github.com> References: <8qFFnwzJwKtq1uKNtPINZE80QDx7t9IeQlR4LBg4rOo=.1375d71e-f7cb-4506-af13-60be46c24cb0@github.com> Message-ID: On Thu, 19 Jun 2025 00:33:42 GMT, Chris Plummer wrote: >> [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117) removed support for non-local debuggees, so now only local debuggees are supported. However, there are now a lot of references to the "local" debuggee mode which are not necessary because "local" is implied. These references are in comments and API names and should be removed. >> >> Also, after [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117), DebugeeProcess no longer needs to be considered abstract. It has no abstract methods. >> >> Tested nsk/jdi, nsk/jdb, and nsk/jdwp locally. Will run tier5 CI to get better coverage. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > startLocalDebugee renamed to startDebugee Thanks for the reviews Leonid, Serguei, and Alex! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25887#issuecomment-3046201976 From cjplummer at openjdk.org Mon Jul 7 18:52:45 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 7 Jul 2025 18:52:45 GMT Subject: Integrated: 8359958: Cleanup "local" debuggee references after JDK-8333117 removed support for non-local debuggees In-Reply-To: References: Message-ID: <_RJ2DRZKPcSOvEVK520Ii5mKzHyyL1KSKlD1qAYXfiM=.2e813b33-f6d0-409b-860f-1924b42aa3f5@github.com> On Wed, 18 Jun 2025 22:13:34 GMT, Chris Plummer wrote: > [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117) removed support for non-local debuggees, so now only local debuggees are supported. However, there are now a lot of references to the "local" debuggee mode which are not necessary because "local" is implied. These references are in comments and API names and should be removed. > > Also, after [JDK-8333117](https://bugs.openjdk.org/browse/JDK-8333117), DebugeeProcess no longer needs to be considered abstract. It has no abstract methods. > > Tested nsk/jdi, nsk/jdb, and nsk/jdwp locally. Will run tier5 CI to get better coverage. This pull request has now been integrated. Changeset: 39c9de2a Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/39c9de2acea0537335230b1d1db606d90348bdb6 Stats: 105 lines in 19 files changed: 0 ins; 15 del; 90 mod 8359958: Cleanup "local" debuggee references after JDK-8333117 removed support for non-local debuggees Reviewed-by: lmesnik, sspitsyn, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/25887 From cjplummer at openjdk.org Mon Jul 7 19:30:40 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 7 Jul 2025 19:30:40 GMT Subject: RFR: 8351487: [ubsan] jvmti.h runtime error: load of value which is not a valid value In-Reply-To: <1-9RRDL18MUUtoGa3krcB6A_An6SATisnVldYbELMFo=.86eef7ef-c4a1-4e20-97fa-1aa7d8383e57@github.com> References: <1-9RRDL18MUUtoGa3krcB6A_An6SATisnVldYbELMFo=.86eef7ef-c4a1-4e20-97fa-1aa7d8383e57@github.com> Message-ID: <6TWqCbcc92wo7tD39KGy4o5m4dxNBIS8gX73HCssQ6E=.f777306b-8469-4864-b5ac-64ccc011a29c@github.com> On Mon, 7 Jul 2025 12:21:06 GMT, Matthias Baesken wrote: > When running with ubsan - enabled binaries, the following 2 issues are observed in jvmti.h (on macOS aarch64). > > > jtreg test vmTestbase/nsk/jvmti/SetVerboseFlag/setvrbflag002/TestDescription.java > > /priv/jenkins/client-home/workspace/openjdk-jdk-weekly-macos_aarch64-opt/build/support/modules_include/java.base/jvmti.h:2645:44: runtime error: load of value 4294967295, which is not a valid value for type 'jvmtiVerboseFlag' > #0 0x104453540 in _jvmtiEnv::SetVerboseFlag(jvmtiVerboseFlag, unsigned char) jvmti.h:2645 > #1 0x10444ed5c in agentProc(_jvmtiEnv*, JNIEnv_*, void*) setvrbflag002.cpp:49 > #2 0x10444f1c8 in agentThreadWrapper(_jvmtiEnv*, JNIEnv_*, void*) agent_tools.cpp:151 > #3 0x10914895c in JvmtiAgentThread::call_start_function() jvmtiImpl.cpp:89 > #4 0x108ebd7f0 in JavaThread::thread_main_inner() javaThread.cpp:776 > #5 0x1096f6094 in Thread::call_run() thread.cpp:231 > #6 0x10941c37c in thread_native_entry(Thread*) os_bsd.cpp:601 > #7 0x1936fef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90) > #8 0x1936f9d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30) > > vmTestbase/nsk/jvmti/GetErrorName/geterrname002/TestDescription.java > > /priv/jenkins/client-home/workspace/openjdk-jdk-weekly-macos_aarch64-opt/build/support/modules_include/java.base/jvmti.h:2640:42: runtime error: load of value 4294967295, which is not a valid value for type 'jvmtiError' > #0 0x1002b3504 in _jvmtiEnv::GetErrorName(jvmtiError, char**) jvmti.h:2640 > #1 0x1002aec9c in agentProc(_jvmtiEnv*, JNIEnv_*, void*) geterrname002.cpp:50 > #2 0x1002af198 in agentThreadWrapper(_jvmtiEnv*, JNIEnv_*, void*) agent_tools.cpp:151 > #3 0x104f4895c in JvmtiAgentThread::call_start_function() jvmtiImpl.cpp:89 > #4 0x104cbd7f0 in JavaThread::thread_main_inner() javaThread.cpp:776 > #5 0x1054f6094 in Thread::call_run() thread.cpp:231 > #6 0x10521c37c in thread_native_entry(Thread*) os_bsd.cpp:601 > #7 0x1936fef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90) > #8 0x1936f9d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30) > > > So the problem reported is SetVerboseFlag method (which is part of the VM) calls SetVerboseFlag function with that bad argument ; but the test code seems to intentionally use 'bad' arguments . But this does not work well with ubsan ; so better exclude those tests from ubsan checking . > Please note that jvmti.h is shipped so adding some macros/attributes to methods for avoiding ubsan is probab... This is somewhat of an odd situation. SetVerboseFlag() says the argument type is an enum, but it treats it like an int and does error checking to make sure it one of the enum values. If ubsan dug a little deeper to see how the argument is handled, it would see that and not complain. test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetErrorName/geterrname002/TestDescription.java line 38: > 36: * COMMENTS > 37: * > 38: * @requires !vm.ubsan Needs an @comment test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetVerboseFlag/setvrbflag002/TestDescription.java line 37: > 35: * COMMENTS > 36: * > 37: * @requires !vm.ubsan Needs an @comment ------------- Changes requested by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26159#pullrequestreview-2995047256 PR Review Comment: https://git.openjdk.org/jdk/pull/26159#discussion_r2190865703 PR Review Comment: https://git.openjdk.org/jdk/pull/26159#discussion_r2190866138 From cjplummer at openjdk.org Mon Jul 7 20:30:39 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 7 Jul 2025 20:30:39 GMT Subject: RFR: 8305567: serviceability/tmtools/jstat/GcTest01.java failed utils.JstatGcResults.assertConsistency [v2] In-Reply-To: <722Bm9j0Zqx8Oo5no5Q-z-FhxGKkQ79HFMute4nA8AU=.6cc44a6a-4dda-46ee-ad06-ad9d338370a9@github.com> References: <722Bm9j0Zqx8Oo5no5Q-z-FhxGKkQ79HFMute4nA8AU=.6cc44a6a-4dda-46ee-ad06-ad9d338370a9@github.com> Message-ID: On Mon, 7 Jul 2025 09:09:31 GMT, Kevin Walls wrote: >> There is no guarantee of consistency when sampling jstat data, and we're asserting these figures are always consistent. >> Tests should retry some small number of times, rerunning the jstat tool to recapture data. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > modifier order Looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26094#pullrequestreview-2995185649 From sspitsyn at openjdk.org Mon Jul 7 21:08:44 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 7 Jul 2025 21:08:44 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v3] In-Reply-To: References: <8QJ2M_GNYwi50gKBHG47B_13KQ-vHU11VrOleSlrMss=.c081db9f-eda6-41f8-b927-c4d1661ddbbf@github.com> Message-ID: <7bSfuttUn1EO5IsDt1cxstnbccUm0IXWMwLRt92qiWM=.b70585d6-2928-4ad8-a5e8-8ea3fbd2b532@github.com> On Mon, 7 Jul 2025 18:44:13 GMT, Chris Plummer wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: tweak the OPAQUE_FRAME clarifications for ForceEarlyReturn* functions > > src/hotspot/share/prims/jvmti.xml line 3082: > >> 3080: >> 3081: The implementation is unable to set a event for the frame >> 3082: (e.g. the frame at depth is executing a native method). > > I don't think this sounds right. You don't "set" a FramePop event. You tell JVMTI to generate a FramePop event when this frame is popped. Maybe something like "A FramePop event cannot be generated for this frame". Thank you for the comment. The `NotifyFramePop` is similar to `SetBreakpoint`. I'd even prefer it is named accordingly: `SetFramePop` instead of `NotifyFramePop`. We enable any kinds of events with `SetEventNotoficationMode` but there cases where we need to be more specific in setting the events. The `SetBreakpoint` is to set a breakpoint at a specific method's bytecode. The `NotifyFramePop` is to set `FramePop` for a specific frame. So, I' prefer to keep the terminology similar for `Breakpoints` and `FramePop` events. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2191012054 From sspitsyn at openjdk.org Mon Jul 7 21:12:42 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 7 Jul 2025 21:12:42 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v3] In-Reply-To: References: Message-ID: <47TQcDecd7pUiEMcGleu8uAehEl40U22pjqdw2Qs4TQ=.8329e512-531f-4903-94cf-1fc7814c7559@github.com> On Thu, 3 Jul 2025 18:44:09 GMT, Chris Plummer wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: tweak the OPAQUE_FRAME clarifications for ForceEarlyReturn* functions > > src/hotspot/share/prims/jvmti.xml line 3194: > >> 3192: (e.g. current frame is executing a native method). >> 3193: >> 3194: > > Do we still need this section? Same question for repeated sections below. Thank you for suggestion. Let's think on this a little bit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2191017166 From amenkov at openjdk.org Tue Jul 8 00:09:13 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 8 Jul 2025 00:09:13 GMT Subject: RFR: 8358679: [asan] vmTestbase/nsk/jvmti tests show memory issues Message-ID: The fix updates several tests ASAN complains about. Tests for RawMonitors intentionally passes bad pointer to tested function, they should not be run with ASAN. Test vmTestbase/nsk/jvmti/scenarios/events/EM07/em07t002 verifies COMPILED_METHOD_LOAD/COMPILED_METHOD_UNLOAD event and uses RawMonitor for synchronization. It destroys the monitor, but some events may arrive later (before VM exits). Usually JVMTI tests do not destroy synchronization monitors, removed destruction here. ------------- Commit messages: - fix Changes: https://git.openjdk.org/jdk/pull/26176/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26176&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358679 Stats: 25 lines in 6 files changed: 15 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26176.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26176/head:pull/26176 PR: https://git.openjdk.org/jdk/pull/26176 From jwaters at openjdk.org Tue Jul 8 01:30:08 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 8 Jul 2025 01:30:08 GMT Subject: Integrated: 8342682: Errors related to unused code on Windows after 8339120 in dt_shmem jdwp security and jpackage In-Reply-To: References: Message-ID: <-TK5ziYVLfu1MOHf70wFHbnT7bhXhOq0mXLI4HOphJE=.37fea4b0-0383-4e9d-baf6-60f437ac92d1@github.com> On Mon, 21 Oct 2024 14:34:30 GMT, Julian Waters wrote: > After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did This pull request has now been integrated. Changeset: 563a3358 Author: Julian Waters URL: https://git.openjdk.org/jdk/commit/563a3358f6f1ecff816318cbb32376487365c1fa Stats: 8 lines in 4 files changed: 2 ins; 3 del; 3 mod 8342682: Errors related to unused code on Windows after 8339120 in dt_shmem jdwp security and jpackage Reviewed-by: cjplummer, asemenyuk, almatvee ------------- PR: https://git.openjdk.org/jdk/pull/21616 From cjplummer at openjdk.org Tue Jul 8 05:01:47 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 8 Jul 2025 05:01:47 GMT Subject: RFR: 8358679: [asan] vmTestbase/nsk/jvmti tests show memory issues In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 00:01:50 GMT, Alex Menkov wrote: > The fix updates several tests ASAN complains about. > Tests for RawMonitors intentionally passes bad pointer to tested function, they should not be run with ASAN. > Test vmTestbase/nsk/jvmti/scenarios/events/EM07/em07t002 verifies COMPILED_METHOD_LOAD/COMPILED_METHOD_UNLOAD event and uses RawMonitor for synchronization. It destroys the monitor, but some events may arrive later (before VM exits). Usually JVMTI tests do not destroy synchronization monitors, removed destruction here. test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorEnter/rawmonenter003/TestDescription.java line 41: > 39: * > 40: * @comment the test intentionally passes bad argument to the function to verify the functionality, > 41: it causes false positive from ASAN lib Suggestion: * @comment The test intentionally passes a bad argument to the function to verify error checking, which causes a false positive from the ASAN lib Same comment for the other tests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26176#discussion_r2191478686 From kevinw at openjdk.org Tue Jul 8 06:40:46 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 8 Jul 2025 06:40:46 GMT Subject: RFR: 8305567: serviceability/tmtools/jstat/GcTest01.java failed utils.JstatGcResults.assertConsistency [v2] In-Reply-To: <722Bm9j0Zqx8Oo5no5Q-z-FhxGKkQ79HFMute4nA8AU=.6cc44a6a-4dda-46ee-ad06-ad9d338370a9@github.com> References: <722Bm9j0Zqx8Oo5no5Q-z-FhxGKkQ79HFMute4nA8AU=.6cc44a6a-4dda-46ee-ad06-ad9d338370a9@github.com> Message-ID: On Mon, 7 Jul 2025 09:09:31 GMT, Kevin Walls wrote: >> There is no guarantee of consistency when sampling jstat data, and we're asserting these figures are always consistent. >> Tests should retry some small number of times, rerunning the jstat tool to recapture data. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > modifier order Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26094#issuecomment-3047558159 From kevinw at openjdk.org Tue Jul 8 06:40:48 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 8 Jul 2025 06:40:48 GMT Subject: Integrated: 8305567: serviceability/tmtools/jstat/GcTest01.java failed utils.JstatGcResults.assertConsistency In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 11:42:23 GMT, Kevin Walls wrote: > There is no guarantee of consistency when sampling jstat data, and we're asserting these figures are always consistent. > Tests should retry some small number of times, rerunning the jstat tool to recapture data. This pull request has now been integrated. Changeset: 310ef856 Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/310ef85667bdba3f984cb6327aee71cfaf91458b Stats: 101 lines in 10 files changed: 60 ins; 12 del; 29 mod 8305567: serviceability/tmtools/jstat/GcTest01.java failed utils.JstatGcResults.assertConsistency Reviewed-by: cjplummer, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/26094 From mbaesken at openjdk.org Tue Jul 8 08:27:21 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 8 Jul 2025 08:27:21 GMT Subject: RFR: 8351487: [ubsan] jvmti.h runtime error: load of value which is not a valid value [v2] In-Reply-To: <1-9RRDL18MUUtoGa3krcB6A_An6SATisnVldYbELMFo=.86eef7ef-c4a1-4e20-97fa-1aa7d8383e57@github.com> References: <1-9RRDL18MUUtoGa3krcB6A_An6SATisnVldYbELMFo=.86eef7ef-c4a1-4e20-97fa-1aa7d8383e57@github.com> Message-ID: > When running with ubsan - enabled binaries, the following 2 issues are observed in jvmti.h (on macOS aarch64). > > > jtreg test vmTestbase/nsk/jvmti/SetVerboseFlag/setvrbflag002/TestDescription.java > > /priv/jenkins/client-home/workspace/openjdk-jdk-weekly-macos_aarch64-opt/build/support/modules_include/java.base/jvmti.h:2645:44: runtime error: load of value 4294967295, which is not a valid value for type 'jvmtiVerboseFlag' > #0 0x104453540 in _jvmtiEnv::SetVerboseFlag(jvmtiVerboseFlag, unsigned char) jvmti.h:2645 > #1 0x10444ed5c in agentProc(_jvmtiEnv*, JNIEnv_*, void*) setvrbflag002.cpp:49 > #2 0x10444f1c8 in agentThreadWrapper(_jvmtiEnv*, JNIEnv_*, void*) agent_tools.cpp:151 > #3 0x10914895c in JvmtiAgentThread::call_start_function() jvmtiImpl.cpp:89 > #4 0x108ebd7f0 in JavaThread::thread_main_inner() javaThread.cpp:776 > #5 0x1096f6094 in Thread::call_run() thread.cpp:231 > #6 0x10941c37c in thread_native_entry(Thread*) os_bsd.cpp:601 > #7 0x1936fef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90) > #8 0x1936f9d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30) > > vmTestbase/nsk/jvmti/GetErrorName/geterrname002/TestDescription.java > > /priv/jenkins/client-home/workspace/openjdk-jdk-weekly-macos_aarch64-opt/build/support/modules_include/java.base/jvmti.h:2640:42: runtime error: load of value 4294967295, which is not a valid value for type 'jvmtiError' > #0 0x1002b3504 in _jvmtiEnv::GetErrorName(jvmtiError, char**) jvmti.h:2640 > #1 0x1002aec9c in agentProc(_jvmtiEnv*, JNIEnv_*, void*) geterrname002.cpp:50 > #2 0x1002af198 in agentThreadWrapper(_jvmtiEnv*, JNIEnv_*, void*) agent_tools.cpp:151 > #3 0x104f4895c in JvmtiAgentThread::call_start_function() jvmtiImpl.cpp:89 > #4 0x104cbd7f0 in JavaThread::thread_main_inner() javaThread.cpp:776 > #5 0x1054f6094 in Thread::call_run() thread.cpp:231 > #6 0x10521c37c in thread_native_entry(Thread*) os_bsd.cpp:601 > #7 0x1936fef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90) > #8 0x1936f9d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30) > > > So the problem reported is SetVerboseFlag method (which is part of the VM) calls SetVerboseFlag function with that bad argument ; but the test code seems to intentionally use 'bad' arguments . But this does not work well with ubsan ; so better exclude those tests from ubsan checking . > Please note that jvmti.h is shipped so adding some macros/attributes to methods for avoiding ubsan is probab... Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Add comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26159/files - new: https://git.openjdk.org/jdk/pull/26159/files/a346557b..a0ca0ddc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26159&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26159&range=00-01 Stats: 4 lines in 2 files changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26159.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26159/head:pull/26159 PR: https://git.openjdk.org/jdk/pull/26159 From dbriemann at openjdk.org Tue Jul 8 13:27:20 2025 From: dbriemann at openjdk.org (David Briemann) Date: Tue, 8 Jul 2025 13:27:20 GMT Subject: RFR: 8361599: [PPC64] enable missing tests via jtreg requires Message-ID: Some tests are not executed on PPC little or big endian because the current requires annotation only checks for "ppc64" or "ppc64le" but not both. ------------- Commit messages: - 8361599: [PPC64] enable missing tests via jtreg requires Changes: https://git.openjdk.org/jdk/pull/26184/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26184&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361599 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26184.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26184/head:pull/26184 PR: https://git.openjdk.org/jdk/pull/26184 From dbriemann at openjdk.org Tue Jul 8 14:17:21 2025 From: dbriemann at openjdk.org (David Briemann) Date: Tue, 8 Jul 2025 14:17:21 GMT Subject: RFR: 8361599: [PPC64] enable missing tests via jtreg requires [v2] In-Reply-To: References: Message-ID: > Some tests are not executed on PPC little or big endian because the current requires annotation only checks for "ppc64" or "ppc64le" but not both. David Briemann has updated the pull request incrementally with one additional commit since the last revision: adapt copyrights ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26184/files - new: https://git.openjdk.org/jdk/pull/26184/files/d0a1efa1..f79e2895 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26184&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26184&range=00-01 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26184.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26184/head:pull/26184 PR: https://git.openjdk.org/jdk/pull/26184 From mdoerr at openjdk.org Tue Jul 8 14:26:41 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 8 Jul 2025 14:26:41 GMT Subject: RFR: 8361599: [PPC64] enable missing tests via jtreg requires [v2] In-Reply-To: References: Message-ID: <5JXgG6JiUbQ4tvgG_bN_KoZ65M3Y8so4259bmvJufWY=.22c34a1a-dbbe-4bb2-961f-d90097077d5b@github.com> On Tue, 8 Jul 2025 14:17:21 GMT, David Briemann wrote: >> Some tests are not executed on PPC little or big endian because the current requires annotation only checks for "ppc64" or "ppc64le" but not both. > > David Briemann has updated the pull request incrementally with one additional commit since the last revision: > > adapt copyrights Looks good and trivial. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26184#pullrequestreview-2997902196 From cjplummer at openjdk.org Tue Jul 8 18:03:17 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 8 Jul 2025 18:03:17 GMT Subject: [jdk25] RFR: 8360312: Serviceability Agent tests fail with JFR enabled due to unknown thread type JfrRecorderThread Message-ID: Clean backport of [JDK-8360312](https://bugs.openjdk.org/browse/JDK-8360312). The bug was introduced in JDK25 and fixed in JDK26, so should be backported to JDK25. ------------- Commit messages: - Backport 712d866b72b43c839c57c3303dfb215f94c0db3b Changes: https://git.openjdk.org/jdk/pull/26198/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26198&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360312 Stats: 25 lines in 5 files changed: 13 ins; 9 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26198/head:pull/26198 PR: https://git.openjdk.org/jdk/pull/26198 From kevinw at openjdk.org Tue Jul 8 18:19:38 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 8 Jul 2025 18:19:38 GMT Subject: [jdk25] RFR: 8360312: Serviceability Agent tests fail with JFR enabled due to unknown thread type JfrRecorderThread In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 17:57:40 GMT, Chris Plummer wrote: > Clean backport of [JDK-8360312](https://bugs.openjdk.org/browse/JDK-8360312). The bug was introduced in JDK25 and fixed in JDK26, so should be backported to JDK25. > > Tier5 ci testing in progress. Marked as reviewed by kevinw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26198#pullrequestreview-2998666738 From amenkov at openjdk.org Tue Jul 8 19:32:48 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 8 Jul 2025 19:32:48 GMT Subject: Integrated: 8355960: JvmtiAgentList::Iterator dtor double free with -fno-elide-constructors In-Reply-To: References: Message-ID: On Wed, 2 Jul 2025 01:47:59 GMT, Alex Menkov wrote: > Currently jvmtiAgentList keeps agents in reversed order (new agents are added to the head of the list). > To restore original order JvmtiAgentList::Iterator uses GrowableArray allocated in heap. > Iterators for different agent types are returned by value, and the iterator class nas no custom copy ctor, so if the constructor not elides, GrowableArray is deallocated twice. > > The fix updates jvmtiAgentList to keep agents in the original order, agents are added to the tail. > Iterator now needs only single pointer to next agent. > Additionally removed `JvmtiAgentList::Iterator::next() const` method (it looks very strange as `next()` is expected to change state of the iterator). > > Testing: tier1..4,hs-tier5-svc This pull request has now been integrated. Changeset: 03526e25 Author: Alex Menkov URL: https://git.openjdk.org/jdk/commit/03526e250dfb9ac61f50f482b5dfb330e7fec1bf Stats: 83 lines in 6 files changed: 23 ins; 35 del; 25 mod 8355960: JvmtiAgentList::Iterator dtor double free with -fno-elide-constructors Reviewed-by: dholmes, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/26083 From amenkov at openjdk.org Tue Jul 8 19:37:25 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 8 Jul 2025 19:37:25 GMT Subject: RFR: 8358679: [asan] vmTestbase/nsk/jvmti tests show memory issues [v2] In-Reply-To: References: Message-ID: > The fix updates several tests ASAN complains about. > Tests for RawMonitors intentionally passes bad pointer to tested function, they should not be run with ASAN. > Test vmTestbase/nsk/jvmti/scenarios/events/EM07/em07t002 verifies COMPILED_METHOD_LOAD/COMPILED_METHOD_UNLOAD event and uses RawMonitor for synchronization. It destroys the monitor, but some events may arrive later (before VM exits). Usually JVMTI tests do not destroy synchronization monitors, removed destruction here. Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: Update test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorEnter/rawmonenter003/TestDescription.java Co-authored-by: Chris Plummer ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26176/files - new: https://git.openjdk.org/jdk/pull/26176/files/270e1db4..a6480938 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26176&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26176&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26176.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26176/head:pull/26176 PR: https://git.openjdk.org/jdk/pull/26176 From amenkov at openjdk.org Tue Jul 8 19:41:26 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 8 Jul 2025 19:41:26 GMT Subject: RFR: 8358679: [asan] vmTestbase/nsk/jvmti tests show memory issues [v3] In-Reply-To: References: Message-ID: > The fix updates several tests ASAN complains about. > Tests for RawMonitors intentionally passes bad pointer to tested function, they should not be run with ASAN. > Test vmTestbase/nsk/jvmti/scenarios/events/EM07/em07t002 verifies COMPILED_METHOD_LOAD/COMPILED_METHOD_UNLOAD event and uses RawMonitor for synchronization. It destroys the monitor, but some events may arrive later (before VM exits). Usually JVMTI tests do not destroy synchronization monitors, removed destruction here. Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26176/files - new: https://git.openjdk.org/jdk/pull/26176/files/a6480938..337fef05 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26176&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26176&range=01-02 Stats: 8 lines in 4 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/26176.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26176/head:pull/26176 PR: https://git.openjdk.org/jdk/pull/26176 From amenkov at openjdk.org Tue Jul 8 19:41:26 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 8 Jul 2025 19:41:26 GMT Subject: RFR: 8358679: [asan] vmTestbase/nsk/jvmti tests show memory issues [v3] In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 04:59:26 GMT, Chris Plummer wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> feedback > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/RawMonitorEnter/rawmonenter003/TestDescription.java line 41: > >> 39: * >> 40: * @comment the test intentionally passes bad argument to the function to verify the functionality, >> 41: it causes false positive from ASAN lib > > Suggestion: > > * @comment The test intentionally passes a bad argument to the function to verify error checking, > which causes a false positive from the ASAN lib > > > Same comment for the other tests. Updated as suggested ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26176#discussion_r2193308770 From amenkov at openjdk.org Tue Jul 8 19:49:40 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 8 Jul 2025 19:49:40 GMT Subject: RFR: 8351487: [ubsan] jvmti.h runtime error: load of value which is not a valid value [v2] In-Reply-To: References: <1-9RRDL18MUUtoGa3krcB6A_An6SATisnVldYbELMFo=.86eef7ef-c4a1-4e20-97fa-1aa7d8383e57@github.com> Message-ID: On Tue, 8 Jul 2025 08:27:21 GMT, Matthias Baesken wrote: >> When running with ubsan - enabled binaries, the following 2 issues are observed in jvmti.h (on macOS aarch64). >> >> >> jtreg test vmTestbase/nsk/jvmti/SetVerboseFlag/setvrbflag002/TestDescription.java >> >> /priv/jenkins/client-home/workspace/openjdk-jdk-weekly-macos_aarch64-opt/build/support/modules_include/java.base/jvmti.h:2645:44: runtime error: load of value 4294967295, which is not a valid value for type 'jvmtiVerboseFlag' >> #0 0x104453540 in _jvmtiEnv::SetVerboseFlag(jvmtiVerboseFlag, unsigned char) jvmti.h:2645 >> #1 0x10444ed5c in agentProc(_jvmtiEnv*, JNIEnv_*, void*) setvrbflag002.cpp:49 >> #2 0x10444f1c8 in agentThreadWrapper(_jvmtiEnv*, JNIEnv_*, void*) agent_tools.cpp:151 >> #3 0x10914895c in JvmtiAgentThread::call_start_function() jvmtiImpl.cpp:89 >> #4 0x108ebd7f0 in JavaThread::thread_main_inner() javaThread.cpp:776 >> #5 0x1096f6094 in Thread::call_run() thread.cpp:231 >> #6 0x10941c37c in thread_native_entry(Thread*) os_bsd.cpp:601 >> #7 0x1936fef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90) >> #8 0x1936f9d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30) >> >> vmTestbase/nsk/jvmti/GetErrorName/geterrname002/TestDescription.java >> >> /priv/jenkins/client-home/workspace/openjdk-jdk-weekly-macos_aarch64-opt/build/support/modules_include/java.base/jvmti.h:2640:42: runtime error: load of value 4294967295, which is not a valid value for type 'jvmtiError' >> #0 0x1002b3504 in _jvmtiEnv::GetErrorName(jvmtiError, char**) jvmti.h:2640 >> #1 0x1002aec9c in agentProc(_jvmtiEnv*, JNIEnv_*, void*) geterrname002.cpp:50 >> #2 0x1002af198 in agentThreadWrapper(_jvmtiEnv*, JNIEnv_*, void*) agent_tools.cpp:151 >> #3 0x104f4895c in JvmtiAgentThread::call_start_function() jvmtiImpl.cpp:89 >> #4 0x104cbd7f0 in JavaThread::thread_main_inner() javaThread.cpp:776 >> #5 0x1054f6094 in Thread::call_run() thread.cpp:231 >> #6 0x10521c37c in thread_native_entry(Thread*) os_bsd.cpp:601 >> #7 0x1936fef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90) >> #8 0x1936f9d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30) >> >> >> So the problem reported is SetVerboseFlag method (which is part of the VM) calls SetVerboseFlag function with that bad argument ; but the test code seems to intentionally use 'bad' arguments . But this does not work well with ubsan ; so better exclude those tests from ubsan checking . >> Please note that jvmti.h is shipped so adding... > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Add comments test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetErrorName/geterrname002/TestDescription.java line 39: > 37: * > 38: * @requires !vm.ubsan > 39: * @comment We test with arguments out of scope of the jvmti enums, this causes Could you please place the comments before `@requires` tags ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26159#discussion_r2193321360 From mdoerr at openjdk.org Tue Jul 8 21:27:40 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 8 Jul 2025 21:27:40 GMT Subject: RFR: 8361599: [PPC64] enable missing tests via jtreg requires [v2] In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 14:17:21 GMT, David Briemann wrote: >> Some tests are not executed on PPC little or big endian because the current requires annotation only checks for "ppc64" or "ppc64le" but not both. > > David Briemann has updated the pull request incrementally with one additional commit since the last revision: > > adapt copyrights Tests have passed on linux PPC64 Big Endian. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26184#issuecomment-3050341686 From cjplummer at openjdk.org Tue Jul 8 22:14:39 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 8 Jul 2025 22:14:39 GMT Subject: RFR: 8351487: [ubsan] jvmti.h runtime error: load of value which is not a valid value [v2] In-Reply-To: References: <1-9RRDL18MUUtoGa3krcB6A_An6SATisnVldYbELMFo=.86eef7ef-c4a1-4e20-97fa-1aa7d8383e57@github.com> Message-ID: On Tue, 8 Jul 2025 08:27:21 GMT, Matthias Baesken wrote: >> When running with ubsan - enabled binaries, the following 2 issues are observed in jvmti.h (on macOS aarch64). >> >> >> jtreg test vmTestbase/nsk/jvmti/SetVerboseFlag/setvrbflag002/TestDescription.java >> >> /priv/jenkins/client-home/workspace/openjdk-jdk-weekly-macos_aarch64-opt/build/support/modules_include/java.base/jvmti.h:2645:44: runtime error: load of value 4294967295, which is not a valid value for type 'jvmtiVerboseFlag' >> #0 0x104453540 in _jvmtiEnv::SetVerboseFlag(jvmtiVerboseFlag, unsigned char) jvmti.h:2645 >> #1 0x10444ed5c in agentProc(_jvmtiEnv*, JNIEnv_*, void*) setvrbflag002.cpp:49 >> #2 0x10444f1c8 in agentThreadWrapper(_jvmtiEnv*, JNIEnv_*, void*) agent_tools.cpp:151 >> #3 0x10914895c in JvmtiAgentThread::call_start_function() jvmtiImpl.cpp:89 >> #4 0x108ebd7f0 in JavaThread::thread_main_inner() javaThread.cpp:776 >> #5 0x1096f6094 in Thread::call_run() thread.cpp:231 >> #6 0x10941c37c in thread_native_entry(Thread*) os_bsd.cpp:601 >> #7 0x1936fef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90) >> #8 0x1936f9d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30) >> >> vmTestbase/nsk/jvmti/GetErrorName/geterrname002/TestDescription.java >> >> /priv/jenkins/client-home/workspace/openjdk-jdk-weekly-macos_aarch64-opt/build/support/modules_include/java.base/jvmti.h:2640:42: runtime error: load of value 4294967295, which is not a valid value for type 'jvmtiError' >> #0 0x1002b3504 in _jvmtiEnv::GetErrorName(jvmtiError, char**) jvmti.h:2640 >> #1 0x1002aec9c in agentProc(_jvmtiEnv*, JNIEnv_*, void*) geterrname002.cpp:50 >> #2 0x1002af198 in agentThreadWrapper(_jvmtiEnv*, JNIEnv_*, void*) agent_tools.cpp:151 >> #3 0x104f4895c in JvmtiAgentThread::call_start_function() jvmtiImpl.cpp:89 >> #4 0x104cbd7f0 in JavaThread::thread_main_inner() javaThread.cpp:776 >> #5 0x1054f6094 in Thread::call_run() thread.cpp:231 >> #6 0x10521c37c in thread_native_entry(Thread*) os_bsd.cpp:601 >> #7 0x1936fef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90) >> #8 0x1936f9d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30) >> >> >> So the problem reported is SetVerboseFlag method (which is part of the VM) calls SetVerboseFlag function with that bad argument ; but the test code seems to intentionally use 'bad' arguments . But this does not work well with ubsan ; so better exclude those tests from ubsan checking . >> Please note that jvmti.h is shipped so adding... > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Add comments test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetErrorName/geterrname002/TestDescription.java line 40: > 38: * @requires !vm.ubsan > 39: * @comment We test with arguments out of scope of the jvmti enums, this causes > 40: * ubsan issues. Suggestion: * @comment We test with arguments out of scope of the jvmti enums, which causes * ubsan issues. test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetVerboseFlag/setvrbflag002/TestDescription.java line 39: > 37: * @requires !vm.ubsan > 38: * @comment We test with arguments out of scope of the jvmti enums, this causes > 39: * ubsan issues. Suggestion: * @comment We test with arguments out of scope of the jvmti enums, which causes * ubsan issues. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26159#discussion_r2193521845 PR Review Comment: https://git.openjdk.org/jdk/pull/26159#discussion_r2193522041 From cjplummer at openjdk.org Tue Jul 8 22:29:39 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 8 Jul 2025 22:29:39 GMT Subject: RFR: 8358679: [asan] vmTestbase/nsk/jvmti tests show memory issues [v3] In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 19:41:26 GMT, Alex Menkov wrote: >> The fix updates several tests ASAN complains about. >> Tests for RawMonitors intentionally passes bad pointer to tested function, they should not be run with ASAN. >> Test vmTestbase/nsk/jvmti/scenarios/events/EM07/em07t002 verifies COMPILED_METHOD_LOAD/COMPILED_METHOD_UNLOAD event and uses RawMonitor for synchronization. It destroys the monitor, but some events may arrive later (before VM exits). Usually JVMTI tests do not destroy synchronization monitors, removed destruction here. > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > feedback Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26176#pullrequestreview-2999240093 From sspitsyn at openjdk.org Wed Jul 9 04:15:20 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 9 Jul 2025 04:15:20 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v4] In-Reply-To: References: Message-ID: > It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent. > This impacts the following JVMTI functions: > - `PopFrame` > - `NotifyFramePop` > - `ForceEarlyReturn` > > A related CSR is going to be filed for this spec update. > > Testing: > - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: (1) remove vthread specific clarifications; unify GetLocal* and SetLocal* with other functions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26111/files - new: https://git.openjdk.org/jdk/pull/26111/files/0c6ef896..da3f20a8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26111&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26111&range=02-03 Stats: 68 lines in 1 file changed: 5 ins; 48 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/26111.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26111/head:pull/26111 PR: https://git.openjdk.org/jdk/pull/26111 From sspitsyn at openjdk.org Wed Jul 9 04:15:21 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 9 Jul 2025 04:15:21 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v4] In-Reply-To: References: Message-ID: On Thu, 3 Jul 2025 18:41:21 GMT, Chris Plummer wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: (1) remove vthread specific clarifications; unify GetLocal* and SetLocal* with other functions > > src/hotspot/share/prims/jvmti.xml line 2991: > >> 2989: >> 2990: The implementation is unable to pop this frame >> 2991: (e.g. called or calling method is a native method). > > Directly below we have special OPAQUE_FRAME language for virtual threads. Do we want to get rid of it since it is now covered by the above language? Note there is also language directly above that discusses suspended virtual threads. Thank you for the suggestion. Fixed now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2193968014 From sspitsyn at openjdk.org Wed Jul 9 04:15:21 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 9 Jul 2025 04:15:21 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v4] In-Reply-To: <47TQcDecd7pUiEMcGleu8uAehEl40U22pjqdw2Qs4TQ=.8329e512-531f-4903-94cf-1fc7814c7559@github.com> References: <47TQcDecd7pUiEMcGleu8uAehEl40U22pjqdw2Qs4TQ=.8329e512-531f-4903-94cf-1fc7814c7559@github.com> Message-ID: On Mon, 7 Jul 2025 21:10:26 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/prims/jvmti.xml line 3194: >> >>> 3192: (e.g. current frame is executing a native method). >>> 3193: >>> 3194: >> >> Do we still need this section? Same question for repeated sections below. > > Thank you for suggestion. Let's think on this a little bit. Thank you for the suggestion. Fixed now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2193968224 From sspitsyn at openjdk.org Wed Jul 9 04:18:44 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 9 Jul 2025 04:18:44 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v3] In-Reply-To: <8QJ2M_GNYwi50gKBHG47B_13KQ-vHU11VrOleSlrMss=.c081db9f-eda6-41f8-b927-c4d1661ddbbf@github.com> References: <8QJ2M_GNYwi50gKBHG47B_13KQ-vHU11VrOleSlrMss=.c081db9f-eda6-41f8-b927-c4d1661ddbbf@github.com> Message-ID: <8BMr_79RV7fedcZUNfyhxCbrWKCE8vyuBiskFOXs-hI=.9893949e-9c5a-4fe9-be19-6cca51ac0ac2@github.com> On Mon, 7 Jul 2025 18:13:19 GMT, Serguei Spitsyn wrote: >> It was decided in a local discussion with Chris and Alan to update the JVMTI spec to make descriptions/clarifications of some `JVMTI_ERROR_OPAQUE_FRAME` cases more consistent. >> This impacts the following JVMTI functions: >> - `PopFrame` >> - `NotifyFramePop` >> - `ForceEarlyReturn` >> >> A related CSR is going to be filed for this spec update. >> >> Testing: >> - it is N/A in general but mach5 tiers 1-3 will be run to be completely safe > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: tweak the OPAQUE_FRAME clarifications for ForceEarlyReturn* functions I've decided to also unify the `OPAQUE_FRAME` clarifications of the `GetLocal/SetLocal` functions with the other `OPAQUE_FRAME` cases. It is fixed now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26111#issuecomment-3051050715 From sspitsyn at openjdk.org Wed Jul 9 04:18:45 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 9 Jul 2025 04:18:45 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v3] In-Reply-To: <7bSfuttUn1EO5IsDt1cxstnbccUm0IXWMwLRt92qiWM=.b70585d6-2928-4ad8-a5e8-8ea3fbd2b532@github.com> References: <8QJ2M_GNYwi50gKBHG47B_13KQ-vHU11VrOleSlrMss=.c081db9f-eda6-41f8-b927-c4d1661ddbbf@github.com> <7bSfuttUn1EO5IsDt1cxstnbccUm0IXWMwLRt92qiWM=.b70585d6-2928-4ad8-a5e8-8ea3fbd2b532@github.com> Message-ID: On Mon, 7 Jul 2025 21:06:22 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/prims/jvmti.xml line 3082: >> >>> 3080: >>> 3081: The implementation is unable to set a event for the frame >>> 3082: (e.g. the frame at depth is executing a native method). >> >> I don't think this sounds right. You don't "set" a FramePop event. You tell JVMTI to generate a FramePop event when this frame is popped. Maybe something like "A FramePop event cannot be generated for this frame". > > Thank you for the comment. > The `NotifyFramePop` is similar to `SetBreakpoint`. I'd even prefer it to be named accordingly: `SetFramePop` instead of `NotifyFramePop`. Unfortunately, we can't easily rename API's by compatibility reasons. We enable any kinds of events with `SetEventNotoficationMode` but these are two cases where we need to be precise in setting the events. The `SetBreakpoint` is to set a breakpoint notification at a specific method's bytecode. The `NotifyFramePop` is to set `FramePop` notification for a specific frame. So, I' prefer to keep the terminology similar for `Breakpoints` and `FramePop` events. Chris, please, let me know if it is okay to keep this at is or you still want an update for the `NotifyFramePop`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2193975815 From mbaesken at openjdk.org Wed Jul 9 07:05:28 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 9 Jul 2025 07:05:28 GMT Subject: RFR: 8351487: [ubsan] jvmti.h runtime error: load of value which is not a valid value [v3] In-Reply-To: <1-9RRDL18MUUtoGa3krcB6A_An6SATisnVldYbELMFo=.86eef7ef-c4a1-4e20-97fa-1aa7d8383e57@github.com> References: <1-9RRDL18MUUtoGa3krcB6A_An6SATisnVldYbELMFo=.86eef7ef-c4a1-4e20-97fa-1aa7d8383e57@github.com> Message-ID: > When running with ubsan - enabled binaries, the following 2 issues are observed in jvmti.h (on macOS aarch64). > > > jtreg test vmTestbase/nsk/jvmti/SetVerboseFlag/setvrbflag002/TestDescription.java > > /priv/jenkins/client-home/workspace/openjdk-jdk-weekly-macos_aarch64-opt/build/support/modules_include/java.base/jvmti.h:2645:44: runtime error: load of value 4294967295, which is not a valid value for type 'jvmtiVerboseFlag' > #0 0x104453540 in _jvmtiEnv::SetVerboseFlag(jvmtiVerboseFlag, unsigned char) jvmti.h:2645 > #1 0x10444ed5c in agentProc(_jvmtiEnv*, JNIEnv_*, void*) setvrbflag002.cpp:49 > #2 0x10444f1c8 in agentThreadWrapper(_jvmtiEnv*, JNIEnv_*, void*) agent_tools.cpp:151 > #3 0x10914895c in JvmtiAgentThread::call_start_function() jvmtiImpl.cpp:89 > #4 0x108ebd7f0 in JavaThread::thread_main_inner() javaThread.cpp:776 > #5 0x1096f6094 in Thread::call_run() thread.cpp:231 > #6 0x10941c37c in thread_native_entry(Thread*) os_bsd.cpp:601 > #7 0x1936fef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90) > #8 0x1936f9d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30) > > vmTestbase/nsk/jvmti/GetErrorName/geterrname002/TestDescription.java > > /priv/jenkins/client-home/workspace/openjdk-jdk-weekly-macos_aarch64-opt/build/support/modules_include/java.base/jvmti.h:2640:42: runtime error: load of value 4294967295, which is not a valid value for type 'jvmtiError' > #0 0x1002b3504 in _jvmtiEnv::GetErrorName(jvmtiError, char**) jvmti.h:2640 > #1 0x1002aec9c in agentProc(_jvmtiEnv*, JNIEnv_*, void*) geterrname002.cpp:50 > #2 0x1002af198 in agentThreadWrapper(_jvmtiEnv*, JNIEnv_*, void*) agent_tools.cpp:151 > #3 0x104f4895c in JvmtiAgentThread::call_start_function() jvmtiImpl.cpp:89 > #4 0x104cbd7f0 in JavaThread::thread_main_inner() javaThread.cpp:776 > #5 0x1054f6094 in Thread::call_run() thread.cpp:231 > #6 0x10521c37c in thread_native_entry(Thread*) os_bsd.cpp:601 > #7 0x1936fef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90) > #8 0x1936f9d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30) > > > So the problem reported is SetVerboseFlag method (which is part of the VM) calls SetVerboseFlag function with that bad argument ; but the test code seems to intentionally use 'bad' arguments . But this does not work well with ubsan ; so better exclude those tests from ubsan checking . > Please note that jvmti.h is shipped so adding some macros/attributes to methods for avoiding ubsan is probab... Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust and move comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26159/files - new: https://git.openjdk.org/jdk/pull/26159/files/a0ca0ddc..33b057c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26159&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26159&range=01-02 Stats: 6 lines in 2 files changed: 2 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26159.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26159/head:pull/26159 PR: https://git.openjdk.org/jdk/pull/26159 From rrich at openjdk.org Wed Jul 9 07:50:49 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Wed, 9 Jul 2025 07:50:49 GMT Subject: [jdk25] RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails because of unstable inlining Message-ID: <9YA3ygtNCyiCxlzm8SXJm7PaXEcR5M9Q7SGg13A89OY=.bf703d2a-d412-48fb-b111-50b9d474e6ce@github.com> This pull request contains a backport of commit [fea73c1d](https://github.com/openjdk/jdk/commit/fea73c1d40441561a246f2a09a739367cfc197ea) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Richard Reingruber on 7 Jul 2025 and was reviewed by Alan Bateman, Martin Doerr and Leonid Mesnik. Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. Thanks, Richard. ------------- Commit messages: - Backport fea73c1d40441561a246f2a09a739367cfc197ea Changes: https://git.openjdk.org/jdk/pull/26180/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26180&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360599 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/26180.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26180/head:pull/26180 PR: https://git.openjdk.org/jdk/pull/26180 From mdoerr at openjdk.org Wed Jul 9 07:50:50 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 9 Jul 2025 07:50:50 GMT Subject: [jdk25] RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails because of unstable inlining In-Reply-To: <9YA3ygtNCyiCxlzm8SXJm7PaXEcR5M9Q7SGg13A89OY=.bf703d2a-d412-48fb-b111-50b9d474e6ce@github.com> References: <9YA3ygtNCyiCxlzm8SXJm7PaXEcR5M9Q7SGg13A89OY=.bf703d2a-d412-48fb-b111-50b9d474e6ce@github.com> Message-ID: On Tue, 8 Jul 2025 07:09:28 GMT, Richard Reingruber wrote: > This pull request contains a backport of commit [fea73c1d](https://github.com/openjdk/jdk/commit/fea73c1d40441561a246f2a09a739367cfc197ea) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Richard Reingruber on 7 Jul 2025 and was reviewed by Alan Bateman, Martin Doerr and Leonid Mesnik. > > Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. > > Thanks, Richard. This testfix backport makes sense. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26180#pullrequestreview-2996597109 From dbriemann at openjdk.org Wed Jul 9 07:59:38 2025 From: dbriemann at openjdk.org (David Briemann) Date: Wed, 9 Jul 2025 07:59:38 GMT Subject: RFR: 8361599: [PPC64] enable missing tests via jtreg requires [v2] In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 14:17:21 GMT, David Briemann wrote: >> Some tests are not executed on PPC little or big endian because the current requires annotation only checks for "ppc64" or "ppc64le" but not both. > > David Briemann has updated the pull request incrementally with one additional commit since the last revision: > > adapt copyrights Thanks for testing that! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26184#issuecomment-3051576708 From duke at openjdk.org Wed Jul 9 07:59:38 2025 From: duke at openjdk.org (duke) Date: Wed, 9 Jul 2025 07:59:38 GMT Subject: RFR: 8361599: [PPC64] enable missing tests via jtreg requires [v2] In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 14:17:21 GMT, David Briemann wrote: >> Some tests are not executed on PPC little or big endian because the current requires annotation only checks for "ppc64" or "ppc64le" but not both. > > David Briemann has updated the pull request incrementally with one additional commit since the last revision: > > adapt copyrights @dbriemann Your change (at version f79e289564b527bad4e261e1db72d62b1a06e4c4) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26184#issuecomment-3051578710 From ayang at openjdk.org Wed Jul 9 08:06:23 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 9 Jul 2025 08:06:23 GMT Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v21] In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com> References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com> Message-ID: > This patch refines Parallel's sizing strategy to improve overall memory management and performance. > > The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`. > > `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`. > > GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`. > > ## Performance evaluation > > - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)). > - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html). > - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing. > > PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging. > > Test: tier1-8 Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits: - Merge branch 'master' into pgc-size-policy - review - review - Merge branch 'master' into pgc-size-policy - review - review - Merge branch 'master' into pgc-size-policy - Merge branch 'master' into pgc-size-policy - review - cast - ... and 22 more: https://git.openjdk.org/jdk/compare/117f0b40...0d5de9a2 ------------- Changes: https://git.openjdk.org/jdk/pull/25000/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=20 Stats: 4362 lines in 31 files changed: 507 ins; 3470 del; 385 mod Patch: https://git.openjdk.org/jdk/pull/25000.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000 PR: https://git.openjdk.org/jdk/pull/25000 From ayang at openjdk.org Wed Jul 9 08:06:23 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 9 Jul 2025 08:06:23 GMT Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v13] In-Reply-To: References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com> <76NgHH-m26Nw2paJmIQvNNqio_iKtdQ_bJ2aejMfKEI=.82ff25aa-f5c5-4146-84b5-1aaaefb5efd1@github.com> <85HD8TnSUAI0GIc_xeF7SPzT52Mv3fAO2mUlm73M4_g=.d6300d71-32c6-4cc9-af9d-97d8a66f6264@github.com> Message-ID: <-tg-l6DOtno0KEnAIgMPSuWLoHZLtJnTdj4BRLUnGpo=.be889c98-761f-416c-bd74-e2d3986db1b7@github.com> On Mon, 7 Jul 2025 00:39:59 GMT, Zhengyu Gu wrote: >> I don't see how I changed the semantics. >> >> On baseline, from `mem_allocate_work`: >> >> >> if (result != nullptr) { >> return result; >> } >> >> // If certain conditions hold, try allocating from the old gen. >> if (!is_tlab) { >> result = mem_allocate_old_gen(size); >> if (result != nullptr) { >> return result; >> } >> } >> >> >> and >> >> >> HeapWord* ParallelScavengeHeap::mem_allocate_old_gen(size_t size) { >> if (!should_alloc_in_eden(size)) { >> // Size is too big for eden. >> return allocate_old_gen_and_record(size); >> } >> >> return nullptr; >> } >> >> >> The original logic is essentially: >> >> >> if (result == nullptr && !is_tlab && !should_alloc_in_eden(size)) { >> // allocate in old-gen >> } >> >> which is the same as I put here. > > Ah, okay. I took another look at this and realized that there are to paths to do retry-allocation-in-old-gen-after-young-gen-failure. 1. In `mem_allocate_work`. HeapWord* result = young_gen()->allocate(size); if (result != nullptr) { return result; } // If certain conditions hold, try allocating from the old gen. if (!is_tlab && !should_alloc_in_eden(size)) { result = old_gen()->cas_allocate_noexpand(size); This retry-allocation-in-old-gen is *pre-gc* -- the `should_alloc_in_eden` filter is there to ensure that a (young) gc should kick-in, instead of populating old-gen with many small objs. 2. In `satisfy_failed_allocation` -> `expand_heap_and_allocate`. HeapWord* result = young_gen()->expand_and_allocate(size); if (result == nullptr && !is_tlab) { result = old_gen()->expand_and_allocate(size); } This retry-allocation-in-old-gen is *post-gc* -- we should not artificially introduce old-gen-allocation-failure, because that would mean the previous (young/full) gc was useless to this allocation-request. Therefore, I believe the logic on master is more reasonable. Also, for back compatibility reasons, I have reverted this part and added a comment there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2194344731 From kevinw at openjdk.org Wed Jul 9 08:15:38 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 9 Jul 2025 08:15:38 GMT Subject: [jdk25] RFR: 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails because of unstable inlining In-Reply-To: <9YA3ygtNCyiCxlzm8SXJm7PaXEcR5M9Q7SGg13A89OY=.bf703d2a-d412-48fb-b111-50b9d474e6ce@github.com> References: <9YA3ygtNCyiCxlzm8SXJm7PaXEcR5M9Q7SGg13A89OY=.bf703d2a-d412-48fb-b111-50b9d474e6ce@github.com> Message-ID: On Tue, 8 Jul 2025 07:09:28 GMT, Richard Reingruber wrote: > This pull request contains a backport of commit [fea73c1d](https://github.com/openjdk/jdk/commit/fea73c1d40441561a246f2a09a739367cfc197ea) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Richard Reingruber on 7 Jul 2025 and was reviewed by Alan Bateman, Martin Doerr and Leonid Mesnik. > > Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. > > Thanks, Richard. Marked as reviewed by kevinw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26180#pullrequestreview-3000513381 From dbriemann at openjdk.org Wed Jul 9 08:30:48 2025 From: dbriemann at openjdk.org (David Briemann) Date: Wed, 9 Jul 2025 08:30:48 GMT Subject: Integrated: 8361599: [PPC64] enable missing tests via jtreg requires In-Reply-To: References: Message-ID: On Tue, 8 Jul 2025 13:19:35 GMT, David Briemann wrote: > Some tests are not executed on PPC little or big endian because the current requires annotation only checks for "ppc64" or "ppc64le" but not both. This pull request has now been integrated. Changeset: 83feb7a2 Author: David Briemann Committer: Martin Doerr URL: https://git.openjdk.org/jdk/commit/83feb7a2388e33835b2071cfe0e51ba8b43e241f Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod 8361599: [PPC64] enable missing tests via jtreg requires Reviewed-by: mdoerr ------------- PR: https://git.openjdk.org/jdk/pull/26184 From ayang at openjdk.org Wed Jul 9 08:33:15 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 9 Jul 2025 08:33:15 GMT Subject: RFR: 8361680: Use correct enum Claim value in VM_HeapWalkOperation::collect_simple_roots Message-ID: Trivial changing boolean to the correct integer to avoid implicit bool-to-int conversion. ------------- Commit messages: - trivial Changes: https://git.openjdk.org/jdk/pull/26214/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26214&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361680 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26214.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26214/head:pull/26214 PR: https://git.openjdk.org/jdk/pull/26214 From shade at openjdk.org Wed Jul 9 08:36:37 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 9 Jul 2025 08:36:37 GMT Subject: RFR: 8361680: Use correct enum Claim value in VM_HeapWalkOperation::collect_simple_roots In-Reply-To: References: Message-ID: <1P2g9O_at3m1WbHsuLBZjpmDfq7SbDT0BBChzcs3FhQ=.2eb89b13-43fe-4481-8c6d-82a7a03318a2@github.com> On Wed, 9 Jul 2025 08:28:23 GMT, Albert Mingkun Yang wrote: > Trivial changing boolean to the correct integer to avoid implicit bool-to-int conversion. Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26214#pullrequestreview-3000579279 From ayang at openjdk.org Wed Jul 9 12:03:46 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 9 Jul 2025 12:03:46 GMT Subject: RFR: 8361680: Use correct enum Claim value in VM_HeapWalkOperation::collect_simple_roots In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 08:28:23 GMT, Albert Mingkun Yang wrote: > Trivial changing boolean to the correct integer to avoid implicit bool-to-int conversion. Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26214#issuecomment-3052380514 From ayang at openjdk.org Wed Jul 9 12:03:46 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 9 Jul 2025 12:03:46 GMT Subject: Integrated: 8361680: Use correct enum Claim value in VM_HeapWalkOperation::collect_simple_roots In-Reply-To: References: Message-ID: <5bbkdgPu8pO3BXhdf31cSrlI-r1FIkFM3OopyfdFaWQ=.02657dc5-d815-4b2b-9d64-686aff73a364@github.com> On Wed, 9 Jul 2025 08:28:23 GMT, Albert Mingkun Yang wrote: > Trivial changing boolean to the correct integer to avoid implicit bool-to-int conversion. This pull request has now been integrated. Changeset: eec04dd0 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/eec04dd01051064bacf5110539755aa41106b1a6 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8361680: Use correct enum Claim value in VM_HeapWalkOperation::collect_simple_roots Reviewed-by: shade ------------- PR: https://git.openjdk.org/jdk/pull/26214 From kevinw at openjdk.org Wed Jul 9 13:00:48 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 9 Jul 2025 13:00:48 GMT Subject: RFR: 8359809: AttributeList, RoleList and UnresolvedRoleList should never accept other types of Object [v5] In-Reply-To: References: Message-ID: On Tue, 1 Jul 2025 08:52:56 GMT, Kevin Walls wrote: >> The classes javax.management.AttributeList, and javax.management.relation.RoleList and UnresolvedRoleList, have a historical feature where they accept objects of the wrong type, and only check for wrong objects when the "asList()" method is called. >> >> This feature should be removed, and these classes should never accept the wrong kind of Object. > > Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: > > - Further doc update > - Test udpate (listIterator) CSR is approved, will need to get re-review or additional review 8-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/25856#issuecomment-3052582311