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 From cjplummer at openjdk.org Wed Jul 9 17:53:38 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 9 Jul 2025 17:53:38 GMT Subject: RFR: 8351487: [ubsan] jvmti.h runtime error: load of value which is not a valid value [v3] In-Reply-To: References: <1-9RRDL18MUUtoGa3krcB6A_An6SATisnVldYbELMFo=.86eef7ef-c4a1-4e20-97fa-1aa7d8383e57@github.com> Message-ID: On Wed, 9 Jul 2025 07:05:28 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: > > Adjust and move comments Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26159#pullrequestreview-3002565085 From amenkov at openjdk.org Wed Jul 9 18:57:39 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 9 Jul 2025 18:57:39 GMT Subject: RFR: 8351487: [ubsan] jvmti.h runtime error: load of value which is not a valid value [v3] In-Reply-To: References: <1-9RRDL18MUUtoGa3krcB6A_An6SATisnVldYbELMFo=.86eef7ef-c4a1-4e20-97fa-1aa7d8383e57@github.com> Message-ID: On Wed, 9 Jul 2025 07:05:28 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: > > Adjust and move comments Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26159#pullrequestreview-3002731320 From sspitsyn at openjdk.org Wed Jul 9 21:51:39 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 9 Jul 2025 21:51:39 GMT Subject: RFR: 8358679: [asan] vmTestbase/nsk/jvmti tests show memory issues [v3] In-Reply-To: References: Message-ID: <7s84jYQb5OYoMQVXDKPcNP8tP_0DnzrHSX41UwZlimQ=.863ac62d-96ab-4ee7-a32c-e2746b7f75f7@github.com> 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 Looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26176#pullrequestreview-3003213936 From sspitsyn at openjdk.org Wed Jul 9 23:18:39 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 9 Jul 2025 23:18:39 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) Changes requested by sspitsyn (Reviewer). test/jdk/javax/management/generified/ListTypeCheckTest.java line 105: > 103: ListIterator iter2 = al.listIterator(); > 104: Object x2 = iter2.next(); > 105: iter2.add("blah"); Nit: The case #6 is exactly the same as #5. Q: Why is it needed? I'd suggest to add a comment explaining this case. The line 105 should have a comment as at the line 99. In general, this test has a lack of comments explaining tests cases (was before your fix). test/jdk/javax/management/generified/ListTypeCheckTest.java line 110: > 108: throw new Exception("test wrong"); > 109: } > 110: throw new Exception("op " + i + " allowed but should fail on " + al.getClass()); Nit: This is confusing. If it is allowed then why should it fail. At least, it needs to be explained somewhere in the tests. ------------- PR Review: https://git.openjdk.org/jdk/pull/25856#pullrequestreview-3003366010 PR Review Comment: https://git.openjdk.org/jdk/pull/25856#discussion_r2196169023 PR Review Comment: https://git.openjdk.org/jdk/pull/25856#discussion_r2196171012 From sspitsyn at openjdk.org Wed Jul 9 23:22:39 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 9 Jul 2025 23:22:39 GMT Subject: RFR: 8351487: [ubsan] jvmti.h runtime error: load of value which is not a valid value [v3] In-Reply-To: References: <1-9RRDL18MUUtoGa3krcB6A_An6SATisnVldYbELMFo=.86eef7ef-c4a1-4e20-97fa-1aa7d8383e57@github.com> Message-ID: On Wed, 9 Jul 2025 07:05:28 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: > > Adjust and move comments Looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26159#pullrequestreview-3003374571 From sspitsyn at openjdk.org Wed Jul 9 23:29:39 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 9 Jul 2025 23:29:39 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. It is a clean backport. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26198#pullrequestreview-3003381861 From cjplummer at openjdk.org Thu Jul 10 00:17:43 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 10 Jul 2025 00:17:43 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> <7bSfuttUn1EO5IsDt1cxstnbccUm0IXWMwLRt92qiWM=.b70585d6-2928-4ad8-a5e8-8ea3fbd2b532@github.com> Message-ID: On Wed, 9 Jul 2025 04:16:22 GMT, Serguei Spitsyn wrote: >> 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`. I understand what you are saying about the comparison to SetBreakpoint and that SetFramePop would have been a better name, but I don't see what this with the description. I said "set a FramePop event" doesn't sound right. Neither would "set a Breakpoint event". Also, the analogy with breakpoints doesn't really work when you consider that "a breakpoint" is meaningful, but "a FrampPop" does not. A breakpoint is a location in the code where a breakpoint event will be triggered when executed. That analogy doesn't really work with FramePop. We don't have a word similar to breakpoint that means "a frame marked for generating a FramePop event when popped". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2196234910 From amenkov at openjdk.org Thu Jul 10 00:24:10 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 10 Jul 2025 00:24:10 GMT Subject: RFR: 8361314: Test serviceability/jvmti/VMEvent/MyPackage/VMEventRecursionTest.java FATAL ERROR in native method: Failed during the GetClassSignature call Message-ID: The fix adds guards against JVMTI_ERROR_WRONG_PHASE error in VMObjectAlloc event handler. Testing: fixed test on all platforms ------------- Commit messages: - fix Changes: https://git.openjdk.org/jdk/pull/26231/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26231&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361314 Stats: 41 lines in 1 file changed: 40 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26231.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26231/head:pull/26231 PR: https://git.openjdk.org/jdk/pull/26231 From sspitsyn at openjdk.org Thu Jul 10 01:17:33 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 10 Jul 2025 01:17:33 GMT Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired Message-ID: The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27. There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams: - Class redefinition/retransformation can impact lambda expressions which are supported with private methods - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now). Testing: - mach5 tiers 1-6 are good - may need to run mach5 tiers > 6 ------------- Commit messages: - 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired Changes: https://git.openjdk.org/jdk/pull/26232/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358890 Stats: 1851 lines in 36 files changed: 0 ins; 1825 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/26232.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26232/head:pull/26232 PR: https://git.openjdk.org/jdk/pull/26232 From sspitsyn at openjdk.org Thu Jul 10 03:12:27 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 10 Jul 2025 03:12:27 GMT Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired [v2] In-Reply-To: References: Message-ID: > The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27. > > TBD: Need to submit a related CSR. > > There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams: > - Class redefinition/retransformation can impact lambda expressions which are supported with private methods > - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now). > > Testing: > - mach5 tiers 1-6 are good > - may need to run mach5 tiers > 6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: corrected one assert message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26232/files - new: https://git.openjdk.org/jdk/pull/26232/files/a7bceacb..a8358402 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26232.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26232/head:pull/26232 PR: https://git.openjdk.org/jdk/pull/26232 From cjplummer at openjdk.org Thu Jul 10 03:29:37 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 10 Jul 2025 03:29:37 GMT Subject: RFR: 8361314: Test serviceability/jvmti/VMEvent/MyPackage/VMEventRecursionTest.java FATAL ERROR in native method: Failed during the GetClassSignature call In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 00:08:26 GMT, Alex Menkov wrote: > The fix adds guards against JVMTI_ERROR_WRONG_PHASE error in VMObjectAlloc event handler. > > Testing: fixed test on all platforms Your changes look fine, but I'm a bit confused as to how this test is testing for what it claims it is testing: `Verifies that a VM event callback does not recurse if a VM object is allocated during callback.` Where is it actually checking that it is not recursing? ------------- PR Review: https://git.openjdk.org/jdk/pull/26231#pullrequestreview-3003747988 From mbaesken at openjdk.org Thu Jul 10 07:11:44 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 10 Jul 2025 07:11:44 GMT Subject: RFR: 8351487: [ubsan] jvmti.h runtime error: load of value which is not a valid value [v3] In-Reply-To: References: <1-9RRDL18MUUtoGa3krcB6A_An6SATisnVldYbELMFo=.86eef7ef-c4a1-4e20-97fa-1aa7d8383e57@github.com> Message-ID: <8oMxeYD9TJJk3-axtF1zeMD1Hb_4RJuLnkd-BsV0bV0=.8e830fd3-b780-498c-bd46-1f7c0bd7efca@github.com> On Wed, 9 Jul 2025 07:05:28 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: > > Adjust and move comments Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26159#issuecomment-3055973421 From mbaesken at openjdk.org Thu Jul 10 07:11:44 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 10 Jul 2025 07:11:44 GMT Subject: Integrated: 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: 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 pull request has now been integrated. Changeset: bf3cfbef Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/bf3cfbeff414356aaf2b0933568ff648beace2c5 Stats: 8 lines in 2 files changed: 6 ins; 0 del; 2 mod 8351487: [ubsan] jvmti.h runtime error: load of value which is not a valid value Reviewed-by: cjplummer, amenkov, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/26159 From dholmes at openjdk.org Thu Jul 10 07:23:40 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 10 Jul 2025 07:23:40 GMT Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired [v2] In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 03:12:27 GMT, Serguei Spitsyn wrote: >> The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27. >> >> TBD: Need to submit a related CSR. >> >> There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams: >> - Class redefinition/retransformation can impact lambda expressions which are supported with private methods >> - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now). >> >> Testing: >> - mach5 tiers 1-6 are good >> - may need to run mach5 tiers > 6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > corrected one assert message This involved a lot more code than I had envisaged. The test situation seems problematic as it suggests to me that we have required functionality (redefine a method containing a lambda expression) that is not possible without the flag. And it seems this flag is also being used in the wild e.g. https://blog.picnic.nl/embracing-java-17-heres-what-we-learned-69779d95fdf2 > As of Java 16, JDK internals are strongly encapsulated by default ([JEP 396](https://openjdk.java.net/jeps/396)). These and other changes mean that some dependencies now [require](https://github.com/reactor/BlockHound/issues/33) additional JVM flags such as --add-opens and -XX:+AllowRedefinitionToAddDeleteMethods to function properly. We updated our shared build system such that teams can configure these flags in a single place, ensuring that test and production runtimes remain in sync. With more info in https://github.com/reactor/BlockHound/issues/33 So I am quite concerned that this "workaround" has become entrenched. src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4053: > 4051: } > 4052: > 4053: void VM_RedefineClasses::compute_matching_methods() { I can't see that this method actually still does anything useful. ?? src/hotspot/share/runtime/arguments.cpp line 525: > 523: // -------------- Deprecated Flags -------------- > 524: // --- Non-alias flags - sorted by obsolete_in then expired_in: > 525: { "AllowRedefinitionToAddDeleteMethods", JDK_Version::jdk(13), JDK_Version::jdk(26), JDK_Version::jdk(27) }, Please move this line to before line 535 (ParallelRefProcEnabled) so that we are sorted on obsolete_in as required. ------------- PR Review: https://git.openjdk.org/jdk/pull/26232#pullrequestreview-3004272187 PR Review Comment: https://git.openjdk.org/jdk/pull/26232#discussion_r2196808392 PR Review Comment: https://git.openjdk.org/jdk/pull/26232#discussion_r2196813023 From rrich at openjdk.org Thu Jul 10 07:30:12 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Thu, 10 Jul 2025 07:30:12 GMT Subject: RFR: 8361602: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java deadlocks on exception Message-ID: This pr moves the `notify()` call to the finally block to avoid the deadlock in `join()` if `verifyHeapDump(dumpFile)` throws an exception. Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. ------------- Commit messages: - Notify in finally block to avoid deadlock reaching there by exception Changes: https://git.openjdk.org/jdk/pull/26213/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26213&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361602 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26213.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26213/head:pull/26213 PR: https://git.openjdk.org/jdk/pull/26213 From rrich at openjdk.org Thu Jul 10 07:37:46 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Thu, 10 Jul 2025 07:37:46 GMT Subject: [jdk25] Integrated: 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 pull request has now been integrated. Changeset: 532b1c73 Author: Richard Reingruber URL: https://git.openjdk.org/jdk/commit/532b1c732edb2873afead4d12721a938cec8879f Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod 8360599: [TESTBUG] DumpThreadsWithEliminatedLock.java fails because of unstable inlining Reviewed-by: mdoerr, kevinw Backport-of: fea73c1d40441561a246f2a09a739367cfc197ea ------------- PR: https://git.openjdk.org/jdk/pull/26180 From kevinw at openjdk.org Thu Jul 10 07:58:00 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 10 Jul 2025 07:58:00 GMT Subject: RFR: 8359809: AttributeList, RoleList and UnresolvedRoleList should never accept other types of Object [v5] In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 23:14:19 GMT, Serguei Spitsyn wrote: >> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: >> >> - Further doc update >> - Test udpate (listIterator) > > test/jdk/javax/management/generified/ListTypeCheckTest.java line 105: > >> 103: ListIterator iter2 = al.listIterator(); >> 104: Object x2 = iter2.next(); >> 105: iter2.add("blah"); > > Nit: The case #6 is exactly the same as #5. > Q: Why is it needed? > I'd suggest to add a comment explaining this case. > The line 105 should have a comment as at the line 99. > In general, this test has a lack of comments explaining tests cases (was before your fix). These cases test the ListIterator operations, one case for set, one case for add. Will update with comment to clarify. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25856#discussion_r2196896204 From kevinw at openjdk.org Thu Jul 10 07:58:00 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 10 Jul 2025 07:58:00 GMT Subject: RFR: 8359809: AttributeList, RoleList and UnresolvedRoleList should never accept other types of Object [v6] 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: - Test comment update - Test comment update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25856/files - new: https://git.openjdk.org/jdk/pull/25856/files/a2a28dde..7d3728d4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25856&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25856&range=04-05 Stats: 6 lines in 1 file changed: 3 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 mbaesken at openjdk.org Thu Jul 10 08:02:38 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 10 Jul 2025 08:02:38 GMT Subject: RFR: 8361602: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java deadlocks on exception In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 07:39:05 GMT, Richard Reingruber wrote: > This pr moves the `notify()` call to the finally block to avoid the deadlock in `join()` if `verifyHeapDump(dumpFile)` throws an exception. > > Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. Seems you need to adjust the COPYRIGHT too, but otherwise looks good. ------------- PR Review: https://git.openjdk.org/jdk/pull/26213#pullrequestreview-3004428723 From clanger at openjdk.org Thu Jul 10 08:02:39 2025 From: clanger at openjdk.org (Christoph Langer) Date: Thu, 10 Jul 2025 08:02:39 GMT Subject: RFR: 8361602: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java deadlocks on exception In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 07:39:05 GMT, Richard Reingruber wrote: > This pr moves the `notify()` call to the finally block to avoid the deadlock in `join()` if `verifyHeapDump(dumpFile)` throws an exception. > > Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. Looks good, modulo copyright year. ? ------------- Marked as reviewed by clanger (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26213#pullrequestreview-3004433562 From sspitsyn at openjdk.org Thu Jul 10 08:05:54 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 10 Jul 2025 08:05:54 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v5] 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 spec sections: > - `PopFrame` > - `NotifyFramePop` > - `ForceEarlyReturn` > - `GetLocal` > - `SetLocal` > - general description of the `JVMTI_ERROR_OPAQUE_FRAME` error code > > 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: corrected 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/da3f20a8..4f1d4170 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26111&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26111&range=03-04 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 Thu Jul 10 08:10:40 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 10 Jul 2025 08:10: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: References: <8QJ2M_GNYwi50gKBHG47B_13KQ-vHU11VrOleSlrMss=.c081db9f-eda6-41f8-b927-c4d1661ddbbf@github.com> <7bSfuttUn1EO5IsDt1cxstnbccUm0IXWMwLRt92qiWM=.b70585d6-2928-4ad8-a5e8-8ea3fbd2b532@github.com> Message-ID: On Thu, 10 Jul 2025 00:15:21 GMT, Chris Plummer wrote: >> Chris, please, let me know if it is okay to keep this at is or you still want an update for the `NotifyFramePop`. > > I understand what you are saying about the comparison to SetBreakpoint and that SetFramePop would have been a better name, but I don't see what this with the description. I said "set a FramePop event" doesn't sound right. Neither would "set a Breakpoint event". Also, the analogy with breakpoints doesn't really work when you consider that "a breakpoint" is meaningful, but "a FrampPop" does not. > > A breakpoint is a location in the code where a breakpoint event will be triggered when executed. That analogy doesn't really work with FramePop. We don't have a word similar to breakpoint that means "a frame marked for generating a FramePop event when popped". Okay, thanks. I've updated the `NotifyFramePop` spec as you suggested: ```A FramePop event cannot be generated for this frame``` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2196933575 From kevinw at openjdk.org Thu Jul 10 08:11:41 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 10 Jul 2025 08:11:41 GMT Subject: RFR: 8359809: AttributeList, RoleList and UnresolvedRoleList should never accept other types of Object [v5] In-Reply-To: References: Message-ID: <4G_NS84Uyd7KNaKjIH_DgC-C7H2Ep_hOAFNH0ZA9OV0=.11ab8dca-6f6f-4d5f-ad2b-da610f8be329@github.com> On Wed, 9 Jul 2025 23:16:12 GMT, Serguei Spitsyn wrote: >> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: >> >> - Further doc update >> - Test udpate (listIterator) > > test/jdk/javax/management/generified/ListTypeCheckTest.java line 110: > >> 108: throw new Exception("test wrong"); >> 109: } >> 110: throw new Exception("op " + i + " allowed but should fail on " + al.getClass()); > > Nit: This is confusing. If it is allowed then why should it fail. > At least, it needs to be explained somewhere in the tests. Thanks Serguei, I hope I've addressed both comments with additional comment updates. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25856#discussion_r2196935071 From rrich at openjdk.org Thu Jul 10 08:12:54 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Thu, 10 Jul 2025 08:12:54 GMT Subject: RFR: 8361602: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java deadlocks on exception [v2] In-Reply-To: References: Message-ID: > This pr moves the `notify()` call to the finally block to avoid the deadlock in `join()` if `verifyHeapDump(dumpFile)` throws an exception. > > Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26213/files - new: https://git.openjdk.org/jdk/pull/26213/files/e802fe62..a4943345 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26213&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26213&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26213.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26213/head:pull/26213 PR: https://git.openjdk.org/jdk/pull/26213 From dholmes at openjdk.org Thu Jul 10 08:18:42 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 10 Jul 2025 08:18:42 GMT Subject: RFR: 8361602: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java deadlocks on exception [v2] In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 08:12:54 GMT, Richard Reingruber wrote: >> This pr moves the `notify()` call to the finally block to avoid the deadlock in `join()` if `verifyHeapDump(dumpFile)` throws an exception. >> >> Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Copyright That fixes the observed problem, but I find the existing test logic somewhat awkward. You only need a finally block to ensure something happens if an exception occurred - but here if you get an exception why do we care about joining the vthread? We don't know what the exception was or what it implies about the state of the vthread. Also using wait/notify without a loop on the wait and checking a state variable is not the correct usage pattern and would be affected by spurious wakeups. ------------- PR Review: https://git.openjdk.org/jdk/pull/26213#pullrequestreview-3004487073 From kevinw at openjdk.org Thu Jul 10 08:21:47 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 10 Jul 2025 08:21:47 GMT Subject: Integrated: 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 This pull request has now been integrated. Changeset: 13e0f996 Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/13e0f99626ed58958bf0b581be95934f0b218979 Stats: 649 lines in 6 files changed: 0 ins; 644 del; 5 mod 8351413: Remove XML interchange in java.management/javax/management/modelmbean/DescriptorSupport Reviewed-by: dfuchs, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/25697 From sspitsyn at openjdk.org Thu Jul 10 08:24:56 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 10 Jul 2025 08:24:56 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v6] 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 spec sections: > - `PopFrame` > - `NotifyFramePop` > - `ForceEarlyReturn` > - `GetLocal` > - `SetLocal` > - general description of the `JVMTI_ERROR_OPAQUE_FRAME` error code > > 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: minor tweak of previous change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26111/files - new: https://git.openjdk.org/jdk/pull/26111/files/4f1d4170..170fe280 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26111&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26111&range=04-05 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 rrich at openjdk.org Thu Jul 10 10:02:56 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Thu, 10 Jul 2025 10:02:56 GMT Subject: RFR: 8361602: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java deadlocks on exception [v3] In-Reply-To: References: Message-ID: > This pr moves the `notify()` call to the finally block to avoid the deadlock in `join()` if `verifyHeapDump(dumpFile)` throws an exception. > > Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Wait while !done ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26213/files - new: https://git.openjdk.org/jdk/pull/26213/files/a4943345..13cb9ba3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26213&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26213&range=01-02 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26213.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26213/head:pull/26213 PR: https://git.openjdk.org/jdk/pull/26213 From rrich at openjdk.org Thu Jul 10 10:02:56 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Thu, 10 Jul 2025 10:02:56 GMT Subject: RFR: 8361602: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java deadlocks on exception [v2] In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 08:16:10 GMT, David Holmes wrote: > That fixes the observed problem, but I find the existing test logic somewhat awkward. You only need a finally block to ensure something happens if an exception occurred - but here if you get an exception why do we care about joining the vthread? We don't know what the exception was or what it implies about the state of the vthread. The test should notify(). Without the virtual thread will not terminate and stay there until the vm exits. This would influence (new) test cases as heap dumps would accumulate virtual threads from previous tests. Btw this is another reason to call System.gc() before every test for fixing https://bugs.openjdk.org/browse/JDK-8361827 join() is helpful to find issues like the observed problem and to make sure the virtual thread's gone. > > Also using wait/notify without a loop on the wait and checking a state variable is not the correct usage pattern and would be affected by spurious wakeups. I've added the loop. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26213#issuecomment-3056690466 From syan at openjdk.org Thu Jul 10 14:13:15 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 10 Jul 2025 14:13:15 GMT Subject: RFR: 8361869: Tests which call ThreadController should mark as /native Message-ID: <8AjbR0Au_UZcjgwtlBeWJJfP2oeFtpwAR4wTrxdSdoQ=.e69993ed-8682-49c3-8afa-bd0087eb827b@github.com> Hi all, Several tests which call `ThreadController` native libary missing `/native` jtreg directive. This PR add `/native` directive will make test more friendly. The analysis process of how to find which tests missing show as [JDK-8361869](https://bugs.openjdk.org/browse/JDK-8361869) Test-fix only, change has been verified locally, no risk. ------------- Commit messages: - 8361869: Tests which call ThreadController should mark as /native Changes: https://git.openjdk.org/jdk/pull/26244/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26244&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361869 Stats: 18 lines in 9 files changed: 0 ins; 0 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/26244.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26244/head:pull/26244 PR: https://git.openjdk.org/jdk/pull/26244 From sspitsyn at openjdk.org Thu Jul 10 15:08:44 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 10 Jul 2025 15:08:44 GMT Subject: RFR: 8359809: AttributeList, RoleList and UnresolvedRoleList should never accept other types of Object [v5] In-Reply-To: <4G_NS84Uyd7KNaKjIH_DgC-C7H2Ep_hOAFNH0ZA9OV0=.11ab8dca-6f6f-4d5f-ad2b-da610f8be329@github.com> References: <4G_NS84Uyd7KNaKjIH_DgC-C7H2Ep_hOAFNH0ZA9OV0=.11ab8dca-6f6f-4d5f-ad2b-da610f8be329@github.com> Message-ID: On Thu, 10 Jul 2025 08:08:35 GMT, Kevin Walls wrote: >> test/jdk/javax/management/generified/ListTypeCheckTest.java line 110: >> >>> 108: throw new Exception("test wrong"); >>> 109: } >>> 110: throw new Exception("op " + i + " allowed but should fail on " + al.getClass()); >> >> Nit: This is confusing. If it is allowed then why should it fail. >> At least, it needs to be explained somewhere in the tests. > > Thanks Serguei, I hope I've addressed both comments with additional comment updates. Thank you for the update, Kevin! I've almost done with reviewing but want to make one more pass, especially though the updated tests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25856#discussion_r2198004375 From sspitsyn at openjdk.org Thu Jul 10 15:12:39 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 10 Jul 2025 15:12:39 GMT Subject: RFR: 8359809: AttributeList, RoleList and UnresolvedRoleList should never accept other types of Object [v6] In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 07:58:00 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: > > - Test comment update > - Test comment update It looks good to me now. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25856#pullrequestreview-3006173062 From kevinw at openjdk.org Thu Jul 10 15:23:52 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 10 Jul 2025 15:23:52 GMT Subject: Integrated: 8359809: AttributeList, RoleList and UnresolvedRoleList should never accept other types of Object In-Reply-To: References: Message-ID: On Tue, 17 Jun 2025 16:54:15 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. This pull request has now been integrated. Changeset: cbc7090b Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/cbc7090b91f4ce84117a04036028076373ab805e Stats: 300 lines in 5 files changed: 68 ins; 171 del; 61 mod 8359809: AttributeList, RoleList and UnresolvedRoleList should never accept other types of Object Reviewed-by: sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/25856 From cjplummer at openjdk.org Thu Jul 10 15:45:45 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 10 Jul 2025 15:45:45 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. Thank you for the reviews Kevin and Serguei! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26198#issuecomment-3057984680 From cjplummer at openjdk.org Thu Jul 10 15:45:46 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 10 Jul 2025 15:45:46 GMT Subject: [jdk25] Integrated: 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. This pull request has now been integrated. Changeset: 96380509 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/96380509b31a2dcc41bbba62ec316e1c569b13ab Stats: 25 lines in 5 files changed: 13 ins; 9 del; 3 mod 8360312: Serviceability Agent tests fail with JFR enabled due to unknown thread type JfrRecorderThread Reviewed-by: kevinw, sspitsyn Backport-of: 712d866b72b43c839c57c3303dfb215f94c0db3b ------------- PR: https://git.openjdk.org/jdk/pull/26198 From amenkov at openjdk.org Thu Jul 10 19:59:44 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 10 Jul 2025 19:59:44 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 Thanks for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/26176#issuecomment-3058846580 From amenkov at openjdk.org Thu Jul 10 19:59:44 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 10 Jul 2025 19:59:44 GMT Subject: Integrated: 8358679: [asan] vmTestbase/nsk/jvmti tests show memory issues In-Reply-To: References: Message-ID: <08wWgyozLr_HSBfB_1H67FD5_b31O2Ud1r_QL9nFl_s=.6803e76a-753c-4ec2-b00a-b6eb07f3ed64@github.com> 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. This pull request has now been integrated. Changeset: 2300a212 Author: Alex Menkov URL: https://git.openjdk.org/jdk/commit/2300a212dd135f1f01604c5c2915653a3f3bd869 Stats: 25 lines in 6 files changed: 15 ins; 4 del; 6 mod 8358679: [asan] vmTestbase/nsk/jvmti tests show memory issues Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/26176 From amenkov at openjdk.org Thu Jul 10 20:11:40 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 10 Jul 2025 20:11:40 GMT Subject: RFR: 8361314: Test serviceability/jvmti/VMEvent/MyPackage/VMEventRecursionTest.java FATAL ERROR in native method: Failed during the GetClassSignature call In-Reply-To: References: Message-ID: <0vAXUCSJlAhBSVDE-XXxOJrU6sFEDFJTldAXvHDn5NQ=.23bcd61e-619b-4b21-a7b0-b850daf80a8f@github.com> On Thu, 10 Jul 2025 03:26:56 GMT, Chris Plummer wrote: > Your changes look fine, but I'm a bit confused as to how this test is testing for what it claims it is testing: > > `Verifies that a VM event callback does not recurse if a VM object is allocated during callback.` > > Where is it actually checking that it is not recursing? VMObjectAlloc callback does upcall (`clone`) which does new allocation. So if the recursion happen, the test gets infinite recursion ------------- PR Comment: https://git.openjdk.org/jdk/pull/26231#issuecomment-3058887673 From cjplummer at openjdk.org Thu Jul 10 20:19:37 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 10 Jul 2025 20:19:37 GMT Subject: RFR: 8361314: Test serviceability/jvmti/VMEvent/MyPackage/VMEventRecursionTest.java FATAL ERROR in native method: Failed during the GetClassSignature call In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 00:08:26 GMT, Alex Menkov wrote: > The fix adds guards against JVMTI_ERROR_WRONG_PHASE error in VMObjectAlloc event handler. > > Testing: fixed test on all platforms Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26231#pullrequestreview-3007206886 From cjplummer at openjdk.org Thu Jul 10 20:19:38 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 10 Jul 2025 20:19:38 GMT Subject: RFR: 8361314: Test serviceability/jvmti/VMEvent/MyPackage/VMEventRecursionTest.java FATAL ERROR in native method: Failed during the GetClassSignature call In-Reply-To: <0vAXUCSJlAhBSVDE-XXxOJrU6sFEDFJTldAXvHDn5NQ=.23bcd61e-619b-4b21-a7b0-b850daf80a8f@github.com> References: <0vAXUCSJlAhBSVDE-XXxOJrU6sFEDFJTldAXvHDn5NQ=.23bcd61e-619b-4b21-a7b0-b850daf80a8f@github.com> Message-ID: On Thu, 10 Jul 2025 20:09:23 GMT, Alex Menkov wrote: > VMObjectAlloc callback does upcall (`clone`) which does new allocation. > So if the recursion happen, the test gets infinite recursion Ok, so the failure then will be a StackOverflowException. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26231#issuecomment-3058920509 From cjplummer at openjdk.org Thu Jul 10 21:04:50 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 10 Jul 2025 21:04:50 GMT Subject: RFR: 8361602: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java deadlocks on exception [v3] In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 10:02:56 GMT, Richard Reingruber wrote: >> This pr moves the `notify()` call to the finally block to avoid the deadlock in `join()` if `verifyHeapDump(dumpFile)` throws an exception. >> >> Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Wait while !done With your fix in place, I assume now if verifyHeapDump() throws an exception the test will still fail, but in a more timely and meaningful manner. Why is verifyHeapDump() throwing an exception in the first place. Is that something that still needs to be addressed? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26213#issuecomment-3059069045 From cjplummer at openjdk.org Thu Jul 10 21:19:41 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 10 Jul 2025 21:19:41 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v6] In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 08:24:56 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 spec sections: >> - `PopFrame` >> - `NotifyFramePop` >> - `ForceEarlyReturn` >> - `GetLocal` >> - `SetLocal` >> - general description of the `JVMTI_ERROR_OPAQUE_FRAME` error code >> >> 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: minor tweak of previous change src/hotspot/share/prims/jvmti.xml line 6233: > 6231: > 6232: The implementation is unable to set the frame locals > 6233: (e.g. the frame at depth is executing a native method). The situation here is a little different than other places where you removed the special case for virtual threads. In the other cases above there was already a description of the virtual thread support earlier in the description of the API. However, for SetLocalObject the only description of the virtual thread support is with the JVMTI_ERROR_OPAQUE_FRAME description, which is now removed. I guess to be consistent with earlier APIs, the description of virtual thread support should be added to the API description. This should probably just be done once at the beginning in the "Local Variable" section rather than separately for each API. Or you can re-add the JVMTI_ERROR_OPAQUE_FRAME description here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2198754120 From cjplummer at openjdk.org Thu Jul 10 21:46:21 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 10 Jul 2025 21:46:21 GMT Subject: RFR: 8361905: Problem list serviceability/sa/ClhsdbThreadContext.java on Windows due to JDK-8356704 Message-ID: Problem list serviceability/sa/ClhsdbThreadContext.java on Windows due to numerous failures. ------------- Commit messages: - problem list ClhsdbThreadContext on Windows Changes: https://git.openjdk.org/jdk/pull/26254/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26254&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361905 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26254.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26254/head:pull/26254 PR: https://git.openjdk.org/jdk/pull/26254 From amenkov at openjdk.org Thu Jul 10 21:52:39 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 10 Jul 2025 21:52:39 GMT Subject: RFR: 8361905: Problem list serviceability/sa/ClhsdbThreadContext.java on Windows due to JDK-8356704 In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 21:40:50 GMT, Chris Plummer wrote: > Problem list serviceability/sa/ClhsdbThreadContext.java on Windows due to numerous failures. Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26254#pullrequestreview-3007501620 From dholmes at openjdk.org Thu Jul 10 22:33:38 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 10 Jul 2025 22:33:38 GMT Subject: RFR: 8361602: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java deadlocks on exception [v3] In-Reply-To: References: Message-ID: <2bdbmQ72faQbtrbD3ngMLZkFk54KRNlesXXnJMIfcZo=.dad4e406-d8f4-4f5b-9fcb-6b707335de1c@github.com> On Thu, 10 Jul 2025 10:02:56 GMT, Richard Reingruber wrote: >> This pr moves the `notify()` call to the finally block to avoid the deadlock in `join()` if `verifyHeapDump(dumpFile)` throws an exception. >> >> Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Wait while !done Thanks for update. Still not sure that forcing the join is necessarily desirable if there is an unexpected exception, but ... test/hotspot/jtreg/serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java line 50: > 48: public class UnmountedVThreadNativeMethodAtTop { > 49: > 50: public boolean done; Should not be public ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26213#pullrequestreview-3007594415 PR Review Comment: https://git.openjdk.org/jdk/pull/26213#discussion_r2198886549 From sspitsyn at openjdk.org Fri Jul 11 00:24:39 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 11 Jul 2025 00:24:39 GMT Subject: RFR: 8361314: Test serviceability/jvmti/VMEvent/MyPackage/VMEventRecursionTest.java FATAL ERROR in native method: Failed during the GetClassSignature call In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 00:08:26 GMT, Alex Menkov wrote: > The fix adds guards against JVMTI_ERROR_WRONG_PHASE error in VMObjectAlloc event handler. > > Testing: fixed test on all platforms Changes requested by sspitsyn (Reviewer). Looks good. test/hotspot/jtreg/serviceability/jvmti/VMEvent/libVMEventTest.c line 67: > 65: } > 66: } > 67: Nit: It'd be better to use the `RawMonitorLocker` defined in the `jvmti_common.hpp`. The usages can be found in the `test/hotspot/jtreg/serviceability/jvmti/vthread` tests. ------------- PR Review: https://git.openjdk.org/jdk/pull/26231#pullrequestreview-3007845066 Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26231#pullrequestreview-3007849937 PR Review Comment: https://git.openjdk.org/jdk/pull/26231#discussion_r2199073603 From sspitsyn at openjdk.org Fri Jul 11 00:24:40 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 11 Jul 2025 00:24:40 GMT Subject: RFR: 8361314: Test serviceability/jvmti/VMEvent/MyPackage/VMEventRecursionTest.java FATAL ERROR in native method: Failed during the GetClassSignature call In-Reply-To: References: Message-ID: <_W1wk1WWgfQioBYDzJo5A0v-RTYjs3gpErjbOSwOgPY=.f84499cb-2eec-47ed-9b0f-c4bd1c9ed89d@github.com> On Fri, 11 Jul 2025 00:18:07 GMT, Serguei Spitsyn wrote: >> The fix adds guards against JVMTI_ERROR_WRONG_PHASE error in VMObjectAlloc event handler. >> >> Testing: fixed test on all platforms > > test/hotspot/jtreg/serviceability/jvmti/VMEvent/libVMEventTest.c line 67: > >> 65: } >> 66: } >> 67: > > Nit: It'd be better to use the `RawMonitorLocker` defined in the `jvmti_common.hpp`. > The usages can be found in the `test/hotspot/jtreg/serviceability/jvmti/vthread` tests. Sorry, my suggestion is no applicable. The problem is that this is not a c++ file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26231#discussion_r2199076469 From sspitsyn at openjdk.org Fri Jul 11 00:28:37 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 11 Jul 2025 00:28:37 GMT Subject: RFR: 8361905: Problem list serviceability/sa/ClhsdbThreadContext.java on Windows due to JDK-8356704 In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 21:40:50 GMT, Chris Plummer wrote: > Problem list serviceability/sa/ClhsdbThreadContext.java on Windows due to numerous failures. Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26254#pullrequestreview-3007855137 From sspitsyn at openjdk.org Fri Jul 11 00:31:38 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 11 Jul 2025 00:31:38 GMT Subject: RFR: 8361869: Tests which call ThreadController should mark as /native In-Reply-To: <8AjbR0Au_UZcjgwtlBeWJJfP2oeFtpwAR4wTrxdSdoQ=.e69993ed-8682-49c3-8afa-bd0087eb827b@github.com> References: <8AjbR0Au_UZcjgwtlBeWJJfP2oeFtpwAR4wTrxdSdoQ=.e69993ed-8682-49c3-8afa-bd0087eb827b@github.com> Message-ID: On Thu, 10 Jul 2025 14:09:16 GMT, SendaoYan wrote: > Hi all, > > Several tests which call `ThreadController` native libary missing `/native` jtreg directive. This PR add `/native` directive will make test more friendly. The analysis process of how to find which tests missing show as [JDK-8361869](https://bugs.openjdk.org/browse/JDK-8361869) > Test-fix only, change has been verified locally, no risk. Looks okay. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26244#pullrequestreview-3007864704 From lmesnik at openjdk.org Fri Jul 11 01:47:39 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 11 Jul 2025 01:47:39 GMT Subject: RFR: 8361869: Tests which call ThreadController should mark as /native In-Reply-To: <8AjbR0Au_UZcjgwtlBeWJJfP2oeFtpwAR4wTrxdSdoQ=.e69993ed-8682-49c3-8afa-bd0087eb827b@github.com> References: <8AjbR0Au_UZcjgwtlBeWJJfP2oeFtpwAR4wTrxdSdoQ=.e69993ed-8682-49c3-8afa-bd0087eb827b@github.com> Message-ID: On Thu, 10 Jul 2025 14:09:16 GMT, SendaoYan wrote: > Hi all, > > Several tests which call `ThreadController` native libary missing `/native` jtreg directive. This PR add `/native` directive will make test more friendly. The analysis process of how to find which tests missing show as [JDK-8361869](https://bugs.openjdk.org/browse/JDK-8361869) > Test-fix only, change has been verified locally, no risk. Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26244#pullrequestreview-3008145808 From sspitsyn at openjdk.org Fri Jul 11 04:27:44 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 11 Jul 2025 04:27:44 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v6] In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 21:11:13 GMT, Chris Plummer wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: minor tweak of previous change > > src/hotspot/share/prims/jvmti.xml line 6233: > >> 6231: >> 6232: The implementation is unable to set the frame locals >> 6233: (e.g. the frame at depth is executing a native method). > > The situation here is a little different than other places where you removed the special case for virtual threads. In the other cases above there was already a description of the virtual thread support earlier in the description of the API. However, for SetLocalObject the only description of the virtual thread support is with the JVMTI_ERROR_OPAQUE_FRAME description, which is now removed. I guess to be consistent with earlier APIs, the description of virtual thread support should be added to the API description. This should probably just be done once at the beginning in the "Local Variable" section rather than separately for each API. Or you can re-add the JVMTI_ERROR_OPAQUE_FRAME description here. Thank you for the comment. Yes, I was thinking about adding virtual thread specific clarification for `SetLocal*` to the general API description. I'll prepare and push an update. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2199542452 From sspitsyn at openjdk.org Fri Jul 11 05:28:38 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 11 Jul 2025 05:28:38 GMT Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired [v2] In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 07:20:57 GMT, David Holmes wrote: > So I am quite concerned that this "workaround" has become entrenched. Thank you for the comments and concern! I'll check what can be done here. Need to investigate it a little bit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26232#issuecomment-3060599600 From sspitsyn at openjdk.org Fri Jul 11 05:31:40 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 11 Jul 2025 05:31:40 GMT Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired [v2] In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 07:12:20 GMT, David Holmes wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> corrected one assert message > > src/hotspot/share/runtime/arguments.cpp line 525: > >> 523: // -------------- Deprecated Flags -------------- >> 524: // --- Non-alias flags - sorted by obsolete_in then expired_in: >> 525: { "AllowRedefinitionToAddDeleteMethods", JDK_Version::jdk(13), JDK_Version::jdk(26), JDK_Version::jdk(27) }, > > Please move this line to before line 535 (ParallelRefProcEnabled) so that we are sorted on obsolete_in as required. Thanks. Fixed now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26232#discussion_r2199641968 From sspitsyn at openjdk.org Fri Jul 11 05:49:40 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 11 Jul 2025 05:49:40 GMT Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired [v3] In-Reply-To: References: Message-ID: > The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27. > > TBD: Need to submit a related CSR. > > There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams: > - Class redefinition/retransformation can impact lambda expressions which are supported with private methods > - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now). > > Testing: > - mach5 tiers 1-6 are good > - may need to run mach5 tiers > 6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: keep right order of the obsoleted VM options ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26232/files - new: https://git.openjdk.org/jdk/pull/26232/files/a8358402..833c6169 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26232.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26232/head:pull/26232 PR: https://git.openjdk.org/jdk/pull/26232 From sspitsyn at openjdk.org Fri Jul 11 05:49:41 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 11 Jul 2025 05:49:41 GMT Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired [v2] In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 07:09:49 GMT, David Holmes wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> corrected one assert message > > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4053: > >> 4051: } >> 4052: >> 4053: void VM_RedefineClasses::compute_matching_methods() { > > I can't see that this method actually still does anything useful. ?? I think it does: - has asserts on added/deleted methods - collects `_matching_old_methods` and `_matching_new_methods` It seems that the `_old_methods` is same as `_matching_old_methods` and `_new_methods` is same as `_matching_new_methods`. But I do not want to make a deeper refactoring at this point until we have a decision on the full removal of added/deleted methods support. It feels like we may need to keep some support for lambda expression changes in class redefinitions/retransformations. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26232#discussion_r2199664342 From rrich at openjdk.org Fri Jul 11 08:30:57 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Fri, 11 Jul 2025 08:30:57 GMT Subject: RFR: 8361602: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java deadlocks on exception [v4] In-Reply-To: References: Message-ID: > This pr moves the `notify()` call to the finally block to avoid the deadlock in `join()` if `verifyHeapDump(dumpFile)` throws an exception. > > Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. Richard Reingruber has updated the pull request incrementally with two additional commits since the last revision: - Last line is incomplete (acc. to POSIX). Add newline. - `done` shouldn't be public ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26213/files - new: https://git.openjdk.org/jdk/pull/26213/files/13cb9ba3..c2ae5b24 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26213&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26213&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26213.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26213/head:pull/26213 PR: https://git.openjdk.org/jdk/pull/26213 From rrich at openjdk.org Fri Jul 11 09:10:13 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Fri, 11 Jul 2025 09:10:13 GMT Subject: RFR: 8361602: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java deadlocks on exception [v3] In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 21:01:32 GMT, Chris Plummer wrote: > With your fix in place, I assume now if verifyHeapDump() throws an exception the test will still fail, but in a more timely and meaningful manner. Yes, that's the intention. > Why is verifyHeapDump() throwing an exception in the first place. Is that something that still needs to be addressed? In our local ci testing it throws OOM (even reproducibly on one machine). This is addressed with https://bugs.openjdk.org/browse/JDK-8361602. I've drafted a dependent pr: https://github.com/openjdk/jdk/pull/26260 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26213#issuecomment-3061353586 From coleenp at openjdk.org Fri Jul 11 15:05:40 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 11 Jul 2025 15:05:40 GMT Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired [v3] In-Reply-To: References: Message-ID: On Fri, 11 Jul 2025 05:49:40 GMT, Serguei Spitsyn wrote: >> The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27. >> >> TBD: Need to submit a related CSR. >> >> There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams: >> - Class redefinition/retransformation can impact lambda expressions which are supported with private methods >> - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now). >> >> Testing: >> - mach5 tiers 1-6 are good >> - may need to run mach5 tiers > 6 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: keep right order of the obsoleted VM options It's nice to be able to clean this code out but I also think it's being used in the wild. Was there another mechanism that we suggest for instrumenting native methods? And there was code once to prefix native methods so this adding private method mechanism worked. src/hotspot/share/oops/methodFlags.hpp line 49: > 47: status(is_old , 1 << 2) /* RedefineClasses() has replaced this method */ \ > 48: status(is_obsolete , 1 << 3) /* RedefineClasses() has made method obsolete */ \ > 49: status(RESERVED , 1 << 4) \ Maybe change to unused rather than reserved. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26232#pullrequestreview-3010624569 PR Review Comment: https://git.openjdk.org/jdk/pull/26232#discussion_r2200936076 From coleenp at openjdk.org Fri Jul 11 15:05:42 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 11 Jul 2025 15:05:42 GMT Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired [v2] In-Reply-To: References: Message-ID: On Fri, 11 Jul 2025 05:44:08 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4053: >> >>> 4051: } >>> 4052: >>> 4053: void VM_RedefineClasses::compute_matching_methods() { >> >> I can't see that this method actually still does anything useful. ?? > > I think it does: > - has asserts on added/deleted methods > - collects `_matching_old_methods` and `_matching_new_methods` > > It seems that the `_old_methods` is same as `_matching_old_methods` and `_new_methods` is same as `_matching_new_methods`. But I do not want to make a deeper refactoring at this point until we have a decision on the full removal of added/deleted methods support. It feels like we may need to keep some support for lambda expression changes in class redefinitions/retransformations. What this does now is that the redefined class can have matching method names in a different order because of the signature. So this sorts this out. I don't know why we don't sort methods according to name and signature when creating the klass though. That would make this just a method to check that the methods match. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26232#discussion_r2200944838 From cjplummer at openjdk.org Fri Jul 11 18:24:41 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 11 Jul 2025 18:24:41 GMT Subject: RFR: 8361602: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java deadlocks on exception [v4] In-Reply-To: References: Message-ID: On Fri, 11 Jul 2025 08:30:57 GMT, Richard Reingruber wrote: >> This pr moves the `notify()` call to the finally block to avoid the deadlock in `join()` if `verifyHeapDump(dumpFile)` throws an exception. >> >> Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. > > Richard Reingruber has updated the pull request incrementally with two additional commits since the last revision: > > - Last line is incomplete (acc. to POSIX). Add newline. > - `done` shouldn't be public Looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26213#pullrequestreview-3011455649 From amenkov at openjdk.org Fri Jul 11 18:35:49 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 11 Jul 2025 18:35:49 GMT Subject: Integrated: 8361314: Test serviceability/jvmti/VMEvent/MyPackage/VMEventRecursionTest.java FATAL ERROR in native method: Failed during the GetClassSignature call In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 00:08:26 GMT, Alex Menkov wrote: > The fix adds guards against JVMTI_ERROR_WRONG_PHASE error in VMObjectAlloc event handler. > > Testing: fixed test on all platforms This pull request has now been integrated. Changeset: 8c00c374 Author: Alex Menkov URL: https://git.openjdk.org/jdk/commit/8c00c374ec3e5ae2db3c35a970f6c7a691ae274e Stats: 41 lines in 1 file changed: 40 ins; 0 del; 1 mod 8361314: Test serviceability/jvmti/VMEvent/MyPackage/VMEventRecursionTest.java FATAL ERROR in native method: Failed during the GetClassSignature call Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/26231 From sspitsyn at openjdk.org Fri Jul 11 18:54:34 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 11 Jul 2025 18:54:34 GMT Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired [v4] In-Reply-To: References: Message-ID: > The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27. > > TBD: Need to submit a related CSR. > > There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams: > - Class redefinition/retransformation can impact lambda expressions which are supported with private methods > - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now). > > Testing: > - mach5 tiers 1-6 are good > - may need to run mach5 tiers > 6 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: replace RESERVED flag with UNUSED ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26232/files - new: https://git.openjdk.org/jdk/pull/26232/files/833c6169..fc5630c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26232.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26232/head:pull/26232 PR: https://git.openjdk.org/jdk/pull/26232 From sspitsyn at openjdk.org Fri Jul 11 18:54:37 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 11 Jul 2025 18:54:37 GMT Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired [v3] In-Reply-To: References: Message-ID: On Fri, 11 Jul 2025 14:54:55 GMT, Coleen Phillimore wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: keep right order of the obsoleted VM options > > src/hotspot/share/oops/methodFlags.hpp line 49: > >> 47: status(is_old , 1 << 2) /* RedefineClasses() has replaced this method */ \ >> 48: status(is_obsolete , 1 << 3) /* RedefineClasses() has made method obsolete */ \ >> 49: status(RESERVED , 1 << 4) \ > > Maybe change to unused rather than reserved. Thanks. Fixed now ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26232#discussion_r2201539524 From sspitsyn at openjdk.org Fri Jul 11 19:01:48 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 11 Jul 2025 19:01:48 GMT Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired [v3] In-Reply-To: References: Message-ID: On Fri, 11 Jul 2025 15:02:38 GMT, Coleen Phillimore wrote: > It's nice to be able to clean this code out but I also think it's being used. Was there another mechanism that we suggest for instrumenting native methods? And there was code once to prefix native methods so this adding private method mechanism worked. > > Edit: I seem to remember TransferNativeFunctionRegistration code was for instrumenting native methods that used adding and deleting static private methods. So maybe this should be removed also as a follow-up? In fact, I have a big doubt we really want to get rid of this approach to instrument native methods calls. The same doubt is about lambda expressions change support. It feels we need more thinking on this and some kind of consensus on this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26232#issuecomment-3063405103 From cjplummer at openjdk.org Fri Jul 11 19:31:42 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 11 Jul 2025 19:31:42 GMT Subject: RFR: 8361905: Problem list serviceability/sa/ClhsdbThreadContext.java on Windows due to JDK-8356704 In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 21:40:50 GMT, Chris Plummer wrote: > Problem list serviceability/sa/ClhsdbThreadContext.java on Windows due to numerous failures. Thanks for the reviews Alex and Serguei! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26254#issuecomment-3063511949 From cjplummer at openjdk.org Fri Jul 11 19:31:43 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 11 Jul 2025 19:31:43 GMT Subject: Integrated: 8361905: Problem list serviceability/sa/ClhsdbThreadContext.java on Windows due to JDK-8356704 In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 21:40:50 GMT, Chris Plummer wrote: > Problem list serviceability/sa/ClhsdbThreadContext.java on Windows due to numerous failures. This pull request has now been integrated. Changeset: f7e8d255 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/f7e8d255cc26fcfb02d51584147751d40fff6478 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8361905: Problem list serviceability/sa/ClhsdbThreadContext.java on Windows due to JDK-8356704 Reviewed-by: amenkov, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/26254 From sspitsyn at openjdk.org Fri Jul 11 20:08:01 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 11 Jul 2025 20:08:01 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v7] 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 spec sections: > - `PopFrame` > - `NotifyFramePop` > - `ForceEarlyReturn` > - `GetLocal` > - `SetLocal` > - general description of the `JVMTI_ERROR_OPAQUE_FRAME` error code > > 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge - review: minor tweak of previous change - review: corrected OPAQUE_FRAME clarification for NotifyFramePop function - review: (1) remove vthread specific clarifications; unify GetLocal* and SetLocal* with other functions - review: tweak the OPAQUE_FRAME clarifications for ForceEarlyReturn* functions - review: tweak OPAQUE_FRAME clarification for NotifyFramePop function - 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26111/files - new: https://git.openjdk.org/jdk/pull/26111/files/170fe280..8f6e7787 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26111&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26111&range=05-06 Stats: 16165 lines in 539 files changed: 9142 ins; 3145 del; 3878 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 Fri Jul 11 20:16:24 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 11 Jul 2025 20:16:24 GMT Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired [v5] In-Reply-To: References: Message-ID: > The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27. > > TBD: Need to submit a related CSR. > > There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams: > - Class redefinition/retransformation can impact lambda expressions which are supported with private methods > - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now). > > Testing: > - mach5 tiers 1-6 are good > - may need to run mach5 tiers > 6 Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge - review: replace RESERVED flag with UNUSED - review: keep right order of the obsoleted VM options - corrected one assert message - 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26232/files - new: https://git.openjdk.org/jdk/pull/26232/files/fc5630c1..3900252d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=03-04 Stats: 16165 lines in 539 files changed: 9142 ins; 3145 del; 3878 mod Patch: https://git.openjdk.org/jdk/pull/26232.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26232/head:pull/26232 PR: https://git.openjdk.org/jdk/pull/26232 From cjplummer at openjdk.org Fri Jul 11 22:22:44 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 11 Jul 2025 22:22:44 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v7] In-Reply-To: References: Message-ID: On Fri, 11 Jul 2025 20:08:01 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 spec sections: >> - `PopFrame` >> - `NotifyFramePop` >> - `ForceEarlyReturn` >> - `GetLocal` >> - `SetLocal` >> - general description of the `JVMTI_ERROR_OPAQUE_FRAME` error code >> >> 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge > - review: minor tweak of previous change > - review: corrected OPAQUE_FRAME clarification for NotifyFramePop function > - review: (1) remove vthread specific clarifications; unify GetLocal* and SetLocal* with other functions > - review: tweak the OPAQUE_FRAME clarifications for ForceEarlyReturn* functions > - review: tweak OPAQUE_FRAME clarification for NotifyFramePop function > - 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method src/hotspot/share/prims/jvmti.xml line 5904: > 5902: > 5903: The implementation is unable to get the frame locals > 5904: (e.g. the frame at depth is executing a native method). Is this true, especially the native method handling? I'm looking at changes needed on the JDWP and JDI side, and currently they don't even handle OPAQUE_FRAME. I get the feeling native methods produce JVMTI_ERROR_INVALID_SLOT . For JDWP and JDI things are similar for GetLocalXXX() with the exception that they expect OPAQUE_FRAME when not dealing with a mounted virtual thread suspended at a breakpoint. So basically that means OPAQUE_FRAME handling did not exist before virtual threads. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2201974159 From syan at openjdk.org Sat Jul 12 01:53:43 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 12 Jul 2025 01:53:43 GMT Subject: RFR: 8361869: Tests which call ThreadController should mark as /native In-Reply-To: References: <8AjbR0Au_UZcjgwtlBeWJJfP2oeFtpwAR4wTrxdSdoQ=.e69993ed-8682-49c3-8afa-bd0087eb827b@github.com> Message-ID: On Fri, 11 Jul 2025 00:29:05 GMT, Serguei Spitsyn wrote: >> Hi all, >> >> Several tests which call `ThreadController` native libary missing `/native` jtreg directive. This PR add `/native` directive will make test more friendly. The analysis process of how to find which tests missing show as [JDK-8361869](https://bugs.openjdk.org/browse/JDK-8361869) >> Test-fix only, change has been verified locally, no risk. > > Looks okay. Thanks for the review @sspitsyn @lmesnik ------------- PR Comment: https://git.openjdk.org/jdk/pull/26244#issuecomment-3064493035 From syan at openjdk.org Sat Jul 12 01:53:44 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 12 Jul 2025 01:53:44 GMT Subject: Integrated: 8361869: Tests which call ThreadController should mark as /native In-Reply-To: <8AjbR0Au_UZcjgwtlBeWJJfP2oeFtpwAR4wTrxdSdoQ=.e69993ed-8682-49c3-8afa-bd0087eb827b@github.com> References: <8AjbR0Au_UZcjgwtlBeWJJfP2oeFtpwAR4wTrxdSdoQ=.e69993ed-8682-49c3-8afa-bd0087eb827b@github.com> Message-ID: On Thu, 10 Jul 2025 14:09:16 GMT, SendaoYan wrote: > Hi all, > > Several tests which call `ThreadController` native libary missing `/native` jtreg directive. This PR add `/native` directive will make test more friendly. The analysis process of how to find which tests missing show as [JDK-8361869](https://bugs.openjdk.org/browse/JDK-8361869) > Test-fix only, change has been verified locally, no risk. This pull request has now been integrated. Changeset: 3bacf7ea Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/3bacf7ea85f1e3f5e57fd2d046b98dfafe2c7e18 Stats: 18 lines in 9 files changed: 0 ins; 0 del; 18 mod 8361869: Tests which call ThreadController should mark as /native Reviewed-by: sspitsyn, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/26244 From syan at openjdk.org Sat Jul 12 03:56:37 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 12 Jul 2025 03:56:37 GMT Subject: [jdk25] RFR: 8361869: Tests which call ThreadController should mark as /native Message-ID: Hi all, This pull request contains a backport of commit [3bacf7ea](https://github.com/openjdk/jdk/commit/3bacf7ea85f1e3f5e57fd2d046b98dfafe2c7e18) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by SendaoYan on 12 Jul 2025 and was reviewed by Serguei Spitsyn and Leonid Mesnik. Thanks! ------------- Commit messages: - Backport 3bacf7ea85f1e3f5e57fd2d046b98dfafe2c7e18 Changes: https://git.openjdk.org/jdk/pull/26277/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26277&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361869 Stats: 18 lines in 9 files changed: 0 ins; 0 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/26277.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26277/head:pull/26277 PR: https://git.openjdk.org/jdk/pull/26277 From rrich at openjdk.org Sat Jul 12 05:43:53 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Sat, 12 Jul 2025 05:43:53 GMT Subject: Integrated: 8361602: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java deadlocks on exception In-Reply-To: References: Message-ID: On Wed, 9 Jul 2025 07:39:05 GMT, Richard Reingruber wrote: > This pr moves the `notify()` call to the finally block to avoid the deadlock in `join()` if `verifyHeapDump(dumpFile)` throws an exception. > > Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. This pull request has now been integrated. Changeset: 917d0182 Author: Richard Reingruber URL: https://git.openjdk.org/jdk/commit/917d0182cb5ea6066afd396381ca4650371e64b0 Stats: 10 lines in 1 file changed: 5 ins; 1 del; 4 mod 8361602: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java deadlocks on exception Reviewed-by: cjplummer, clanger, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/26213 From rrich at openjdk.org Sat Jul 12 05:43:53 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Sat, 12 Jul 2025 05:43:53 GMT Subject: RFR: 8361602: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java deadlocks on exception [v4] In-Reply-To: References: Message-ID: <3kgz3G3tD71xlunj9SOlAobCfFXOISM0i7waMSWuX88=.0553bf17-cc87-4352-ade8-3f13dcb71e11@github.com> On Fri, 11 Jul 2025 08:30:57 GMT, Richard Reingruber wrote: >> This pr moves the `notify()` call to the finally block to avoid the deadlock in `join()` if `verifyHeapDump(dumpFile)` throws an exception. >> >> Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. > > Richard Reingruber has updated the pull request incrementally with two additional commits since the last revision: > > - Last line is incomplete (acc. to POSIX). Add newline. > - `done` shouldn't be public Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26213#issuecomment-3064709312 From rrich at openjdk.org Mon Jul 14 07:31:52 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Mon, 14 Jul 2025 07:31:52 GMT Subject: RFR: 8361827: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java throws OutOfMemoryError Message-ID: This pr makes sure to call System.gc() before each test in UnmountedVThreadNativeMethodAtTop.java The intention is to get rid of unreachable objects representing loaded heap dumps from previous tests. This prevents OutOfMemoryErrors. Parsing the smaller dumps is faster too. The PR also includes a reproducer for convenient testing of the pr. ------------- Commit messages: - Revert "Reproduce OOM with duplicate test case" - Fix issue: System.gc() before each test - Reproduce OOM with duplicate test case Changes: https://git.openjdk.org/jdk/pull/26278/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26278&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361827 Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26278.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26278/head:pull/26278 PR: https://git.openjdk.org/jdk/pull/26278 From rrich at openjdk.org Mon Jul 14 07:34:51 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Mon, 14 Jul 2025 07:34:51 GMT Subject: [jdk25] RFR: 8361602: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java deadlocks on exception Message-ID: This pull request contains a backport of commit [917d0182](https://github.com/openjdk/jdk/commit/917d0182cb5ea6066afd396381ca4650371e64b0) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. It moves the notify() call to the finally block to avoid the deadlock in join() if verifyHeapDump(dumpFile) throws an exception. It also wraps the wait into a loop to protect against spurious wake up. The commit being backported was authored by Richard Reingruber on 12 Jul 2025 and was reviewed by Chris Plummer, Christoph Langer and David Holmes. Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. ------------- Commit messages: - Backport 917d0182cb5ea6066afd396381ca4650371e64b0 Changes: https://git.openjdk.org/jdk/pull/26279/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26279&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361602 Stats: 10 lines in 1 file changed: 5 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26279.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26279/head:pull/26279 PR: https://git.openjdk.org/jdk/pull/26279 From clanger at openjdk.org Mon Jul 14 07:39:39 2025 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 14 Jul 2025 07:39:39 GMT Subject: RFR: 8361827: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java throws OutOfMemoryError In-Reply-To: References: Message-ID: <2-Aklh1ZCXhnIeqbz-PxqRssnvj5zfl_ZhEFE64PE0o=.48ce6a3d-c8ae-434c-b6b4-4a2e5762e54d@github.com> On Sat, 12 Jul 2025 06:10:31 GMT, Richard Reingruber wrote: > This pr makes sure to call System.gc() before each test in UnmountedVThreadNativeMethodAtTop.java > > The intention is to get rid of unreachable objects representing loaded heap dumps from previous tests. > > This prevents OutOfMemoryErrors. Parsing the smaller dumps is faster too. > > The PR also includes a reproducer for convenient testing of the pr. Looks good and likely improves test performance and stability. ------------- Marked as reviewed by clanger (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26278#pullrequestreview-3015091182 From clanger at openjdk.org Mon Jul 14 07:39:39 2025 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 14 Jul 2025 07:39:39 GMT Subject: [jdk25] RFR: 8361602: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java deadlocks on exception In-Reply-To: References: Message-ID: On Sat, 12 Jul 2025 08:27:19 GMT, Richard Reingruber wrote: > This pull request contains a backport of commit [917d0182](https://github.com/openjdk/jdk/commit/917d0182cb5ea6066afd396381ca4650371e64b0) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > It moves the notify() call to the finally block to avoid the deadlock in join() if verifyHeapDump(dumpFile) throws an exception. It also wraps the wait into a loop to protect against spurious wake up. > > The commit being backported was authored by Richard Reingruber on 12 Jul 2025 and was reviewed by Chris Plummer, Christoph Langer and David Holmes. > > Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. Marked as reviewed by clanger (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26279#pullrequestreview-3015092367 From syan at openjdk.org Mon Jul 14 12:49:44 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 14 Jul 2025 12:49:44 GMT Subject: RFR: 8361827: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java throws OutOfMemoryError In-Reply-To: References: Message-ID: <8W8K1NbB059f5EeFXGwRkTVbjGTB_3vqeI4oWyPS5IQ=.6debe558-4cd8-4522-9097-2a3f573611dd@github.com> On Sat, 12 Jul 2025 06:10:31 GMT, Richard Reingruber wrote: > This pr makes sure to call System.gc() before each test in UnmountedVThreadNativeMethodAtTop.java > > The intention is to get rid of unreachable objects representing loaded heap dumps from previous tests. > > This prevents OutOfMemoryErrors. Parsing the smaller dumps is faster too. > > The PR also includes a reproducer for convenient testing of the pr. Marked as reviewed by syan (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26278#pullrequestreview-3016242126 From cjplummer at openjdk.org Mon Jul 14 16:45:51 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 14 Jul 2025 16:45:51 GMT Subject: [jdk25] RFR: 8361905: Problem list serviceability/sa/ClhsdbThreadContext.java on Windows due to JDK-8356704 Message-ID: This issue is somewhat noisy on JDK 25 also, so warrants a backport. Backport is clean. ------------- Commit messages: - Backport f7e8d255cc26fcfb02d51584147751d40fff6478 Changes: https://git.openjdk.org/jdk/pull/26297/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26297&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361905 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26297.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26297/head:pull/26297 PR: https://git.openjdk.org/jdk/pull/26297 From cjplummer at openjdk.org Mon Jul 14 17:29:41 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 14 Jul 2025 17:29:41 GMT Subject: [jdk25] RFR: 8361602: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java deadlocks on exception In-Reply-To: References: Message-ID: On Sat, 12 Jul 2025 08:27:19 GMT, Richard Reingruber wrote: > This pull request contains a backport of commit [917d0182](https://github.com/openjdk/jdk/commit/917d0182cb5ea6066afd396381ca4650371e64b0) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > It moves the notify() call to the finally block to avoid the deadlock in join() if verifyHeapDump(dumpFile) throws an exception. It also wraps the wait into a loop to protect against spurious wake up. > > The commit being backported was authored by Richard Reingruber on 12 Jul 2025 and was reviewed by Chris Plummer, Christoph Langer and David Holmes. > > Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26279#pullrequestreview-3017179464 From sspitsyn at openjdk.org Mon Jul 14 21:46:41 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 14 Jul 2025 21:46:41 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v7] In-Reply-To: References: Message-ID: On Fri, 11 Jul 2025 22:18:09 GMT, Chris Plummer wrote: >> Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: >> >> - Merge >> - review: minor tweak of previous change >> - review: corrected OPAQUE_FRAME clarification for NotifyFramePop function >> - review: (1) remove vthread specific clarifications; unify GetLocal* and SetLocal* with other functions >> - review: tweak the OPAQUE_FRAME clarifications for ForceEarlyReturn* functions >> - review: tweak OPAQUE_FRAME clarification for NotifyFramePop function >> - 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method > > src/hotspot/share/prims/jvmti.xml line 5904: > >> 5902: >> 5903: The implementation is unable to get the frame locals >> 5904: (e.g. the frame at depth is executing a native method). > > Is this true, especially the native method handling? I'm looking at changes needed on the JDWP and JDI side, and currently they don't even handle OPAQUE_FRAME. I get the feeling native methods produce JVMTI_ERROR_INVALID_SLOT . > > For JDWP and JDI things are similar for GetLocalXXX() with the exception that they expect OPAQUE_FRAME when not dealing with a mounted virtual thread suspended at a breakpoint. So basically that means OPAQUE_FRAME handling did not exist before virtual threads. Thank you for the concern. But I'm kind of puzzled with your observation. The JVMTI implementation should return `JVMTI_ERROR_OPAQUE_FRAME` for platform threads. Though I wonder if it also was the case before virtual thread support was added. The `VM_BaseGetOrSetLocal::doit()` have the following checks in place: void VM_BaseGetOrSetLocal::doit() { . . . frame fr = _jvf->fr(); if (_set && _depth != 0 && Continuation::is_frame_in_continuation(_jvf->thread(), fr)) { _result = JVMTI_ERROR_OPAQUE_FRAME; // deferred locals are not fully supported in continuations return; } Method* method = _jvf->method(); if (getting_receiver()) { if (method->is_static()) { _result = JVMTI_ERROR_INVALID_SLOT; ### This check is for GetLocalInstance return; } } else { if (method->is_native()) { _result = JVMTI_ERROR_OPAQUE_FRAME; ### This check is before calls to ### check_slot_type_no_lvt() and check_slot_type_lvt() return; } if (!check_slot_type_no_lvt(_jvf)) { ### This has checks for JVMTI_ERROR_INVALID_SLOT return; } if (method->has_localvariable_table() && !check_slot_type_lvt(_jvf)) { ### This has checks for JVMTI_ERROR_INVALID_SLOT return; } } . . . ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2205878604 From sspitsyn at openjdk.org Mon Jul 14 22:54:39 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 14 Jul 2025 22:54:39 GMT Subject: [jdk25] RFR: 8361905: Problem list serviceability/sa/ClhsdbThreadContext.java on Windows due to JDK-8356704 In-Reply-To: References: Message-ID: On Mon, 14 Jul 2025 16:40:43 GMT, Chris Plummer wrote: > This issue is somewhat noisy on JDK 25 also, so warrants a backport. Backport is clean. Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26297#pullrequestreview-3018018915 From cjplummer at openjdk.org Mon Jul 14 23:25:39 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 14 Jul 2025 23:25:39 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v7] In-Reply-To: References: Message-ID: On Mon, 14 Jul 2025 21:42:42 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/prims/jvmti.xml line 5904: >> >>> 5902: >>> 5903: The implementation is unable to get the frame locals >>> 5904: (e.g. the frame at depth is executing a native method). >> >> Is this true, especially the native method handling? I'm looking at changes needed on the JDWP and JDI side, and currently they don't even handle OPAQUE_FRAME. I get the feeling native methods produce JVMTI_ERROR_INVALID_SLOT . >> >> For JDWP and JDI things are similar for GetLocalXXX() with the exception that they expect OPAQUE_FRAME when not dealing with a mounted virtual thread suspended at a breakpoint. So basically that means OPAQUE_FRAME handling did not exist before virtual threads. > > Thank you for the concern. But I'm kind of puzzled with your observation. > The JVMTI implementation should return `JVMTI_ERROR_OPAQUE_FRAME` for platform threads. > Though I wonder if it also was the case before virtual thread support was added. > > The `VM_BaseGetOrSetLocal::doit()` have the following checks in place: > > > void VM_BaseGetOrSetLocal::doit() { > . . . > frame fr = _jvf->fr(); > if (_set && _depth != 0 && Continuation::is_frame_in_continuation(_jvf->thread(), fr)) { > _result = JVMTI_ERROR_OPAQUE_FRAME; // deferred locals are not fully supported in continuations > return; > } > Method* method = _jvf->method(); > if (getting_receiver()) { > if (method->is_static()) { > _result = JVMTI_ERROR_INVALID_SLOT; ### This check is for GetLocalInstance > return; > } > } else { > if (method->is_native()) { > _result = JVMTI_ERROR_OPAQUE_FRAME; ### This check is before calls to > ### check_slot_type_no_lvt() and check_slot_type_lvt() > return; > } > if (!check_slot_type_no_lvt(_jvf)) { ### This has checks for JVMTI_ERROR_INVALID_SLOT > return; > } > if (method->has_localvariable_table() && > !check_slot_type_lvt(_jvf)) { ### This has checks for JVMTI_ERROR_INVALID_SLOT > return; > } > } > . . . My concern was that Set/GetLocal could produce JVMTI_ERROR_OPAQUE_FRAME for a native frame, and JDI was not handling this, but is appears that JDI is prevening Set/GetLocal on a native frame. Read on for more details. It looks like historically Set/GetLocal has returned JVMTI_ERROR_OPAQUE_FRAME for native methods. However, JDI does not check for this, so I had some concern about that because JVMTI_ERROR_OPAQUE_FRAME would result in a JDIInternalError. However, I think now that JDI would never result in a JVMTI Set/GetLocal call when the frame is native because of checks JDI does ahead of time. The JDI Set/GetValue APIs take a LocalVariable, the source of which would preclude ever getting one for a frame that is for a native method. I think what is most common is to call StackFrame.visibleVariables() to get all the LocalVariables, and if this is done on a native method, you simply get no LocalVariables, thus you have nothing to pass to Set/GetLocal. So I think the only time JDI will see JVMTI_ERROR_OPAQUE_FRAME is for the virtual thread case, which for SetLocal requires that the frame be the topmost frame and the virtual thread be mounted. The JDI spec is already covering this, so probably no changes are needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2205981269 From sspitsyn at openjdk.org Tue Jul 15 03:02:38 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 15 Jul 2025 03:02:38 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v7] In-Reply-To: References: Message-ID: On Mon, 14 Jul 2025 23:23:21 GMT, Chris Plummer wrote: >> Thank you for the concern. But I'm kind of puzzled with your observation. >> The JVMTI implementation should return `JVMTI_ERROR_OPAQUE_FRAME` for platform threads. >> Though I wonder if it also was the case before virtual thread support was added. >> >> The `VM_BaseGetOrSetLocal::doit()` have the following checks in place: >> >> >> void VM_BaseGetOrSetLocal::doit() { >> . . . >> frame fr = _jvf->fr(); >> if (_set && _depth != 0 && Continuation::is_frame_in_continuation(_jvf->thread(), fr)) { >> _result = JVMTI_ERROR_OPAQUE_FRAME; // deferred locals are not fully supported in continuations >> return; >> } >> Method* method = _jvf->method(); >> if (getting_receiver()) { >> if (method->is_static()) { >> _result = JVMTI_ERROR_INVALID_SLOT; ### This check is for GetLocalInstance >> return; >> } >> } else { >> if (method->is_native()) { >> _result = JVMTI_ERROR_OPAQUE_FRAME; ### This check is before calls to >> ### check_slot_type_no_lvt() and check_slot_type_lvt() >> return; >> } >> if (!check_slot_type_no_lvt(_jvf)) { ### This has checks for JVMTI_ERROR_INVALID_SLOT >> return; >> } >> if (method->has_localvariable_table() && >> !check_slot_type_lvt(_jvf)) { ### This has checks for JVMTI_ERROR_INVALID_SLOT >> return; >> } >> } >> . . . > > My concern was that Set/GetLocal could produce JVMTI_ERROR_OPAQUE_FRAME for a native frame, and JDI was not handling this, but is appears that JDI is prevening Set/GetLocal on a native frame. Read on for more details. > > It looks like historically Set/GetLocal has returned JVMTI_ERROR_OPAQUE_FRAME for native methods. However, JDI does not check for this, so I had some concern about that because JVMTI_ERROR_OPAQUE_FRAME would result in a JDIInternalError. However, I think now that JDI would never result in a JVMTI Set/GetLocal call when the frame is native because of checks JDI does ahead of time. The JDI Set/GetValue APIs take a LocalVariable, the source of which would preclude ever getting one for a frame that is for a native method. I think what is most common is to call StackFrame.visibleVariables() to get all the LocalVariables, and if this is done on a native method, you simply get no LocalVariables, thus you have nothing to pass to Set/GetLocal. > > So I think the only time JDI will see JVMTI_ERROR_OPAQUE_FRAME is for the virtual thread case, which for SetLocal requires that the frame be the topmost frame and the virtual thread be mounted. The JDI spec is already covering this, so probably no changes are needed. Okay, thanks. This sounds right. ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2206180435 From lmesnik at openjdk.org Tue Jul 15 03:07:38 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 15 Jul 2025 03:07:38 GMT Subject: RFR: 8362203: assert(state == nullptr || state->get_thread_oop() != nullptr) failed: incomplete state Message-ID: The problem happens if post_early_vm_start is triggered. The fix is to complete initialization once threadObj become available. I'vent observed that recompute_enable and hitting assertion might happens before this step. However it might be makes sense to check state in assertion if needed. ------------- Commit messages: - fixed comments after feedback, some polishing - 8362203: assert(state == nullptr || state->get_thread_oop() != nullptr) failed: incomplete state Changes: https://git.openjdk.org/jdk/pull/26303/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26303&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8362203 Stats: 19 lines in 4 files changed: 17 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26303/head:pull/26303 PR: https://git.openjdk.org/jdk/pull/26303 From sspitsyn at openjdk.org Tue Jul 15 03:07:39 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 15 Jul 2025 03:07:39 GMT Subject: RFR: 8362203: assert(state == nullptr || state->get_thread_oop() != nullptr) failed: incomplete state In-Reply-To: References: Message-ID: On Mon, 14 Jul 2025 23:42:03 GMT, Leonid Mesnik wrote: > The problem happens if post_early_vm_start is triggered. > The fix is to complete initialization once threadObj become available. > > I'vent observed that recompute_enable and hitting assertion might happens before this step. However it might be makes sense to check state in assertion if needed. Changes requested by sspitsyn (Reviewer). src/hotspot/share/prims/jvmtiExport.cpp line 678: > 676: EVT_TRIG_TRACE(JVMTI_EVENT_VM_START, ("Trg VM start event triggered" )); > 677: > 678: // The thread state might be incomplete if initialized in post_early_vm_start Nit: Better to say "The JvmtiThreadState might be incomplete" to avoid confusion with other means of thread state. src/hotspot/share/prims/jvmtiThreadState.cpp line 1045: > 1043: > 1044: void JvmtiThreadState::update_thread_oop(JavaThread* thread) { > 1045: assert(thread->threadObj() != nullptr, "Should threadObj be already initialized"); Nit: Better just to say: "Sanity check". ------------- PR Review: https://git.openjdk.org/jdk/pull/26303#pullrequestreview-3018124707 PR Review Comment: https://git.openjdk.org/jdk/pull/26303#discussion_r2206025058 PR Review Comment: https://git.openjdk.org/jdk/pull/26303#discussion_r2206028317 From lmesnik at openjdk.org Tue Jul 15 03:07:40 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 15 Jul 2025 03:07:40 GMT Subject: RFR: 8362203: assert(state == nullptr || state->get_thread_oop() != nullptr) failed: incomplete state In-Reply-To: References: Message-ID: On Mon, 14 Jul 2025 23:42:03 GMT, Leonid Mesnik wrote: > The problem happens if post_early_vm_start is triggered. > The fix is to complete initialization once threadObj become available. > > I'vent observed that recompute_enable and hitting assertion might happens before this step. However it might be makes sense to check state in assertion if needed. I renamed function just to make clear that it should be used once in startup phase. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26303#issuecomment-3071735984 From lmesnik at openjdk.org Tue Jul 15 03:07:40 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 15 Jul 2025 03:07:40 GMT Subject: RFR: 8362203: assert(state == nullptr || state->get_thread_oop() != nullptr) failed: incomplete state In-Reply-To: References: Message-ID: On Tue, 15 Jul 2025 00:17:04 GMT, Serguei Spitsyn wrote: >> The problem happens if post_early_vm_start is triggered. >> The fix is to complete initialization once threadObj become available. >> >> I'vent observed that recompute_enable and hitting assertion might happens before this step. However it might be makes sense to check state in assertion if needed. > > src/hotspot/share/prims/jvmtiExport.cpp line 678: > >> 676: EVT_TRIG_TRACE(JVMTI_EVENT_VM_START, ("Trg VM start event triggered" )); >> 677: >> 678: // The thread state might be incomplete if initialized in post_early_vm_start > > Nit: Better to say "The JvmtiThreadState might be incomplete" to avoid confusion with other means of thread state. updated > src/hotspot/share/prims/jvmtiThreadState.cpp line 1045: > >> 1043: >> 1044: void JvmtiThreadState::update_thread_oop(JavaThread* thread) { >> 1045: assert(thread->threadObj() != nullptr, "Should threadObj be already initialized"); > > Nit: Better just to say: "Sanity check". updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26303#discussion_r2206182954 PR Review Comment: https://git.openjdk.org/jdk/pull/26303#discussion_r2206182861 From sspitsyn at openjdk.org Tue Jul 15 03:08:41 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 15 Jul 2025 03:08:41 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v6] In-Reply-To: References: Message-ID: On Thu, 10 Jul 2025 21:11:13 GMT, Chris Plummer wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: minor tweak of previous change > > src/hotspot/share/prims/jvmti.xml line 6233: > >> 6231: >> 6232: The implementation is unable to set the frame locals >> 6233: (e.g. the frame at depth is executing a native method). > > The situation here is a little different than other places where you removed the special case for virtual threads. In the other cases above there was already a description of the virtual thread support earlier in the description of the API. However, for SetLocalObject the only description of the virtual thread support is with the JVMTI_ERROR_OPAQUE_FRAME description, which is now removed. I guess to be consistent with earlier APIs, the description of virtual thread support should be added to the API description. This should probably just be done once at the beginning in the "Local Variable" section rather than separately for each API. Or you can re-add the JVMTI_ERROR_OPAQUE_FRAME description here. @plummercj Please, let me know if I've addressed your concern or you still want a spec update. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2206185378 From cjplummer at openjdk.org Tue Jul 15 03:14:38 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 15 Jul 2025 03:14:38 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v7] In-Reply-To: References: Message-ID: On Tue, 15 Jul 2025 03:00:12 GMT, Serguei Spitsyn wrote: >> My concern was that Set/GetLocal could produce JVMTI_ERROR_OPAQUE_FRAME for a native frame, and JDI was not handling this, but is appears that JDI is prevening Set/GetLocal on a native frame. Read on for more details. >> >> It looks like historically Set/GetLocal has returned JVMTI_ERROR_OPAQUE_FRAME for native methods. However, JDI does not check for this, so I had some concern about that because JVMTI_ERROR_OPAQUE_FRAME would result in a JDIInternalError. However, I think now that JDI would never result in a JVMTI Set/GetLocal call when the frame is native because of checks JDI does ahead of time. The JDI Set/GetValue APIs take a LocalVariable, the source of which would preclude ever getting one for a frame that is for a native method. I think what is most common is to call StackFrame.visibleVariables() to get all the LocalVariables, and if this is done on a native method, you simply get no LocalVariables, thus you have nothing to pass to Set/GetLocal. >> >> So I think the only time JDI will see JVMTI_ERROR_OPAQUE_FRAME is for the virtual thread case, which for SetLocal requires that the frame be the topmost frame and the virtual thread be mounted. The JDI spec is already covering this, so probably no changes are needed. > > Okay, thanks. This sounds right. ? ...but JDWP might need some work. StackFrame.SetValues and GetValues only mentions OPAQUE_FRAME for SetValues of a virtual thread. However, I don't think there is anything to prevent them being called on a native frame. You might expect INVALID_SLOT in that case because it would not be possible to specify a valid slot for a local when there are none, but from the code you gave above it looks like slot checks are made after the native method check. So if a combination of a native method and invalid slot results in OPAQUE_FRAME, then we need to update the JDWP spec to reflect this. The other choice is to make JVMTI return INVALID_SLOT when the method is native. And speaking of INVALID_SLOT, it missing in the JDWP spec for SetValues, but is there for GetValues. It seems that should be fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2206190118 From cjplummer at openjdk.org Tue Jul 15 03:22:39 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 15 Jul 2025 03:22:39 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v7] In-Reply-To: References: Message-ID: <16umPXOVTbR55u-y9vmxOv4Vb-laTixA-0g2jin80Rw=.651ed95b-aca9-41b3-9c7a-27982ca1c9a8@github.com> On Fri, 11 Jul 2025 20:08:01 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 spec sections: >> - `PopFrame` >> - `NotifyFramePop` >> - `ForceEarlyReturn` >> - `GetLocal` >> - `SetLocal` >> - general description of the `JVMTI_ERROR_OPAQUE_FRAME` error code >> >> 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge > - review: minor tweak of previous change > - review: corrected OPAQUE_FRAME clarification for NotifyFramePop function > - review: (1) remove vthread specific clarifications; unify GetLocal* and SetLocal* with other functions > - review: tweak the OPAQUE_FRAME clarifications for ForceEarlyReturn* functions > - review: tweak OPAQUE_FRAME clarification for NotifyFramePop function > - 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26111#pullrequestreview-3018370144 From cjplummer at openjdk.org Tue Jul 15 03:22:40 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 15 Jul 2025 03:22:40 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v6] In-Reply-To: References: Message-ID: On Tue, 15 Jul 2025 03:06:10 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/prims/jvmti.xml line 6233: >> >>> 6231: >>> 6232: The implementation is unable to set the frame locals >>> 6233: (e.g. the frame at depth is executing a native method). >> >> The situation here is a little different than other places where you removed the special case for virtual threads. In the other cases above there was already a description of the virtual thread support earlier in the description of the API. However, for SetLocalObject the only description of the virtual thread support is with the JVMTI_ERROR_OPAQUE_FRAME description, which is now removed. I guess to be consistent with earlier APIs, the description of virtual thread support should be added to the API description. This should probably just be done once at the beginning in the "Local Variable" section rather than separately for each API. Or you can re-add the JVMTI_ERROR_OPAQUE_FRAME description here. > > @plummercj Please, let me know if I've addressed your concern or you still want a spec update. Yes, I think it looks fine. I thought the section you referred to that clarifies virtual threads was only for GetLocalXXX, but I see now it is also for SetLocalXXX. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2206196187 From sspitsyn at openjdk.org Tue Jul 15 04:27:44 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 15 Jul 2025 04:27:44 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v6] In-Reply-To: References: Message-ID: On Tue, 15 Jul 2025 03:19:57 GMT, Chris Plummer wrote: >> @plummercj Please, let me know if I've addressed your concern or you still want a spec update. > > Yes, I think it looks fine. I thought the section you referred to that clarifies virtual threads was only for GetLocalXXX, but I see now it is also for SetLocalXXX. Okay, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2206257447 From sspitsyn at openjdk.org Tue Jul 15 04:38:40 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 15 Jul 2025 04:38:40 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v7] In-Reply-To: References: Message-ID: On Fri, 11 Jul 2025 20:08:01 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 spec sections: >> - `PopFrame` >> - `NotifyFramePop` >> - `ForceEarlyReturn` >> - `GetLocal` >> - `SetLocal` >> - general description of the `JVMTI_ERROR_OPAQUE_FRAME` error code >> >> 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge > - review: minor tweak of previous change > - review: corrected OPAQUE_FRAME clarification for NotifyFramePop function > - review: (1) remove vthread specific clarifications; unify GetLocal* and SetLocal* with other functions > - review: tweak the OPAQUE_FRAME clarifications for ForceEarlyReturn* functions > - review: tweak OPAQUE_FRAME clarification for NotifyFramePop function > - 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method Thank you for review, Chris! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26111#issuecomment-3071864368 From sspitsyn at openjdk.org Tue Jul 15 04:38:41 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 15 Jul 2025 04:38:41 GMT Subject: RFR: 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method [v7] In-Reply-To: References: Message-ID: On Tue, 15 Jul 2025 03:12:13 GMT, Chris Plummer wrote: > So if a combination of a native method and invalid slot results in OPAQUE_FRAME, then we need to update the JDWP spec to reflect this. Agreed > And speaking of INVALID_SLOT, it missing in the JDWP spec for SetValues, but is there for GetValues. It seems that should be fixed. Agreed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26111#discussion_r2206313896 From sspitsyn at openjdk.org Tue Jul 15 07:22:39 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 15 Jul 2025 07:22:39 GMT Subject: RFR: 8362203: assert(state == nullptr || state->get_thread_oop() != nullptr) failed: incomplete state In-Reply-To: References: Message-ID: On Mon, 14 Jul 2025 23:42:03 GMT, Leonid Mesnik wrote: > The problem happens if post_early_vm_start is triggered. > The fix is to complete initialization once threadObj become available. > > I'vent observed that recompute_enable and hitting assertion might happens before this step. However it might be makes sense to check state in assertion if needed. This looks good in general. Thank you for catching with Kitchensink and fixing this issue! I've posted a couple of nits. src/hotspot/share/prims/jvmtiThreadState.cpp line 1046: > 1044: void JvmtiThreadState::update_thread_oop_during_vm_start(JavaThread* thread) { > 1045: assert(thread->threadObj() != nullptr, "santity check"); > 1046: if (thread->jvmti_thread_state()->get_thread_oop() == nullptr) { Nit: Replace `thread->jvmti_thread_state()->get_thread_oop()` with `get_thread_oop()`. src/hotspot/share/prims/jvmtiThreadState.cpp line 1047: > 1045: assert(thread->threadObj() != nullptr, "santity check"); > 1046: if (thread->jvmti_thread_state()->get_thread_oop() == nullptr) { > 1047: _thread_oop_h.release(JvmtiExport::jvmti_oop_storage()); Nit: This line needs a comment explaining we are releasing an `OopHandle` pointing to `null`. ------------- PR Review: https://git.openjdk.org/jdk/pull/26303#pullrequestreview-3019013676 PR Review Comment: https://git.openjdk.org/jdk/pull/26303#discussion_r2206621244 PR Review Comment: https://git.openjdk.org/jdk/pull/26303#discussion_r2206627052 From lmesnik at openjdk.org Tue Jul 15 07:57:53 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 15 Jul 2025 07:57:53 GMT Subject: RFR: 8362203: assert(state == nullptr || state->get_thread_oop() != nullptr) failed: incomplete state [v2] In-Reply-To: References: Message-ID: > The problem happens if post_early_vm_start is triggered. > The fix is to complete initialization once threadObj become available. > > I'vent observed that recompute_enable and hitting assertion might happens before this step. However it might be makes sense to check state in assertion if needed. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: simplified the update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26303/files - new: https://git.openjdk.org/jdk/pull/26303/files/19e76aa9..a8d5e277 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26303&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26303&range=00-01 Stats: 8 lines in 3 files changed: 1 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26303/head:pull/26303 PR: https://git.openjdk.org/jdk/pull/26303 From lmesnik at openjdk.org Tue Jul 15 07:57:53 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 15 Jul 2025 07:57:53 GMT Subject: RFR: 8362203: assert(state == nullptr || state->get_thread_oop() != nullptr) failed: incomplete state [v2] In-Reply-To: References: Message-ID: <6N3jM4b8JwxgRo-TaPTtKotne-noij-EFc0ZuPA9Suo=.b30387b7-8564-4871-946f-1a115db7d89d@github.com> On Tue, 15 Jul 2025 07:17:10 GMT, Serguei Spitsyn wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> simplified the update > > src/hotspot/share/prims/jvmtiThreadState.cpp line 1046: > >> 1044: void JvmtiThreadState::update_thread_oop_during_vm_start(JavaThread* thread) { >> 1045: assert(thread->threadObj() != nullptr, "santity check"); >> 1046: if (thread->jvmti_thread_state()->get_thread_oop() == nullptr) { > > Nit: Replace `thread->jvmti_thread_state()->get_thread_oop()` with `get_thread_oop()`. I realised that thread is already in this state, so no need to set it as a parameter. > src/hotspot/share/prims/jvmtiThreadState.cpp line 1047: > >> 1045: assert(thread->threadObj() != nullptr, "santity check"); >> 1046: if (thread->jvmti_thread_state()->get_thread_oop() == nullptr) { >> 1047: _thread_oop_h.release(JvmtiExport::jvmti_oop_storage()); > > Nit: This line needs a comment explaining we are releasing an `OopHandle` pointing to `null`. I realized that there is replace method and use it instead of release/update. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26303#discussion_r2206722425 PR Review Comment: https://git.openjdk.org/jdk/pull/26303#discussion_r2206725694 From rrich at openjdk.org Tue Jul 15 08:05:47 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Tue, 15 Jul 2025 08:05:47 GMT Subject: [jdk25] RFR: 8361602: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java deadlocks on exception In-Reply-To: References: Message-ID: <7Aakf8YYDwLDIruW6rHfNKT36guAAdihB-NOd-0fQ7E=.64ff804f-e991-4fb4-811d-b0a0c8de5a2c@github.com> On Sat, 12 Jul 2025 08:27:19 GMT, Richard Reingruber wrote: > This pull request contains a backport of commit [917d0182](https://github.com/openjdk/jdk/commit/917d0182cb5ea6066afd396381ca4650371e64b0) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > It moves the notify() call to the finally block to avoid the deadlock in join() if verifyHeapDump(dumpFile) throws an exception. It also wraps the wait into a loop to protect against spurious wake up. > > The commit being backported was authored by Richard Reingruber on 12 Jul 2025 and was reviewed by Chris Plummer, Christoph Langer and David Holmes. > > Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. Thanks for reviewing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26279#issuecomment-3072548389 From rrich at openjdk.org Tue Jul 15 08:05:47 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Tue, 15 Jul 2025 08:05:47 GMT Subject: [jdk25] Integrated: 8361602: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java deadlocks on exception In-Reply-To: References: Message-ID: On Sat, 12 Jul 2025 08:27:19 GMT, Richard Reingruber wrote: > This pull request contains a backport of commit [917d0182](https://github.com/openjdk/jdk/commit/917d0182cb5ea6066afd396381ca4650371e64b0) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > It moves the notify() call to the finally block to avoid the deadlock in join() if verifyHeapDump(dumpFile) throws an exception. It also wraps the wait into a loop to protect against spurious wake up. > > The commit being backported was authored by Richard Reingruber on 12 Jul 2025 and was reviewed by Chris Plummer, Christoph Langer and David Holmes. > > Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. This pull request has now been integrated. Changeset: ce85123f Author: Richard Reingruber URL: https://git.openjdk.org/jdk/commit/ce85123f3ab23839261084c7dbf933202dcb7194 Stats: 10 lines in 1 file changed: 5 ins; 1 del; 4 mod 8361602: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java deadlocks on exception Reviewed-by: clanger, cjplummer Backport-of: 917d0182cb5ea6066afd396381ca4650371e64b0 ------------- PR: https://git.openjdk.org/jdk/pull/26279 From cjplummer at openjdk.org Tue Jul 15 18:29:47 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 15 Jul 2025 18:29:47 GMT Subject: [jdk25] RFR: 8361905: Problem list serviceability/sa/ClhsdbThreadContext.java on Windows due to JDK-8356704 In-Reply-To: References: Message-ID: <_8tGkTQgB615wzFubQ8TemPloMd9gorfus9HoF2RDCE=.c6335e83-103e-4a71-9888-be8cb4b621b1@github.com> On Mon, 14 Jul 2025 16:40:43 GMT, Chris Plummer wrote: > This issue is somewhat noisy on JDK 25 also, so warrants a backport. Backport is clean. Thanks Serguei! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26297#issuecomment-3074921945 From cjplummer at openjdk.org Tue Jul 15 18:32:46 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 15 Jul 2025 18:32:46 GMT Subject: [jdk25] Integrated: 8361905: Problem list serviceability/sa/ClhsdbThreadContext.java on Windows due to JDK-8356704 In-Reply-To: References: Message-ID: <8Ex3BNCxbppEJP-D4Vs5NjU8Op6MLwrK4bRkgBxNmGc=.bccdefa9-d823-4a7e-ad8a-ea936e3c0f4d@github.com> On Mon, 14 Jul 2025 16:40:43 GMT, Chris Plummer wrote: > This issue is somewhat noisy on JDK 25 also, so warrants a backport. Backport is clean. This pull request has now been integrated. Changeset: cf92877a Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/cf92877aa5be8c4610b41203117eb24a26c7abdc Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8361905: Problem list serviceability/sa/ClhsdbThreadContext.java on Windows due to JDK-8356704 Reviewed-by: sspitsyn Backport-of: f7e8d255cc26fcfb02d51584147751d40fff6478 ------------- PR: https://git.openjdk.org/jdk/pull/26297 From amenkov at openjdk.org Tue Jul 15 18:42:40 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 15 Jul 2025 18:42:40 GMT Subject: RFR: 8362203: assert(state == nullptr || state->get_thread_oop() != nullptr) failed: incomplete state [v2] In-Reply-To: References: Message-ID: <09hGHb4ZK7YXxHJF1qCin5x01CD9opJ4_0rPHOU9qOA=.c291a820-6850-4bca-90bb-dbf507c9dc28@github.com> On Tue, 15 Jul 2025 07:57:53 GMT, Leonid Mesnik wrote: >> The problem happens if post_early_vm_start is triggered. >> The fix is to complete initialization once threadObj become available. >> >> I'vent observed that recompute_enable and hitting assertion might happens before this step. However it might be makes sense to check state in assertion if needed. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > simplified the update test/hotspot/jtreg/serviceability/jvmti/StartPhase/AllowedFunctions/AllowedFunctions.java line 32: > 30: * @run main/othervm/native -agentlib:AllowedFunctions AllowedFunctions > 31: * @run main/othervm/native -agentlib:AllowedFunctions=with_early_vmstart AllowedFunctions > 32: * @run main/othervm/native -agentlib:AllowedFunctions=with_early_vmstart -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n AllowedFunctions Do I understand correctly this test case reproduces the issue? - there is extra space before `-Xrunjdwp` - would be better to use automatic port (address=0) to avoid "port in use" - need to update (c) years in the file ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26303#discussion_r2208336956 From cjplummer at openjdk.org Tue Jul 15 22:12:49 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 15 Jul 2025 22:12:49 GMT Subject: RFR: 8309400: JDI spec needs to clarify when OpaqueFrameException and NativeMethodException are thrown Message-ID: Fix how ThreadReference.popFrame() and ThreadReference.forceEarlyReturn deal with JDWP OPAQUE_FRAME error. Before virtual threads, OpaqueFrameException did not exist and these API always threw NativeMethodException when JDWP OPAQUE_FRAME error was returned. For virtual threads OpaqueFrameException was added to handle the case where a virtual thread was not suspended at an event, so the JDI implementation was updated to throw OpaqueFrameException if it detected that a native method was not the cause. It turns out however that JVMTI (and therefore JDWP) can return OPAQUE_FRAME error for reasons other than a native method or the special virtual thread case, and for platform threads we were incorrectly throwing NativeMethodException in these cases. This PR fixes that. For platform threads we now only throw NativeMethodException if a native method is detected, and otherwise throw OpaqueFrameException. The spec language is also being cleaned up to better align with JVMTI. Rather than calling out all the reasons for OpaqueFrameException, a more generic explanation is given. This is somewhat of a preliminary PR so I can get some feedback. I still need to do a CR and complete testing. ------------- Commit messages: - fix OpaqueFrameException related issues Changes: https://git.openjdk.org/jdk/pull/26335/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26335&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309400 Stats: 35 lines in 3 files changed: 5 ins; 9 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/26335.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26335/head:pull/26335 PR: https://git.openjdk.org/jdk/pull/26335 From lmesnik at openjdk.org Tue Jul 15 23:37:55 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 15 Jul 2025 23:37:55 GMT Subject: RFR: 8362203: assert(state == nullptr || state->get_thread_oop() != nullptr) failed: incomplete state [v3] In-Reply-To: References: Message-ID: > The problem happens if post_early_vm_start is triggered. > The fix is to complete initialization once threadObj become available. > > I'vent observed that recompute_enable and hitting assertion might happens before this step. However it might be makes sense to check state in assertion if needed. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: fixed test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26303/files - new: https://git.openjdk.org/jdk/pull/26303/files/a8d5e277..739b0c1c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26303&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26303&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26303/head:pull/26303 PR: https://git.openjdk.org/jdk/pull/26303 From lmesnik at openjdk.org Tue Jul 15 23:41:39 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 15 Jul 2025 23:41:39 GMT Subject: RFR: 8362203: assert(state == nullptr || state->get_thread_oop() != nullptr) failed: incomplete state [v2] In-Reply-To: <09hGHb4ZK7YXxHJF1qCin5x01CD9opJ4_0rPHOU9qOA=.c291a820-6850-4bca-90bb-dbf507c9dc28@github.com> References: <09hGHb4ZK7YXxHJF1qCin5x01CD9opJ4_0rPHOU9qOA=.c291a820-6850-4bca-90bb-dbf507c9dc28@github.com> Message-ID: On Tue, 15 Jul 2025 18:40:14 GMT, Alex Menkov wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> simplified the update > > test/hotspot/jtreg/serviceability/jvmti/StartPhase/AllowedFunctions/AllowedFunctions.java line 32: > >> 30: * @run main/othervm/native -agentlib:AllowedFunctions AllowedFunctions >> 31: * @run main/othervm/native -agentlib:AllowedFunctions=with_early_vmstart AllowedFunctions >> 32: * @run main/othervm/native -agentlib:AllowedFunctions=with_early_vmstart -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n AllowedFunctions > > Do I understand correctly this test case reproduces the issue? > - there is extra space before `-Xrunjdwp` > - would be better to use automatic port (address=0) to avoid "port in use" > - need to update (c) years in the file Thanks, I updated port, indentation and years. Yes, it is the testcase reproducing the issue. It provokes asserition described in the issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26303#discussion_r2208900621 From cjplummer at openjdk.org Tue Jul 15 23:45:38 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 15 Jul 2025 23:45:38 GMT Subject: RFR: 8362304: Fix JDWP spec w.r.t. OPAQUE_FRAME and INVALID_SLOT errors In-Reply-To: <7AfNhcIuQyu2_RsHWcqupjsQ8WnT_eJRvnfI4seyCnQ=.55dfbd37-d226-4ee9-a53f-ee4a3b611a09@github.com> References: <7AfNhcIuQyu2_RsHWcqupjsQ8WnT_eJRvnfI4seyCnQ=.55dfbd37-d226-4ee9-a53f-ee4a3b611a09@github.com> Message-ID: <0TP1mAGnEjOnrVMKm8MKq6C72wCXw2HpIawKs_xJOAY=.847868d6-9692-44c3-8a71-84c50efac1b5@github.com> On Tue, 15 Jul 2025 22:50:00 GMT, Chris Plummer wrote: > StackFrame.SetValues, StackFrame.GetValues, ThreadReference.PopFrames, and ThreadReference.ForceEarlyReturn all need updated language related to OPAQUE_FRAME error. > > (1) The spec for JVMTI says the following for GetLocalsXXX and SetLocalsXXX > > The implementation is unable to set the frame locals > (e.g. the frame at depth is executing a native method). > > However, the JDWP StackFrame.SetValues and GetValues commands only mention OPAQUE_FRAME for SetValues when not called for the topmost frame of a virtual thread suspended at an event. I don't think there is anything to prevent OPAQUE_FRAME due to the thread being native or some other reason as mentioned in the JVMTI spec. The JDWP spec should be updated to reflect this. > > (1) The spec for JVMTI says the following for PopFrame and ForceEarlyReturn: > > The implementation is unable to force the current frame to return > (e.g. current frame is executing a native method). > > However, the JDWP ThreadReference.PopFrames, and ThreadReference.ForceEarlyReturn commands only mention OPAQUE_FRAME when this commands are not called for the topmost frame of a virtual thread suspended at an event. I don't think there is anything to prevent OPAQUE_FRAME due to the thread being native or some other reason as mentioned in the JVMTI spec. The JDWP spec should be updated to reflect this. > > (3) Another issue is that INVALID_SLOT is missing in the JDWP spec for SetValues, but is there for GetValues. It should be mentioned for both commands. Ping. just triggering first email to serviceability-dev. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26336#issuecomment-3076084500 From amenkov at openjdk.org Wed Jul 16 00:01:41 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 16 Jul 2025 00:01:41 GMT Subject: RFR: 8362203: assert(state == nullptr || state->get_thread_oop() != nullptr) failed: incomplete state [v3] In-Reply-To: References: Message-ID: On Tue, 15 Jul 2025 23:37:55 GMT, Leonid Mesnik wrote: >> The problem happens if post_early_vm_start is triggered. >> The fix is to complete initialization once threadObj become available. >> >> I'vent observed that recompute_enable and hitting assertion might happens before this step. However it might be makes sense to check state in assertion if needed. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fixed test Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26303#pullrequestreview-3022656765 From amenkov at openjdk.org Wed Jul 16 00:30:47 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 16 Jul 2025 00:30:47 GMT Subject: RFR: 8309400: JDI spec needs to clarify when OpaqueFrameException and NativeMethodException are thrown In-Reply-To: References: Message-ID: On Tue, 15 Jul 2025 22:07:40 GMT, Chris Plummer wrote: > Fix how ThreadReference.popFrame() and ThreadReference.forceEarlyReturn deal with JDWP OPAQUE_FRAME error. > > Before virtual threads, OpaqueFrameException did not exist and these API always threw NativeMethodException when JDWP OPAQUE_FRAME error was returned. For virtual threads OpaqueFrameException was added to handle the case where a virtual thread was not suspended at an event, so the JDI implementation was updated to throw OpaqueFrameException if it detected that a native method was not the cause. It turns out however that JVMTI (and therefore JDWP) can return OPAQUE_FRAME error for reasons other than a native method or the special virtual thread case, and for platform threads we were incorrectly throwing NativeMethodException in these cases. This PR fixes that. For platform threads we now only throw NativeMethodException if a native method is detected, and otherwise throw OpaqueFrameException. > > The spec language is also being cleaned up to better align with JVMTI. Rather than calling out all the reasons for OpaqueFrameException, a more generic explanation is given. > > This is somewhat of a preliminary PR so I can get some feedback. I still need to do a CR and complete testing. It looks good. I added cleanup suggestion in the implementation src/jdk.jdi/share/classes/com/sun/tools/jdi/StackFrameImpl.java line 401: > 399: // previous frame is native, in which case we throw NativeMethodException > 400: for (int i = 0; i < 2; i++) { > 401: StackFrameImpl sf; There is nothing implementation-specific here. I'd suggest to: - `StackFrameImpl` -> `StackFrame`; - `MethodImpl` -> `Method`; - remove `validateStackFrame` at line 408 ('MethodImpl.location()' calls it) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26335#issuecomment-3076343535 PR Review Comment: https://git.openjdk.org/jdk/pull/26335#discussion_r2208948088 From cjplummer at openjdk.org Wed Jul 16 01:33:44 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 16 Jul 2025 01:33:44 GMT Subject: RFR: 8309400: JDI spec needs to clarify when OpaqueFrameException and NativeMethodException are thrown In-Reply-To: References: Message-ID: On Wed, 16 Jul 2025 00:26:16 GMT, Alex Menkov wrote: >> Fix how ThreadReference.popFrame() and ThreadReference.forceEarlyReturn deal with JDWP OPAQUE_FRAME error. >> >> Before virtual threads, OpaqueFrameException did not exist and these API always threw NativeMethodException when JDWP OPAQUE_FRAME error was returned. For virtual threads OpaqueFrameException was added to handle the case where a virtual thread was not suspended at an event, so the JDI implementation was updated to throw OpaqueFrameException if it detected that a native method was not the cause. It turns out however that JVMTI (and therefore JDWP) can return OPAQUE_FRAME error for reasons other than a native method or the special virtual thread case, and for platform threads we were incorrectly throwing NativeMethodException in these cases. This PR fixes that. For platform threads we now only throw NativeMethodException if a native method is detected, and otherwise throw OpaqueFrameException. >> >> The spec language is also being cleaned up to better align with JVMTI. Rather than calling out all the reasons for OpaqueFrameException, a more generic explanation is given. >> >> This is somewhat of a preliminary PR so I can get some feedback. I still need to do a CR and complete testing. > > src/jdk.jdi/share/classes/com/sun/tools/jdi/StackFrameImpl.java line 401: > >> 399: // previous frame is native, in which case we throw NativeMethodException >> 400: for (int i = 0; i < 2; i++) { >> 401: StackFrameImpl sf; > > There is nothing implementation-specific here. > I'd suggest to: > - `StackFrameImpl` -> `StackFrame`; > - `MethodImpl` -> `Method`; > - remove `validateStackFrame` at line 408 ('MethodImpl.location()' calls it) Are you suggesting renaming the classes? This is a pretty conventional naming when you have classes implementing a spec defined in an interface class. There are a lot more than just StackFrame and Method that are doing this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26335#discussion_r2209018611 From amenkov at openjdk.org Wed Jul 16 01:48:41 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 16 Jul 2025 01:48:41 GMT Subject: RFR: 8309400: JDI spec needs to clarify when OpaqueFrameException and NativeMethodException are thrown In-Reply-To: References: Message-ID: On Tue, 15 Jul 2025 22:07:40 GMT, Chris Plummer wrote: > Fix how ThreadReference.popFrame() and ThreadReference.forceEarlyReturn deal with JDWP OPAQUE_FRAME error. > > Before virtual threads, OpaqueFrameException did not exist and these API always threw NativeMethodException when JDWP OPAQUE_FRAME error was returned. For virtual threads OpaqueFrameException was added to handle the case where a virtual thread was not suspended at an event, so the JDI implementation was updated to throw OpaqueFrameException if it detected that a native method was not the cause. It turns out however that JVMTI (and therefore JDWP) can return OPAQUE_FRAME error for reasons other than a native method or the special virtual thread case, and for platform threads we were incorrectly throwing NativeMethodException in these cases. This PR fixes that. For platform threads we now only throw NativeMethodException if a native method is detected, and otherwise throw OpaqueFrameException. > > The spec language is also being cleaned up to better align with JVMTI. Rather than calling out all the reasons for OpaqueFrameException, a more generic explanation is given. > > This is somewhat of a preliminary PR so I can get some feedback. I still need to do a CR and complete testing. src/jdk.jdi/share/classes/com/sun/tools/jdi/StackFrameImpl.java line 412: > 410: if (meth.isNative()) { > 411: throw new NativeMethodException(); > 412: } > Are you suggesting renaming the classes? No, I mean Suggestion: for (int i = 0; i < 2; i++) { StackFrame sf; try { sf = thread.frame(i); } catch (IndexOutOfBoundsException e) { // This should never happen, but we need to check for it. break; } Method meth = sf.location().method(); if (meth.isNative()) { throw new NativeMethodException(); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26335#discussion_r2209033573 From cjplummer at openjdk.org Wed Jul 16 02:15:38 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 16 Jul 2025 02:15:38 GMT Subject: RFR: 8309400: JDI spec needs to clarify when OpaqueFrameException and NativeMethodException are thrown In-Reply-To: References: Message-ID: On Wed, 16 Jul 2025 01:46:29 GMT, Alex Menkov wrote: >> Fix how ThreadReference.popFrame() and ThreadReference.forceEarlyReturn deal with JDWP OPAQUE_FRAME error. >> >> Before virtual threads, OpaqueFrameException did not exist and these API always threw NativeMethodException when JDWP OPAQUE_FRAME error was returned. For virtual threads OpaqueFrameException was added to handle the case where a virtual thread was not suspended at an event, so the JDI implementation was updated to throw OpaqueFrameException if it detected that a native method was not the cause. It turns out however that JVMTI (and therefore JDWP) can return OPAQUE_FRAME error for reasons other than a native method or the special virtual thread case, and for platform threads we were incorrectly throwing NativeMethodException in these cases. This PR fixes that. For platform threads we now only throw NativeMethodException if a native method is detected, and otherwise throw OpaqueFrameException. >> >> The spec language is also being cleaned up to better align with JVMTI. Rather than calling out all the reasons for OpaqueFrameException, a more generic explanation is given. >> >> This is somewhat of a preliminary PR so I can get some feedback. I still need to do a CR and complete testing. > > src/jdk.jdi/share/classes/com/sun/tools/jdi/StackFrameImpl.java line 412: > >> 410: if (meth.isNative()) { >> 411: throw new NativeMethodException(); >> 412: } > >> Are you suggesting renaming the classes? > > No, I mean > > Suggestion: > > for (int i = 0; i < 2; i++) { > StackFrame sf; > try { > sf = thread.frame(i); > } catch (IndexOutOfBoundsException e) { > // This should never happen, but we need to check for it. > break; > } > Method meth = sf.location().method(); > if (meth.isNative()) { > throw new NativeMethodException(); > } Ok. I see now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26335#discussion_r2209062136 From cjplummer at openjdk.org Wed Jul 16 03:32:34 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 16 Jul 2025 03:32:34 GMT Subject: RFR: 8309400: JDI spec needs to clarify when OpaqueFrameException and NativeMethodException are thrown [v2] In-Reply-To: References: Message-ID: > Fix how ThreadReference.popFrame() and ThreadReference.forceEarlyReturn deal with JDWP OPAQUE_FRAME error. > > Before virtual threads, OpaqueFrameException did not exist and these API always threw NativeMethodException when JDWP OPAQUE_FRAME error was returned. For virtual threads OpaqueFrameException was added to handle the case where a virtual thread was not suspended at an event, so the JDI implementation was updated to throw OpaqueFrameException if it detected that a native method was not the cause. It turns out however that JVMTI (and therefore JDWP) can return OPAQUE_FRAME error for reasons other than a native method or the special virtual thread case, and for platform threads we were incorrectly throwing NativeMethodException in these cases. This PR fixes that. For platform threads we now only throw NativeMethodException if a native method is detected, and otherwise throw OpaqueFrameException. > > The spec language is also being cleaned up to better align with JVMTI. Rather than calling out all the reasons for OpaqueFrameException, a more generic explanation is given. > > This is somewhat of a preliminary PR so I can get some feedback. I still need to do a CR and complete testing. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: update based on feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26335/files - new: https://git.openjdk.org/jdk/pull/26335/files/5a079346..05cce179 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26335&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26335&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26335.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26335/head:pull/26335 PR: https://git.openjdk.org/jdk/pull/26335 From rrich at openjdk.org Wed Jul 16 06:14:49 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Wed, 16 Jul 2025 06:14:49 GMT Subject: RFR: 8361827: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java throws OutOfMemoryError In-Reply-To: References: Message-ID: <_qaqs7HYnHRbw45zD0t9HsU6vFaOOzVKSz_cgpFFeLg=.2042ff93-cc48-4506-aaf5-5ab14acf802a@github.com> On Sat, 12 Jul 2025 06:10:31 GMT, Richard Reingruber wrote: > This pr makes sure to call System.gc() before each test in UnmountedVThreadNativeMethodAtTop.java > > The intention is to get rid of unreachable objects representing loaded heap dumps from previous tests. > > This prevents OutOfMemoryErrors. Parsing the smaller dumps is faster too. > > The PR also includes a reproducer for convenient testing of the pr. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26278#issuecomment-3077005624 From rrich at openjdk.org Wed Jul 16 06:14:50 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Wed, 16 Jul 2025 06:14:50 GMT Subject: Integrated: 8361827: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java throws OutOfMemoryError In-Reply-To: References: Message-ID: On Sat, 12 Jul 2025 06:10:31 GMT, Richard Reingruber wrote: > This pr makes sure to call System.gc() before each test in UnmountedVThreadNativeMethodAtTop.java > > The intention is to get rid of unreachable objects representing loaded heap dumps from previous tests. > > This prevents OutOfMemoryErrors. Parsing the smaller dumps is faster too. > > The PR also includes a reproducer for convenient testing of the pr. This pull request has now been integrated. Changeset: cbb3d23e Author: Richard Reingruber URL: https://git.openjdk.org/jdk/commit/cbb3d23e19a8a893bf2fbda03e7bda4f4b7a59a6 Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod 8361827: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java throws OutOfMemoryError Reviewed-by: clanger, syan ------------- PR: https://git.openjdk.org/jdk/pull/26278 From syan at openjdk.org Wed Jul 16 06:32:24 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 16 Jul 2025 06:32:24 GMT Subject: [jdk25] RFR: 8361827: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java throws OutOfMemoryError Message-ID: Hi all, This pull request contains a backport of commit [cbb3d23e](https://github.com/openjdk/jdk/commit/cbb3d23e19a8a893bf2fbda03e7bda4f4b7a59a6) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to jdk25. Test-fix only to improves test performance and stability. Change has been verified locally, no risk. Thanks! ------------- Commit messages: - Backport cbb3d23e19a8a893bf2fbda03e7bda4f4b7a59a6 Changes: https://git.openjdk.org/jdk/pull/26343/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26343&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361827 Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26343.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26343/head:pull/26343 PR: https://git.openjdk.org/jdk/pull/26343 From rrich at openjdk.org Wed Jul 16 06:39:43 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Wed, 16 Jul 2025 06:39:43 GMT Subject: [jdk25] RFR: 8361827: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java throws OutOfMemoryError In-Reply-To: References: Message-ID: On Wed, 16 Jul 2025 06:24:16 GMT, SendaoYan wrote: > Hi all, > > This pull request contains a backport of commit [cbb3d23e](https://github.com/openjdk/jdk/commit/cbb3d23e19a8a893bf2fbda03e7bda4f4b7a59a6) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to jdk25. > > > Test-fix only to improves test performance and stability. Change has been verified locally, no risk. > > Thanks! Marked as reviewed by rrich (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26343#pullrequestreview-3023370065 From mbaesken at openjdk.org Wed Jul 16 14:34:41 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 16 Jul 2025 14:34:41 GMT Subject: RFR: 8349638: Build libjdwp with SIZE optimization In-Reply-To: References: Message-ID: On Wed, 9 Apr 2025 20:34:42 GMT, Chris Plummer wrote: > > Wait, `LOW` is `-O2`? ? I thought it was like no optimization at all. I'm sooo confused with these levels. So maybe going from `LOW` to `SIZE` will actually lose more optimization than I thought. _sigh_ > > -Os is the same as -O2 minus some optimizations that increase footprint. > > https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html > > -O3 mostly adds more serious footprint increasing optimizations like loop unrolling. I've seen a number of warnings that suggest in some cases the larger code can reduce performance, so you may be best off with -O2 or -Os for best performance. So should we give SIZE opt a try now with JDK26 (for libjdwp) ? Unfortunately we do not have benchmarks for libjdwp (or are there any?) . But this has not stopped us from updating compiler versions etc. .... ------------- PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-3078868634 From mbaesken at openjdk.org Wed Jul 16 14:34:41 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 16 Jul 2025 14:34:41 GMT Subject: RFR: 8349638: Build libjdwp with SIZE optimization In-Reply-To: References: Message-ID: <11N7SC1bEtYE0Zo-81qS8oJ1HpA1CbuzYRZvIOQGbd4=.4f0c0eb5-7e95-4261-a188-8920eeed483c@github.com> On Wed, 21 May 2025 09:18:56 GMT, Magnus Ihse Bursie wrote: > So if you think you want to do this library by library, then do so, and if so keep this PR A lib by lib approach is probably easier to discuss/review. Changing all (or most) JDK native libs at once will probably make some people unhappy (and it is harder to oversee everything). ------------- PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-3078875695 From lmesnik at openjdk.org Wed Jul 16 18:03:46 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 16 Jul 2025 18:03:46 GMT Subject: [jdk25] RFR: 8361827: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java throws OutOfMemoryError In-Reply-To: References: Message-ID: On Wed, 16 Jul 2025 06:24:16 GMT, SendaoYan wrote: > Hi all, > > This pull request contains a backport of commit [cbb3d23e](https://github.com/openjdk/jdk/commit/cbb3d23e19a8a893bf2fbda03e7bda4f4b7a59a6) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to jdk25. > > > Test-fix only to improves test performance and stability. Change has been verified locally, no risk. > > Thanks! Changes requested by lmesnik (Reviewer). test/hotspot/jtreg/serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java line 59: > 57: @BeforeEach > 58: void doGC() { > 59: System.gc(); The Systen.gc() might not trigger full GC. While not tjust o restrict heap for this test? 256M should be enough. ------------- PR Review: https://git.openjdk.org/jdk/pull/26343#pullrequestreview-3026212575 PR Review Comment: https://git.openjdk.org/jdk/pull/26343#discussion_r2211166978 From amenkov at openjdk.org Wed Jul 16 19:27:40 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 16 Jul 2025 19:27:40 GMT Subject: RFR: 8309400: JDI spec needs to clarify when OpaqueFrameException and NativeMethodException are thrown [v2] In-Reply-To: References: Message-ID: On Wed, 16 Jul 2025 03:32:34 GMT, Chris Plummer wrote: >> Fix how ThreadReference.popFrame() and ThreadReference.forceEarlyReturn deal with JDWP OPAQUE_FRAME error. >> >> Before virtual threads, OpaqueFrameException did not exist and these API always threw NativeMethodException when JDWP OPAQUE_FRAME error was returned. For virtual threads OpaqueFrameException was added to handle the case where a virtual thread was not suspended at an event, so the JDI implementation was updated to throw OpaqueFrameException if it detected that a native method was not the cause. It turns out however that JVMTI (and therefore JDWP) can return OPAQUE_FRAME error for reasons other than a native method or the special virtual thread case, and for platform threads we were incorrectly throwing NativeMethodException in these cases. This PR fixes that. For platform threads we now only throw NativeMethodException if a native method is detected, and otherwise throw OpaqueFrameException. >> >> The spec language is also being cleaned up to better align with JVMTI. Rather than calling out all the reasons for OpaqueFrameException, a more generic explanation is given. >> >> This is somewhat of a preliminary PR so I can get some feedback. I still need to do a CR and complete testing. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > update based on feedback Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26335#pullrequestreview-3026506747 From amenkov at openjdk.org Wed Jul 16 22:21:22 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 16 Jul 2025 22:21:22 GMT Subject: RFR: 8361751: Test sun/tools/jcmd/TestJcmdSanity.java timed out on Windows Message-ID: Tests which run serviceability tools to attach to the main test process can get deadlock with streaming output (see #24672 ) The fix disables attach streaming output for tests in jdk/sun/tools/jcmd Testing: tier6, tier7 ------------- Commit messages: - fix Changes: https://git.openjdk.org/jdk/pull/26358/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26358&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361751 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26358.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26358/head:pull/26358 PR: https://git.openjdk.org/jdk/pull/26358 From cjplummer at openjdk.org Wed Jul 16 22:28:47 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 16 Jul 2025 22:28:47 GMT Subject: RFR: 8361751: Test sun/tools/jcmd/TestJcmdSanity.java timed out on Windows In-Reply-To: References: Message-ID: On Wed, 16 Jul 2025 20:44:05 GMT, Alex Menkov wrote: > Tests which run serviceability tools to attach to the main test process can get deadlock with streaming output (see #24672 ) > The fix disables attach streaming output for tests in jdk/sun/tools/jcmd > > Testing: tier6, tier7 Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26358#pullrequestreview-3027080003 From sspitsyn at openjdk.org Thu Jul 17 01:33:54 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 17 Jul 2025 01:33:54 GMT Subject: Integrated: 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 spec sections: > - `PopFrame` > - `NotifyFramePop` > - `ForceEarlyReturn` > - `GetLocal` > - `SetLocal` > - general description of the `JVMTI_ERROR_OPAQUE_FRAME` error code > > 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 This pull request has now been integrated. Changeset: a65d9532 Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/a65d9532ed454a0f70b1009181a25b23a38ccd4b Stats: 85 lines in 1 file changed: 5 ins; 48 del; 32 mod 8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method Reviewed-by: cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/26111 From dholmes at openjdk.org Thu Jul 17 01:35:47 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 17 Jul 2025 01:35:47 GMT Subject: RFR: 8361751: Test sun/tools/jcmd/TestJcmdSanity.java timed out on Windows In-Reply-To: References: Message-ID: On Wed, 16 Jul 2025 20:44:05 GMT, Alex Menkov wrote: > Tests which run serviceability tools to attach to the main test process can get deadlock with streaming output (see #24672 ) > The fix disables attach streaming output for tests in jdk/sun/tools/jcmd > > Testing: tier6, tier7 Okay, but are there other tests we have missed here? I'm wondering what the value of "streaming output" is when it can lead to deadlocks? Is this just a test problem? Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26358#pullrequestreview-3027416428 From sspitsyn at openjdk.org Thu Jul 17 01:57:32 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 17 Jul 2025 01:57:32 GMT Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired [v6] In-Reply-To: References: Message-ID: > The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27. > > TBD: Need to submit a related CSR. > > There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams: > - Class redefinition/retransformation can impact lambda expressions which are supported with private methods > - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now). > > Testing: > - mach5 tiers 1-6 are good > - may need to run mach5 tiers > 6 Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge - Merge - review: replace RESERVED flag with UNUSED - review: keep right order of the obsoleted VM options - corrected one assert message - 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26232/files - new: https://git.openjdk.org/jdk/pull/26232/files/3900252d..80fc70ec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=04-05 Stats: 16210 lines in 455 files changed: 10361 ins; 3853 del; 1996 mod Patch: https://git.openjdk.org/jdk/pull/26232.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26232/head:pull/26232 PR: https://git.openjdk.org/jdk/pull/26232 From lmesnik at openjdk.org Thu Jul 17 04:11:50 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 17 Jul 2025 04:11:50 GMT Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired [v6] In-Reply-To: References: Message-ID: On Thu, 17 Jul 2025 01:57:32 GMT, Serguei Spitsyn wrote: >> The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27. >> >> TBD: Need to submit a related CSR. >> >> There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams: >> - Class redefinition/retransformation can impact lambda expressions which are supported with private methods >> - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now). >> >> Testing: >> - mach5 tiers 1-6 are good >> - may need to run mach5 tiers > 6 > > Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge > - Merge > - review: replace RESERVED flag with UNUSED > - review: keep right order of the obsoleted VM options > - corrected one assert message > - 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired I commented the only test that seems to be still useful. All other tests are related to add/delete methods. I think it is needed to check if any of remaining tests should be updated to negative tests that verifies correctness of thrown Exception. However, it could be done after final agreement is reached. test/jdk/java/lang/instrument/RedefineMethodInBacktrace.sh line 2: > 1: # > 2: # Copyright (c) 2013, 2024, Oracle and/or its affiliates. All rights reserved. This test is still useful, it is needed to remove method deletion only. However, part of testing with redefined method is still useful. The test checks that old copy of redefined method is not removed. ------------- Changes requested by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26232#pullrequestreview-3027590373 PR Review Comment: https://git.openjdk.org/jdk/pull/26232#discussion_r2212081642 From amitkumar at openjdk.org Thu Jul 17 04:33:01 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 17 Jul 2025 04:33:01 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass [v3] In-Reply-To: References: Message-ID: On Thu, 6 Feb 2025 18:41:12 GMT, Coleen Phillimore wrote: > It might be that you need to add some nop() bytecode or something to generate the code attribute? @coleenp This seems like a valid solution. By the way, can we modify this testcase in OpenJDK or should the OpenJ9 team make the change in their repository. Which one do you suggest ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22116#issuecomment-3082452043 From sspitsyn at openjdk.org Thu Jul 17 07:39:56 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 17 Jul 2025 07:39:56 GMT Subject: RFR: 8362203: assert(state == nullptr || state->get_thread_oop() != nullptr) failed: incomplete state [v3] In-Reply-To: References: Message-ID: On Tue, 15 Jul 2025 23:37:55 GMT, Leonid Mesnik wrote: >> The problem happens if post_early_vm_start is triggered. >> The fix is to complete initialization once threadObj become available. >> >> I'vent observed that recompute_enable and hitting assertion might happens before this step. However it might be makes sense to check state in assertion if needed. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fixed test Thank you for updates! Looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26303#pullrequestreview-3028291409 From rrich at openjdk.org Thu Jul 17 08:07:49 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Thu, 17 Jul 2025 08:07:49 GMT Subject: [jdk25] RFR: 8361827: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java throws OutOfMemoryError In-Reply-To: References: Message-ID: On Wed, 16 Jul 2025 18:00:50 GMT, Leonid Mesnik wrote: > The Systen.gc() might not trigger full GC. Indeed. Might be better to use the Whitebox or start a dedicated VM. > While not tjust o restrict heap for this test? 256M should be enough. This would not help. The tests accumulate heap dumps until OOM. See reproducer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26343#discussion_r2212617511 From rrich at openjdk.org Thu Jul 17 08:24:53 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Thu, 17 Jul 2025 08:24:53 GMT Subject: [jdk25] RFR: 8361827: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java throws OutOfMemoryError In-Reply-To: References: Message-ID: <4jeGbHSi0_wcfwh5OFs93ucP0xxl27ut7JtDHv5xAMc=.6d167da9-0d00-4357-947e-1cc620dde8ba@github.com> On Thu, 17 Jul 2025 08:04:50 GMT, Richard Reingruber wrote: >> test/hotspot/jtreg/serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java line 59: >> >>> 57: @BeforeEach >>> 58: void doGC() { >>> 59: System.gc(); >> >> The Systen.gc() might not trigger full GC. >> >> While not tjust o restrict heap for this test? 256M should be enough. > >> The Systen.gc() might not trigger full GC. > > Indeed. Might be better to use the Whitebox or start a dedicated VM. > >> While not tjust o restrict heap for this test? 256M should be enough. > > This would not help. The tests accumulate heap dumps until OOM. See reproducer. It might not be the perfect solution but it surely reduces the noise in our testing. So let's have this improvement in jdk25. In jdk26 we can change the test to use [WhiteBox::fullGC](https://github.com/openjdk/jdk/blob/18190519e73705281adf3f94d710d000e75b1729/test/lib/jdk/test/whitebox/WhiteBox.java#L561). What do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26343#discussion_r2212657017 From sspitsyn at openjdk.org Thu Jul 17 08:29:49 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 17 Jul 2025 08:29:49 GMT Subject: RFR: 8309400: JDI spec needs to clarify when OpaqueFrameException and NativeMethodException are thrown [v2] In-Reply-To: References: Message-ID: On Wed, 16 Jul 2025 03:32:34 GMT, Chris Plummer wrote: >> Fix how ThreadReference.popFrame() and ThreadReference.forceEarlyReturn deal with JDWP OPAQUE_FRAME error. >> >> Before virtual threads, OpaqueFrameException did not exist and these API always threw NativeMethodException when JDWP OPAQUE_FRAME error was returned. For virtual threads OpaqueFrameException was added to handle the case where a virtual thread was not suspended at an event, so the JDI implementation was updated to throw OpaqueFrameException if it detected that a native method was not the cause. It turns out however that JVMTI (and therefore JDWP) can return OPAQUE_FRAME error for reasons other than a native method or the special virtual thread case, and for platform threads we were incorrectly throwing NativeMethodException in these cases. This PR fixes that. For platform threads we now only throw NativeMethodException if a native method is detected, and otherwise throw OpaqueFrameException. >> >> The spec language is also being cleaned up to better align with JVMTI. Rather than calling out all the reasons for OpaqueFrameException, a more generic explanation is given. >> >> This is somewhat of a preliminary PR so I can get some feedback. I still need to do a CR and complete testing. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > update based on feedback I've posted one concern on the spec updates. Otherwise, it looks okay to me. I guess, a CSR will be filed for this update. I'm not sure what do you mean by CR in the description. Do I understand this right that a potential JDWP spec update we touched out of this PR will be considered separately? src/jdk.jdi/share/classes/com/sun/jdi/ThreadReference.java line 406: > 404: * > 405: * @throws OpaqueFrameException if target VM is unable to pop this frame > 406: * (e.g. a virtual thread is not suspended at an event). Nit: I'm not sure the comment at line 406 is fully correct. The `IncompatibleThreadStateException` will be thrown if a virtual thread is not suspended. So, the `OpaqueFrameException` will be thrown only when a virtual thread is suspended but not at an event. The same concern should apply for the line 488. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26335#pullrequestreview-3028456818 PR Review Comment: https://git.openjdk.org/jdk/pull/26335#discussion_r2212652535 From rrich at openjdk.org Thu Jul 17 10:02:51 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Thu, 17 Jul 2025 10:02:51 GMT Subject: [jdk25] RFR: 8361827: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java throws OutOfMemoryError In-Reply-To: <4jeGbHSi0_wcfwh5OFs93ucP0xxl27ut7JtDHv5xAMc=.6d167da9-0d00-4357-947e-1cc620dde8ba@github.com> References: <4jeGbHSi0_wcfwh5OFs93ucP0xxl27ut7JtDHv5xAMc=.6d167da9-0d00-4357-947e-1cc620dde8ba@github.com> Message-ID: On Thu, 17 Jul 2025 08:21:56 GMT, Richard Reingruber wrote: >>> The Systen.gc() might not trigger full GC. >> >> Indeed. Might be better to use the Whitebox or start a dedicated VM. >> >>> While not tjust o restrict heap for this test? 256M should be enough. >> >> This would not help. The tests accumulate heap dumps until OOM. See reproducer. > > It might not be the perfect solution but it surely reduces the noise in our testing. > So let's have this improvement in jdk25. > In jdk26 we can change the test to use [WhiteBox::fullGC](https://github.com/openjdk/jdk/blob/18190519e73705281adf3f94d710d000e75b1729/test/lib/jdk/test/whitebox/WhiteBox.java#L561). What do you think? I've created a draft pr: https://github.com/openjdk/jdk/pull/26363 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26343#discussion_r2212907841 From sspitsyn at openjdk.org Thu Jul 17 10:17:25 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 17 Jul 2025 10:17:25 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException Message-ID: If JVMTI `StopThread` is done when the thread is in certain various states (but not all states), after the `async` exception is delivered and handled, hotspot leaves the thread's `interrupted` flag set. The end result is the next time the thread does something like `Thread.sleep()`, it will immediately get an `InterruptedException`. The fix is to clear the `interrupted` flag in the `JavaThread::handle_async_exception()` after an `async` pending exception has been set to be thrown with the `set_pending_exception()`. There are a couple of concerns with this fix which would be nice to sort out with reviewers: 1. The proposed fix may clear the interrupt state when it was already set prior to the issuing of the `StopThread()` (this concern was raised by @dholmes-ora in a comment of this JBS issue) 2. The impacted code path is shared between the class `InstallAsyncExceptionHandshakeClosure` used by the JVMTI `StopThread` implementation and the class `ScopedAsyncExceptionHandshakeClosure` used by the `ScopedMemoryAccess` I feel that clearing the `interrupted` flag byt the `JavaThread::handle_async_exception()` is a right thing to do even though it was set before the call to `JavaThread::install_async_exception()`. Also, it has to be done for both `StopThread` and `ScopedMemoryAccess`. The fix also includes minor tweaks of the test `StopThreadTest` to make the issue reproducible with it. Testing: - Mach5 tiers 1-6 are passed - Ran the updated reproducer test `hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest` ------------- Commit messages: - 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException Changes: https://git.openjdk.org/jdk/pull/26365/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26365&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306324 Stats: 7 lines in 2 files changed: 4 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26365.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26365/head:pull/26365 PR: https://git.openjdk.org/jdk/pull/26365 From dholmes at openjdk.org Thu Jul 17 12:15:50 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 17 Jul 2025 12:15:50 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException In-Reply-To: References: Message-ID: On Thu, 17 Jul 2025 10:12:16 GMT, Serguei Spitsyn wrote: > If JVMTI `StopThread` is done when the thread is in certain various states (but not all states), after the `async` exception is delivered and handled, hotspot leaves the thread's `interrupted` flag set. The end result is the next time the thread does something like `Thread.sleep()`, it will immediately get an `InterruptedException`. > > The fix is to clear the `interrupted` flag in the `JavaThread::handle_async_exception()` after an `async` pending exception has been set to be thrown with the `set_pending_exception()`. > > There are a couple of concerns with this fix which would be nice to sort out with reviewers: > 1. The proposed fix may clear the interrupt state when it was already set prior to the issuing of the `StopThread()` (this concern was raised by @dholmes-ora in a comment of this JBS issue) > 2. The impacted code path is shared between the class `InstallAsyncExceptionHandshakeClosure` used by the JVMTI `StopThread` implementation and the class `ScopedAsyncExceptionHandshakeClosure` used by the `ScopedMemoryAccess` > > I feel that clearing the `interrupted` flag byt the `JavaThread::handle_async_exception()` is a right thing to do even though it was set before the call to `JavaThread::install_async_exception()`. Also, it has to be done for both `StopThread` and `ScopedMemoryAccess`. > > The fix also includes minor tweaks of the test `StopThreadTest` to make the issue reproducible with it. > > Testing: > - Mach5 tiers 1-6 are passed > - Ran the updated reproducer test `hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest` I need to dive into the code tomorrow but I can't help think that doing an actual interrupt is not really what is needed, we just need to unpark the thread if it is blocked ... ------------- PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3083837302 From jpai at openjdk.org Thu Jul 17 12:48:53 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 17 Jul 2025 12:48:53 GMT Subject: [jdk25] RFR: 8361869: Tests which call ThreadController should mark as /native In-Reply-To: References: Message-ID: On Sat, 12 Jul 2025 03:50:02 GMT, SendaoYan wrote: > Hi all, > > This pull request contains a backport of commit [3bacf7ea](https://github.com/openjdk/jdk/commit/3bacf7ea85f1e3f5e57fd2d046b98dfafe2c7e18) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by SendaoYan on 12 Jul 2025 and was reviewed by Serguei Spitsyn and Leonid Mesnik. > > Test-fix only, change has been verified locally, no risk. > > Thanks! Marked as reviewed by jpai (Reviewer). This clean, test-only backport to jdk25 looks OK to me. ------------- PR Review: https://git.openjdk.org/jdk/pull/26277#pullrequestreview-3029389439 PR Comment: https://git.openjdk.org/jdk/pull/26277#issuecomment-3083939942 From syan at openjdk.org Thu Jul 17 12:53:55 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 17 Jul 2025 12:53:55 GMT Subject: [jdk25] RFR: 8361869: Tests which call ThreadController should mark as /native In-Reply-To: References: Message-ID: On Thu, 17 Jul 2025 12:45:59 GMT, Jaikiran Pai wrote: > This clean, test-only backport to jdk25 looks OK to me. Thanks for the reviews @jaikiran ------------- PR Comment: https://git.openjdk.org/jdk/pull/26277#issuecomment-3083952545 From syan at openjdk.org Thu Jul 17 12:53:56 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 17 Jul 2025 12:53:56 GMT Subject: [jdk25] Integrated: 8361869: Tests which call ThreadController should mark as /native In-Reply-To: References: Message-ID: On Sat, 12 Jul 2025 03:50:02 GMT, SendaoYan wrote: > Hi all, > > This pull request contains a backport of commit [3bacf7ea](https://github.com/openjdk/jdk/commit/3bacf7ea85f1e3f5e57fd2d046b98dfafe2c7e18) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by SendaoYan on 12 Jul 2025 and was reviewed by Serguei Spitsyn and Leonid Mesnik. > > Test-fix only, change has been verified locally, no risk. > > Thanks! This pull request has now been integrated. Changeset: 5cc7a31b Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/5cc7a31b3f44121553e3412b0f188d7016b35889 Stats: 18 lines in 9 files changed: 0 ins; 0 del; 18 mod 8361869: Tests which call ThreadController should mark as /native Reviewed-by: jpai Backport-of: 3bacf7ea85f1e3f5e57fd2d046b98dfafe2c7e18 ------------- PR: https://git.openjdk.org/jdk/pull/26277 From alanb at openjdk.org Thu Jul 17 14:44:48 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 17 Jul 2025 14:44:48 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException In-Reply-To: References: Message-ID: On Thu, 17 Jul 2025 12:13:22 GMT, David Holmes wrote: > I need to dive into the code tomorrow but I can't help think that doing an actual interrupt is not really what is needed, we just need to unpark the thread if it is blocked ... I think we also need to step back and write down examples of where JVMTI StopThread is useful. The main use-case may be in the debugger where is suspended at a breakpoint and the user wants to throw an exception to exercise some code path and exception handling. So I think it may be less about wakeup. Also if the target thread is in Object.wait then it can't continue until it re-enters the monitor so it's never been guaranteed to wakeup immediately. Although it may be unpalatable, I think we should look at having StopThread fail in these cases. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3084347073 From cjplummer at openjdk.org Thu Jul 17 14:46:49 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 17 Jul 2025 14:46:49 GMT Subject: RFR: 8309400: JDI spec needs to clarify when OpaqueFrameException and NativeMethodException are thrown [v2] In-Reply-To: References: Message-ID: <8URbrJRmAwCZCF6KIJSX__SDGfYvUgK4rLbmiPUu1o4=.67aad1c1-1072-4137-8d02-a0f25bee53af@github.com> On Thu, 17 Jul 2025 08:26:54 GMT, Serguei Spitsyn wrote: > I've posted one concern on the spec updates. Otherwise, it looks okay to me. I guess, a CSR will be filed for this update. I'm not sure what do you mean by CR in the description. Do I understand this right that a potential JDWP spec update we touched out of this PR will be considered separately? I meant CSR. I'll fix that. JDWP will be updated by #26336. > src/jdk.jdi/share/classes/com/sun/jdi/ThreadReference.java line 406: > >> 404: * >> 405: * @throws OpaqueFrameException if target VM is unable to pop this frame >> 406: * (e.g. a virtual thread is not suspended at an event). > > Nit: I'm not sure the comment at line 406 is fully correct. The `IncompatibleThreadStateException` will be thrown if a virtual thread is not suspended. So, the `OpaqueFrameException` will be thrown only when a virtual thread is suspended but not at an event. The same concern should apply for the line 488. We are talking about the difference between "not suspended" vs "not suspended at an event". The former results in IncompatibleThreadStateException. For the latter I felt the wording implied it was suspended, but not at an event. Maybe it should just say "suspended, but not at an event"? The JVMTI spec does not have this issue because it doesn't mention virtual threads as part of the OPAQUE_ERROR description. It instead mentions the method being native as an example of what can cause OPAQUE_ERROR. We can't do that here because a native method results in NativeMethodException, not OpaqueFrameException. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26335#issuecomment-3084355508 PR Review Comment: https://git.openjdk.org/jdk/pull/26335#discussion_r2213550664 From lmesnik at openjdk.org Thu Jul 17 16:21:49 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 17 Jul 2025 16:21:49 GMT Subject: [jdk25] RFR: 8361827: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java throws OutOfMemoryError In-Reply-To: References: Message-ID: On Wed, 16 Jul 2025 06:24:16 GMT, SendaoYan wrote: > Hi all, > > This pull request contains a backport of commit [cbb3d23e](https://github.com/openjdk/jdk/commit/cbb3d23e19a8a893bf2fbda03e7bda4f4b7a59a6) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to jdk25. > > > Test-fix only to improves test performance and stability. Change has been verified locally, no risk. > > Thanks! Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26343#pullrequestreview-3030208490 From lmesnik at openjdk.org Thu Jul 17 16:21:49 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 17 Jul 2025 16:21:49 GMT Subject: [jdk25] RFR: 8361827: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java throws OutOfMemoryError In-Reply-To: References: <4jeGbHSi0_wcfwh5OFs93ucP0xxl27ut7JtDHv5xAMc=.6d167da9-0d00-4357-947e-1cc620dde8ba@github.com> Message-ID: On Thu, 17 Jul 2025 10:00:39 GMT, Richard Reingruber wrote: >> It might not be the perfect solution but it surely reduces the noise in our testing. >> So let's have this improvement in jdk25. >> In jdk26 we can change the test to use [WhiteBox::fullGC](https://github.com/openjdk/jdk/blob/18190519e73705281adf3f94d710d000e75b1729/test/lib/jdk/test/whitebox/WhiteBox.java#L561). What do you think? > > I've created a draft pr: https://github.com/openjdk/jdk/pull/26363 That's fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26343#discussion_r2213781549 From lmesnik at openjdk.org Thu Jul 17 16:28:57 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 17 Jul 2025 16:28:57 GMT Subject: RFR: 8362203: assert(state == nullptr || state->get_thread_oop() != nullptr) failed: incomplete state [v3] In-Reply-To: References: Message-ID: <0Ln5DfuXrOVhzTpTF_eNcYACNnubv9i-DIYRO-P_KJQ=.13b4c837-3547-4057-b3b0-efb5c8765a94@github.com> On Thu, 17 Jul 2025 07:36:58 GMT, Serguei Spitsyn wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed test > > Thank you for updates! Looks good. @sspitsyn, @alexmenkov Thank you for review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26303#issuecomment-3084679519 From lmesnik at openjdk.org Thu Jul 17 16:28:58 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 17 Jul 2025 16:28:58 GMT Subject: Integrated: 8362203: assert(state == nullptr || state->get_thread_oop() != nullptr) failed: incomplete state In-Reply-To: References: Message-ID: On Mon, 14 Jul 2025 23:42:03 GMT, Leonid Mesnik wrote: > The problem happens if post_early_vm_start is triggered. > The fix is to complete initialization once threadObj become available. > > I'vent observed that recompute_enable and hitting assertion might happens before this step. However it might be makes sense to check state in assertion if needed. This pull request has now been integrated. Changeset: bd55d7a4 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/bd55d7a49514da9fa4de0d4a372956e21deab4d2 Stats: 20 lines in 4 files changed: 17 ins; 1 del; 2 mod 8362203: assert(state == nullptr || state->get_thread_oop() != nullptr) failed: incomplete state Reviewed-by: sspitsyn, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/26303 From pchilanomate at openjdk.org Thu Jul 17 16:37:50 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 17 Jul 2025 16:37:50 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException In-Reply-To: References: Message-ID: On Thu, 17 Jul 2025 10:12:16 GMT, Serguei Spitsyn wrote: > If JVMTI `StopThread` is done when the thread is in certain various states (but not all states), after the `async` exception is delivered and handled, hotspot leaves the thread's `interrupted` flag set. The end result is the next time the thread does something like `Thread.sleep()`, it will immediately get an `InterruptedException`. > > The fix is to clear the `interrupted` flag in the `JavaThread::handle_async_exception()` after an `async` pending exception has been set to be thrown with the `set_pending_exception()`. > > There are a couple of concerns with this fix which would be nice to sort out with reviewers: > 1. The proposed fix may clear the interrupt state when it was already set prior to the issuing of the `StopThread()` (this concern was raised by @dholmes-ora in a comment of this JBS issue) > 2. The impacted code path is shared between the class `InstallAsyncExceptionHandshakeClosure` used by the JVMTI `StopThread` implementation and the class `ScopedAsyncExceptionHandshakeClosure` used by the `ScopedMemoryAccess` > > I feel that clearing the `interrupted` flag byt the `JavaThread::handle_async_exception()` is a right thing to do even though it was set before the call to `JavaThread::install_async_exception()`. Also, it has to be done for both `StopThread` and `ScopedMemoryAccess`. > > The fix also includes minor tweaks of the test `StopThreadTest` to make the issue reproducible with it. > > Testing: > - Mach5 tiers 1-6 are passed > - Ran the updated reproducer test `hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest` I also don?t see the purpose of setting the interrupted flag if all we want is for the target to wake up if it?s in one of the blocking calls. From the 3 cases in `JavaThread::interrupt()`, the only one where I see setting that flag is needed is for `Thread.sleep` because we check it to bail out, otherwise we would just keep sleeping for the remaining time. But maybe we could also add a `has_async_exception_condition()` check to bailout. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3084708506 From amenkov at openjdk.org Thu Jul 17 18:54:48 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 17 Jul 2025 18:54:48 GMT Subject: RFR: 8361751: Test sun/tools/jcmd/TestJcmdSanity.java timed out on Windows In-Reply-To: References: Message-ID: On Thu, 17 Jul 2025 01:32:52 GMT, David Holmes wrote: > Okay, but are there other tests we have missed here? I'd say this tests was missed in https://bugs.openjdk.org/browse/JDK-8354461 fix. > > I'm wondering what the value of "streaming output" is when it can lead to deadlocks? Is this just a test problem? "Streaming output" means attach operation output is not buffered, but is sent to the client while the handler produce it. It's useful in real cases, when user runs jcmd or other tool against external target VM (see https://bugs.openjdk.org/browse/JDK-8319055 and related issues). In tests we often use scenarios when test attaches to itself or like in this case use attach tool to attach to the test process. And we can get deadlock because producer (operation handler, often executed in safepoint) and consumer (test reads redirected output of the tool) are executed in the same process. It's just test problem (to reproduce real scenario tests should run target VM as a separate process) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26358#issuecomment-3085091259 From cjplummer at openjdk.org Thu Jul 17 20:15:56 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 17 Jul 2025 20:15:56 GMT Subject: RFR: 8349638: Build libjdwp with SIZE optimization In-Reply-To: References: Message-ID: On Wed, 16 Jul 2025 14:30:22 GMT, Matthias Baesken wrote: > So should we give SIZE opt a try now with JDK26 (for libjdwp) ? > Unfortunately we do not have benchmarks for libjdwp (or are there any?) . > But this has not stopped us from updating compiler versions etc. .... I'm still not sure whether or not this is a good idea. For benchmarking, you can try running large test suites like nsk/jdi, but I think you'll find the times vary quite a bit. I'd pay more attention to cpu time than wall clock time. When debugging libjdwp, I often find that it does quite a bit of inlining of non-trivial functions, even with fastdebug builds. I think for the most part this is done when there is only one call site. Some of this will probably go away with -Os, although I won't miss it since I frequently needs to do builds where I make functions extern instead of static so they are not inlined and stack traces are more accurate. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-3085338361 From sspitsyn at openjdk.org Thu Jul 17 22:52:46 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 17 Jul 2025 22:52:46 GMT Subject: RFR: 8309400: JDI spec needs to clarify when OpaqueFrameException and NativeMethodException are thrown [v2] In-Reply-To: <8URbrJRmAwCZCF6KIJSX__SDGfYvUgK4rLbmiPUu1o4=.67aad1c1-1072-4137-8d02-a0f25bee53af@github.com> References: <8URbrJRmAwCZCF6KIJSX__SDGfYvUgK4rLbmiPUu1o4=.67aad1c1-1072-4137-8d02-a0f25bee53af@github.com> Message-ID: <1OfpIrtETyGlbSGlHo0Pib5E6CLHmMLdtY9Xe2mq-yI=.e93febe4-cbdf-49d1-b8c1-ce0a81b49ccf@github.com> On Thu, 17 Jul 2025 14:42:24 GMT, Chris Plummer wrote: > Maybe it should just say "suspended, but not at an event"? Yes, this would make it clear. And yes, the JVMTI vs JDI spec difference is reasonable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26335#discussion_r2214445484 From sspitsyn at openjdk.org Thu Jul 17 23:05:48 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 17 Jul 2025 23:05:48 GMT Subject: RFR: 8362304: Fix JDWP spec w.r.t. OPAQUE_FRAME and INVALID_SLOT errors In-Reply-To: <7AfNhcIuQyu2_RsHWcqupjsQ8WnT_eJRvnfI4seyCnQ=.55dfbd37-d226-4ee9-a53f-ee4a3b611a09@github.com> References: <7AfNhcIuQyu2_RsHWcqupjsQ8WnT_eJRvnfI4seyCnQ=.55dfbd37-d226-4ee9-a53f-ee4a3b611a09@github.com> Message-ID: On Tue, 15 Jul 2025 22:50:00 GMT, Chris Plummer wrote: > StackFrame.SetValues, StackFrame.GetValues, ThreadReference.PopFrames, and ThreadReference.ForceEarlyReturn all need updated language related to OPAQUE_FRAME error. > > (1) The spec for JVMTI says the following for GetLocalsXXX and SetLocalsXXX > > The implementation is unable to set the frame locals > (e.g. the frame at depth is executing a native method). > > However, the JDWP StackFrame.SetValues and GetValues commands only mention OPAQUE_FRAME for SetValues when not called for the topmost frame of a virtual thread suspended at an event. I don't think there is anything to prevent OPAQUE_FRAME due to the thread being native or some other reason as mentioned in the JVMTI spec. The JDWP spec should be updated to reflect this. > > (1) The spec for JVMTI says the following for PopFrame and ForceEarlyReturn: > > The implementation is unable to force the current frame to return > (e.g. current frame is executing a native method). > > However, the JDWP ThreadReference.PopFrames, and ThreadReference.ForceEarlyReturn commands only mention OPAQUE_FRAME when this commands are not called for the topmost frame of a virtual thread suspended at an event. I don't think there is anything to prevent OPAQUE_FRAME due to the thread being native or some other reason as mentioned in the JVMTI spec. The JDWP spec should be updated to reflect this. > > (3) Another issue is that INVALID_SLOT is missing in the JDWP spec for SetValues, but is there for GetValues. It should be mentioned for both commands. This looks good. Also, I'll wait for CSR to review. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26336#pullrequestreview-3031242406 From sspitsyn at openjdk.org Thu Jul 17 23:07:47 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 17 Jul 2025 23:07:47 GMT Subject: RFR: 8309400: JDI spec needs to clarify when OpaqueFrameException and NativeMethodException are thrown [v2] In-Reply-To: References: Message-ID: On Wed, 16 Jul 2025 03:32:34 GMT, Chris Plummer wrote: >> Fix how ThreadReference.popFrame() and ThreadReference.forceEarlyReturn deal with JDWP OPAQUE_FRAME error. >> >> Before virtual threads, OpaqueFrameException did not exist and these API always threw NativeMethodException when JDWP OPAQUE_FRAME error was returned. For virtual threads OpaqueFrameException was added to handle the case where a virtual thread was not suspended at an event, so the JDI implementation was updated to throw OpaqueFrameException if it detected that a native method was not the cause. It turns out however that JVMTI (and therefore JDWP) can return OPAQUE_FRAME error for reasons other than a native method or the special virtual thread case, and for platform threads we were incorrectly throwing NativeMethodException in these cases. This PR fixes that. For platform threads we now only throw NativeMethodException if a native method is detected, and otherwise throw OpaqueFrameException. >> >> The spec language is also being cleaned up to better align with JVMTI. Rather than calling out all the reasons for OpaqueFrameException, a more generic explanation is given. >> >> This is somewhat of a preliminary PR so I can get some feedback. I still need to do a CSR and complete testing. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > update based on feedback > I meant CSR. I'll fix that. JDWP will be updated by https://github.com/openjdk/jdk/pull/26336. Okay, thanks. I'll wait for CSR to review it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26335#issuecomment-3085779698 From dholmes at openjdk.org Fri Jul 18 03:22:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 18 Jul 2025 03:22:53 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException In-Reply-To: References: Message-ID: On Thu, 17 Jul 2025 16:35:11 GMT, Patricio Chilano Mateo wrote: > But maybe we could also add a has_async_exception_condition() check to bailout. Yes. BTW I don't think this is in any way new. I think Thread.stop would have had the same issue. Issuing the internal interrupt was just a convenient way to unblock all the interruptible blocking points - and as Alan notes, monitor acquisition is not interruptible. We likely did not care that this could make the interrupt state appear odd if the thread continued after the async (ThreadDeath) exception. Not sure it is really that different for the debugger - if we have stopped the thread (not just suspended it) then we shouldn't really be expecting it to continue as normal afterwards. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3085431826 From syan at openjdk.org Fri Jul 18 06:08:54 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 18 Jul 2025 06:08:54 GMT Subject: [jdk25] RFR: 8361827: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java throws OutOfMemoryError In-Reply-To: References: Message-ID: <9dUH9xyMt42YeGrOWKXPwDXWMuPqwbUvBXzYd75F2Ts=.b0883b46-cede-4478-a1c6-c7b2accb63bf@github.com> On Thu, 17 Jul 2025 16:18:55 GMT, Leonid Mesnik wrote: >> Hi all, >> >> This pull request contains a backport of commit [cbb3d23e](https://github.com/openjdk/jdk/commit/cbb3d23e19a8a893bf2fbda03e7bda4f4b7a59a6) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to jdk25. >> >> >> Test-fix only to improves test performance and stability. Change has been verified locally, no risk. >> >> Thanks! > > Marked as reviewed by lmesnik (Reviewer). Thanks @lmesnik @reinrich ------------- PR Comment: https://git.openjdk.org/jdk/pull/26343#issuecomment-3087098147 From syan at openjdk.org Fri Jul 18 06:11:55 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 18 Jul 2025 06:11:55 GMT Subject: [jdk25] Integrated: 8361827: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java throws OutOfMemoryError In-Reply-To: References: Message-ID: <_44pqzVrKG2-3O-gPhCg_iV93-Icslk_XED-m73oNTI=.a6f82695-190b-4f0a-8b82-e7e24e452d5d@github.com> On Wed, 16 Jul 2025 06:24:16 GMT, SendaoYan wrote: > Hi all, > > This pull request contains a backport of commit [cbb3d23e](https://github.com/openjdk/jdk/commit/cbb3d23e19a8a893bf2fbda03e7bda4f4b7a59a6) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to jdk25. > > > Test-fix only to improves test performance and stability. Change has been verified locally, no risk. > > Thanks! This pull request has now been integrated. Changeset: e599ee4a Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/e599ee4a88b9a582c98736b18947072e32730c95 Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod 8361827: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java throws OutOfMemoryError Reviewed-by: rrich, lmesnik Backport-of: cbb3d23e19a8a893bf2fbda03e7bda4f4b7a59a6 ------------- PR: https://git.openjdk.org/jdk/pull/26343 From sspitsyn at openjdk.org Fri Jul 18 06:53:47 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 18 Jul 2025 06:53:47 GMT Subject: RFR: 8361751: Test sun/tools/jcmd/TestJcmdSanity.java timed out on Windows In-Reply-To: References: Message-ID: On Wed, 16 Jul 2025 20:44:05 GMT, Alex Menkov wrote: > Tests which run serviceability tools to attach to the main test process can get deadlock with streaming output (see #24672 ) > The fix disables attach streaming output for tests in jdk/sun/tools/jcmd > > Testing: tier6, tier7 Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26358#pullrequestreview-3032224399 From syan at openjdk.org Fri Jul 18 08:52:01 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 18 Jul 2025 08:52:01 GMT Subject: RFR: 8362379: Test serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java should mark as /native Message-ID: Hi all, Test serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java call native libary 'UnmountedVThreadNativeMethodAtTop' with System.loadLibrary. If run this test without jtreg option '-nativepath', jtreg will report 'JUnit test failure'. After this PR, we add jtreg directive `/native` to test header, run this test without jtreg option '-nativepath', jtreg will report 'Error. Use -nativepath to specify the location of native code'. So add `/native` directive will make this test more friendly. Change has been verified locally, test-fix only, no risk. ------------- Commit messages: - 8362379: Test serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java should mark as /native Changes: https://git.openjdk.org/jdk/pull/26384/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26384&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8362379 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26384.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26384/head:pull/26384 PR: https://git.openjdk.org/jdk/pull/26384 From ayang at openjdk.org Fri Jul 18 13:13:38 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 18 Jul 2025 13:13:38 GMT Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v22] 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 33 commits: - merge - 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 - ... and 23 more: https://git.openjdk.org/jdk/compare/7da274de...295dc853 ------------- Changes: https://git.openjdk.org/jdk/pull/25000/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=21 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 matsaave at openjdk.org Fri Jul 18 16:59:49 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 18 Jul 2025 16:59:49 GMT Subject: RFR: 8361725: Do not load Java agent with "-Xshare:dump -XX:+AOTClassLinking" In-Reply-To: References: Message-ID: On Thu, 17 Jul 2025 22:18:44 GMT, Ioi Lam wrote: > When `-XX:+AOTClassLinking` is enabled when dumping CDS archives with `java -Xshare:dump`, we have more stringent restriction of what Java code can be executed -- if arbitrary Java code is executed, it may produce side effects that cannot be handled when archiving Java heap objects. This usually leads to cdsHeapVerifier.cpp reporting suspicious references to static fields that are not known to be safe. > > We already avoid loading Java agents when dumping AOT caches (which are just enhanced CDS archives with more optimizations), we should do the same thing for `java -Xshare:dump -XX:+AOTClassLinking`. > > After this PR, we still allow Java agents for `java -Xshare:dump -XX:-AOTClassLinking`, as that is required by some CDS tests. In a subsequent RFE, we will fix these CDS tests so Java agents are always disabled for `java -Xshare:dump`. See [JDK-8362561](https://bugs.openjdk.org/browse/JDK-8362561) LGTM! ------------- Marked as reviewed by matsaave (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26374#pullrequestreview-3034015196 From ccheung at openjdk.org Fri Jul 18 16:59:59 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 18 Jul 2025 16:59:59 GMT Subject: RFR: 8361725: Do not load Java agent with "-Xshare:dump -XX:+AOTClassLinking" In-Reply-To: References: Message-ID: On Thu, 17 Jul 2025 22:18:44 GMT, Ioi Lam wrote: > When `-XX:+AOTClassLinking` is enabled when dumping CDS archives with `java -Xshare:dump`, we have more stringent restriction of what Java code can be executed -- if arbitrary Java code is executed, it may produce side effects that cannot be handled when archiving Java heap objects. This usually leads to cdsHeapVerifier.cpp reporting suspicious references to static fields that are not known to be safe. > > We already avoid loading Java agents when dumping AOT caches (which are just enhanced CDS archives with more optimizations), we should do the same thing for `java -Xshare:dump -XX:+AOTClassLinking`. > > After this PR, we still allow Java agents for `java -Xshare:dump -XX:-AOTClassLinking`, as that is required by some CDS tests. In a subsequent RFE, we will fix these CDS tests so Java agents are always disabled for `java -Xshare:dump`. See [JDK-8362561](https://bugs.openjdk.org/browse/JDK-8362561) Looks good. test/hotspot/jtreg/runtime/cds/appcds/aotCache/JavaAgentTransformer.java line 41: > 39: savedInstrumentation = instrumentation; > 40: > 41: LOGGER.log(Level.WARNING, "JavaAgentTransformer::premain() is finished"); Just curious why not use `Level.INFO` instead. Is it because the log won't be printed with product build if `Level.INFO` is used? ------------- Marked as reviewed by ccheung (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26374#pullrequestreview-3034175116 PR Review Comment: https://git.openjdk.org/jdk/pull/26374#discussion_r2216471537 From sspitsyn at openjdk.org Fri Jul 18 17:19:40 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 18 Jul 2025 17:19:40 GMT Subject: RFR: 8362379: Test serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java should mark as /native In-Reply-To: References: Message-ID: On Fri, 18 Jul 2025 08:46:59 GMT, SendaoYan wrote: > Hi all, > > Test serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java call native libary 'UnmountedVThreadNativeMethodAtTop' with System.loadLibrary. If run this test without jtreg option '-nativepath', jtreg will report 'JUnit test failure'. After this PR, we add jtreg directive `/native` to test header, run this test without jtreg option '-nativepath', jtreg will report 'Error. Use -nativepath to specify the location of native code'. So add `/native` directive will make this test more friendly. > > Change has been verified locally, test-fix only, no risk. Looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26384#pullrequestreview-3034228165 From cjplummer at openjdk.org Fri Jul 18 17:29:05 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 18 Jul 2025 17:29:05 GMT Subject: RFR: 8362379: Test serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java should mark as /native In-Reply-To: References: Message-ID: On Fri, 18 Jul 2025 08:46:59 GMT, SendaoYan wrote: > Hi all, > > Test serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java call native libary 'UnmountedVThreadNativeMethodAtTop' with System.loadLibrary. If run this test without jtreg option '-nativepath', jtreg will report 'JUnit test failure'. After this PR, we add jtreg directive `/native` to test header, run this test without jtreg option '-nativepath', jtreg will report 'Error. Use -nativepath to specify the location of native code'. So add `/native` directive will make this test more friendly. > > Change has been verified locally, test-fix only, no risk. Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26384#pullrequestreview-3034294960 From amenkov at openjdk.org Fri Jul 18 18:42:46 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 18 Jul 2025 18:42:46 GMT Subject: Integrated: 8361751: Test sun/tools/jcmd/TestJcmdSanity.java timed out on Windows In-Reply-To: References: Message-ID: On Wed, 16 Jul 2025 20:44:05 GMT, Alex Menkov wrote: > Tests which run serviceability tools to attach to the main test process can get deadlock with streaming output (see #24672 ) > The fix disables attach streaming output for tests in jdk/sun/tools/jcmd > > Testing: tier6, tier7 This pull request has now been integrated. Changeset: a3843e8e Author: Alex Menkov URL: https://git.openjdk.org/jdk/commit/a3843e8e6e189447e554759c3ba672530f8c7329 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8361751: Test sun/tools/jcmd/TestJcmdSanity.java timed out on Windows Reviewed-by: cjplummer, dholmes, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/26358 From sspitsyn at openjdk.org Fri Jul 18 18:47:43 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 18 Jul 2025 18:47:43 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException In-Reply-To: References: Message-ID: On Thu, 17 Jul 2025 10:12:16 GMT, Serguei Spitsyn wrote: > If JVMTI `StopThread` is done when the thread is in certain various states (but not all states), after the `async` exception is delivered and handled, hotspot leaves the thread's `interrupted` flag set. The end result is the next time the thread does something like `Thread.sleep()`, it will immediately get an `InterruptedException`. > > The fix is to clear the `interrupted` flag in the `JavaThread::handle_async_exception()` after an `async` pending exception has been set to be thrown with the `set_pending_exception()`. > > There are a couple of concerns with this fix which would be nice to sort out with reviewers: > 1. The proposed fix may clear the interrupt state when it was already set prior to the issuing of the `StopThread()` (this concern was raised by @dholmes-ora in a comment of this JBS issue) > 2. The impacted code path is shared between the class `InstallAsyncExceptionHandshakeClosure` used by the JVMTI `StopThread` implementation and the class `ScopedAsyncExceptionHandshakeClosure` used by the `ScopedMemoryAccess` > > I feel that clearing the `interrupted` flag byt the `JavaThread::handle_async_exception()` is a right thing to do even though it was set before the call to `JavaThread::install_async_exception()`. Also, it has to be done for both `StopThread` and `ScopedMemoryAccess`. > > The fix also includes minor tweaks of the test `StopThreadTest` to make the issue reproducible with it. > > Testing: > - Mach5 tiers 1-6 are passed > - Ran the updated reproducer test `hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest` Thank you for the comments and suggestions! I'll give it a try to get rid of the interrupt flag setting. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3090355324 From iklam at openjdk.org Fri Jul 18 21:32:55 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 18 Jul 2025 21:32:55 GMT Subject: RFR: 8361725: Do not load Java agent with "-Xshare:dump -XX:+AOTClassLinking" In-Reply-To: References: Message-ID: On Fri, 18 Jul 2025 15:41:04 GMT, Matias Saavedra Silva wrote: >> When `-XX:+AOTClassLinking` is enabled when dumping CDS archives with `java -Xshare:dump`, we have more stringent restriction of what Java code can be executed -- if arbitrary Java code is executed, it may produce side effects that cannot be handled when archiving Java heap objects. This usually leads to cdsHeapVerifier.cpp reporting suspicious references to static fields that are not known to be safe. >> >> We already avoid loading Java agents when dumping AOT caches (which are just enhanced CDS archives with more optimizations), we should do the same thing for `java -Xshare:dump -XX:+AOTClassLinking`. >> >> After this PR, we still allow Java agents for `java -Xshare:dump -XX:-AOTClassLinking`, as that is required by some CDS tests. In a subsequent RFE, we will fix these CDS tests so Java agents are always disabled for `java -Xshare:dump`. See [JDK-8362561](https://bugs.openjdk.org/browse/JDK-8362561) > > LGTM! Thanks @matias9927 @calvinccheung for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/26374#issuecomment-3090763537 From iklam at openjdk.org Fri Jul 18 21:32:56 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 18 Jul 2025 21:32:56 GMT Subject: RFR: 8361725: Do not load Java agent with "-Xshare:dump -XX:+AOTClassLinking" In-Reply-To: References: Message-ID: On Fri, 18 Jul 2025 16:43:09 GMT, Calvin Cheung wrote: >> When `-XX:+AOTClassLinking` is enabled when dumping CDS archives with `java -Xshare:dump`, we have more stringent restriction of what Java code can be executed -- if arbitrary Java code is executed, it may produce side effects that cannot be handled when archiving Java heap objects. This usually leads to cdsHeapVerifier.cpp reporting suspicious references to static fields that are not known to be safe. >> >> We already avoid loading Java agents when dumping AOT caches (which are just enhanced CDS archives with more optimizations), we should do the same thing for `java -Xshare:dump -XX:+AOTClassLinking`. >> >> After this PR, we still allow Java agents for `java -Xshare:dump -XX:-AOTClassLinking`, as that is required by some CDS tests. In a subsequent RFE, we will fix these CDS tests so Java agents are always disabled for `java -Xshare:dump`. See [JDK-8362561](https://bugs.openjdk.org/browse/JDK-8362561) > > test/hotspot/jtreg/runtime/cds/appcds/aotCache/JavaAgentTransformer.java line 41: > >> 39: savedInstrumentation = instrumentation; >> 40: >> 41: LOGGER.log(Level.WARNING, "JavaAgentTransformer::premain() is finished"); > > Just curious why not use `Level.INFO` instead. Is it because the log won't be printed with product build if `Level.INFO` is used? I copied this code from the original reproducer. If this code was executed inside the assembly phase, then we will get a CDSHeapVerifier error. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26374#discussion_r2216943972 From iklam at openjdk.org Fri Jul 18 21:32:56 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 18 Jul 2025 21:32:56 GMT Subject: Integrated: 8361725: Do not load Java agent with "-Xshare:dump -XX:+AOTClassLinking" In-Reply-To: References: Message-ID: On Thu, 17 Jul 2025 22:18:44 GMT, Ioi Lam wrote: > When `-XX:+AOTClassLinking` is enabled when dumping CDS archives with `java -Xshare:dump`, we have more stringent restriction of what Java code can be executed -- if arbitrary Java code is executed, it may produce side effects that cannot be handled when archiving Java heap objects. This usually leads to cdsHeapVerifier.cpp reporting suspicious references to static fields that are not known to be safe. > > We already avoid loading Java agents when dumping AOT caches (which are just enhanced CDS archives with more optimizations), we should do the same thing for `java -Xshare:dump -XX:+AOTClassLinking`. > > After this PR, we still allow Java agents for `java -Xshare:dump -XX:-AOTClassLinking`, as that is required by some CDS tests. In a subsequent RFE, we will fix these CDS tests so Java agents are always disabled for `java -Xshare:dump`. See [JDK-8362561](https://bugs.openjdk.org/browse/JDK-8362561) This pull request has now been integrated. Changeset: 9334fe2e Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/9334fe2eca05e852875ed6aad42b5094a32e9b15 Stats: 65 lines in 5 files changed: 57 ins; 1 del; 7 mod 8361725: Do not load Java agent with "-Xshare:dump -XX:+AOTClassLinking" Reviewed-by: matsaave, ccheung ------------- PR: https://git.openjdk.org/jdk/pull/26374 From cjplummer at openjdk.org Fri Jul 18 23:55:44 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 18 Jul 2025 23:55:44 GMT Subject: RFR: 8309400: JDI spec needs to clarify when OpaqueFrameException and NativeMethodException are thrown [v3] In-Reply-To: References: Message-ID: > Fix how ThreadReference.popFrame() and ThreadReference.forceEarlyReturn deal with JDWP OPAQUE_FRAME error. > > Before virtual threads, OpaqueFrameException did not exist and these API always threw NativeMethodException when JDWP OPAQUE_FRAME error was returned. For virtual threads OpaqueFrameException was added to handle the case where a virtual thread was not suspended at an event, so the JDI implementation was updated to throw OpaqueFrameException if it detected that a native method was not the cause. It turns out however that JVMTI (and therefore JDWP) can return OPAQUE_FRAME error for reasons other than a native method or the special virtual thread case, and for platform threads we were incorrectly throwing NativeMethodException in these cases. This PR fixes that. For platform threads we now only throw NativeMethodException if a native method is detected, and otherwise throw OpaqueFrameException. > > The spec language is also being cleaned up to better align with JVMTI. Rather than calling out all the reasons for OpaqueFrameException, a more generic explanation is given. > > This is somewhat of a preliminary PR so I can get some feedback. I still need to do a CSR and complete testing. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: minor rewording ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26335/files - new: https://git.openjdk.org/jdk/pull/26335/files/05cce179..e6376856 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26335&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26335&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26335.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26335/head:pull/26335 PR: https://git.openjdk.org/jdk/pull/26335 From alanb at openjdk.org Sat Jul 19 07:17:39 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 19 Jul 2025 07:17:39 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException In-Reply-To: References: Message-ID: On Fri, 18 Jul 2025 18:44:45 GMT, Serguei Spitsyn wrote: >> If JVMTI `StopThread` is done when the thread is in certain various states (but not all states), after the `async` exception is delivered and handled, hotspot leaves the thread's `interrupted` flag set. The end result is the next time the thread does something like `Thread.sleep()`, it will immediately get an `InterruptedException`. >> >> The fix is to clear the `interrupted` flag in the `JavaThread::handle_async_exception()` after an `async` pending exception has been set to be thrown with the `set_pending_exception()`. >> >> There are a couple of concerns with this fix which would be nice to sort out with reviewers: >> 1. The proposed fix may clear the interrupt state when it was already set prior to the issuing of the `StopThread()` (this concern was raised by @dholmes-ora in a comment of this JBS issue) >> 2. The impacted code path is shared between the class `InstallAsyncExceptionHandshakeClosure` used by the JVMTI `StopThread` implementation and the class `ScopedAsyncExceptionHandshakeClosure` used by the `ScopedMemoryAccess` >> >> I feel that clearing the `interrupted` flag byt the `JavaThread::handle_async_exception()` is a right thing to do even though it was set before the call to `JavaThread::install_async_exception()`. Also, it has to be done for both `StopThread` and `ScopedMemoryAccess`. >> >> The fix also includes minor tweaks of the test `StopThreadTest` to make the issue reproducible with it. >> >> Testing: >> - Mach5 tiers 1-6 are passed >> - Ran the updated reproducer test `hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest` > > Thank you for the comments and suggestions! > I'll give it a try to get rid of the interrupt flag setting. @sspitsyn It might be useful to reach out to the IDEs to see what they are doing. From a quick test with IntelliJ then it appears to invoke both StopThread and InterruptThread when "Exception to Throw" is used. In that case, it means that Thread.sleep will wakeup, even if StopThread doesn't interrupt. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3091973765 From syan at openjdk.org Sat Jul 19 13:29:48 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 19 Jul 2025 13:29:48 GMT Subject: RFR: 8362379: Test serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java should mark as /native In-Reply-To: References: Message-ID: On Fri, 18 Jul 2025 17:01:10 GMT, Serguei Spitsyn wrote: >> Hi all, >> >> Test serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java call native libary 'UnmountedVThreadNativeMethodAtTop' with System.loadLibrary. If run this test without jtreg option '-nativepath', jtreg will report 'JUnit test failure'. After this PR, we add jtreg directive `/native` to test header, run this test without jtreg option '-nativepath', jtreg will report 'Error. Use -nativepath to specify the location of native code'. So add `/native` directive will make this test more friendly. >> >> Change has been verified locally, test-fix only, no risk. > > Looks good. Thanks for the reviews @sspitsyn @plummercj ------------- PR Comment: https://git.openjdk.org/jdk/pull/26384#issuecomment-3092351253 From syan at openjdk.org Sat Jul 19 13:29:48 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 19 Jul 2025 13:29:48 GMT Subject: Integrated: 8362379: Test serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java should mark as /native In-Reply-To: References: Message-ID: On Fri, 18 Jul 2025 08:46:59 GMT, SendaoYan wrote: > Hi all, > > Test serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java call native libary 'UnmountedVThreadNativeMethodAtTop' with System.loadLibrary. If run this test without jtreg option '-nativepath', jtreg will report 'JUnit test failure'. After this PR, we add jtreg directive `/native` to test header, run this test without jtreg option '-nativepath', jtreg will report 'Error. Use -nativepath to specify the location of native code'. So add `/native` directive will make this test more friendly. > > Change has been verified locally, test-fix only, no risk. This pull request has now been integrated. Changeset: ee0bcc55 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/ee0bcc55269e92e999862ae5c63ffad7a600f6cc Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8362379: Test serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java should mark as /native Reviewed-by: sspitsyn, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/26384 From duke at openjdk.org Sat Jul 19 18:15:38 2025 From: duke at openjdk.org (Lei Zhu) Date: Sat, 19 Jul 2025 18:15:38 GMT Subject: RFR: 8362611: [GCC static analyzer] memory leak in ps_core.c core_handle_note Message-ID: Free the `buf` before the early return. ------------- Commit messages: - 8362611: [GCC static analyzer] memory leak in ps_core.c core_handle_note Changes: https://git.openjdk.org/jdk/pull/26403/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26403&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8362611 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26403.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26403/head:pull/26403 PR: https://git.openjdk.org/jdk/pull/26403 From mbaesken at openjdk.org Mon Jul 21 07:08:40 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 21 Jul 2025 07:08:40 GMT Subject: RFR: 8362611: [GCC static analyzer] memory leak in ps_core.c core_handle_note In-Reply-To: References: Message-ID: On Sat, 19 Jul 2025 18:08:03 GMT, Lei Zhu wrote: > Free the `buf` before the early return. Marked as reviewed by mbaesken (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26403#pullrequestreview-3036821556 From dholmes at openjdk.org Mon Jul 21 07:33:42 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 21 Jul 2025 07:33:42 GMT Subject: RFR: 8362611: [GCC static analyzer] memory leak in ps_core.c core_handle_note In-Reply-To: References: Message-ID: On Sat, 19 Jul 2025 18:08:03 GMT, Lei Zhu wrote: > Free the `buf` before the early return. Changes requested by dholmes (Reviewer). src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 290: > 288: print_error("failed to handle NT_PRSTATUS note\n"); > 289: free(buf); > 290: return false; That works, but seems to me that, following the style of the code above, these two lines should be replaced by `goto err;` ------------- PR Review: https://git.openjdk.org/jdk/pull/26403#pullrequestreview-3036885424 PR Review Comment: https://git.openjdk.org/jdk/pull/26403#discussion_r2218407265 From dholmes at openjdk.org Mon Jul 21 08:32:16 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 21 Jul 2025 08:32:16 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread Message-ID: The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads). It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed. Testing: - tiers 1-4 Thanks ------------- Commit messages: - Revert to simpler fix without new API - Revert "Adapt ThreadSnapshotFactory::get_thread_snapshot to use the new API" - Remove unused JvmtiExport::cv_oop_to_JavaThread API - Adapt ThreadSnapshotFactory::get_thread_snapshot to use the new API - Adapt thread conversion routines to return (and protect) the carrier Changes: https://git.openjdk.org/jdk/pull/26287/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26287&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361912 Stats: 87 lines in 4 files changed: 19 ins; 54 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/26287.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26287/head:pull/26287 PR: https://git.openjdk.org/jdk/pull/26287 From duke at openjdk.org Mon Jul 21 10:17:31 2025 From: duke at openjdk.org (Lei Zhu) Date: Mon, 21 Jul 2025 10:17:31 GMT Subject: RFR: 8362611: [GCC static analyzer] memory leak in ps_core.c core_handle_note [v2] In-Reply-To: References: Message-ID: > Free the `buf` before the early return. Lei Zhu has updated the pull request incrementally with one additional commit since the last revision: goto err ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26403/files - new: https://git.openjdk.org/jdk/pull/26403/files/bf535406..470a463c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26403&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26403&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26403.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26403/head:pull/26403 PR: https://git.openjdk.org/jdk/pull/26403 From duke at openjdk.org Mon Jul 21 10:17:31 2025 From: duke at openjdk.org (Lei Zhu) Date: Mon, 21 Jul 2025 10:17:31 GMT Subject: RFR: 8362611: [GCC static analyzer] memory leak in ps_core.c core_handle_note [v2] In-Reply-To: References: Message-ID: On Mon, 21 Jul 2025 07:31:07 GMT, David Holmes wrote: >> Lei Zhu has updated the pull request incrementally with one additional commit since the last revision: >> >> goto err > > src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 290: > >> 288: print_error("failed to handle NT_PRSTATUS note\n"); >> 289: free(buf); >> 290: return false; > > That works, but seems to me that, following the style of the code above, these two lines should be replaced by `goto err;` Thanks for your review, the code has been corrected. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26403#discussion_r2218745625 From alanb at openjdk.org Mon Jul 21 10:38:42 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 21 Jul 2025 10:38:42 GMT Subject: RFR: 8362304: Fix JDWP spec w.r.t. OPAQUE_FRAME and INVALID_SLOT errors In-Reply-To: <7AfNhcIuQyu2_RsHWcqupjsQ8WnT_eJRvnfI4seyCnQ=.55dfbd37-d226-4ee9-a53f-ee4a3b611a09@github.com> References: <7AfNhcIuQyu2_RsHWcqupjsQ8WnT_eJRvnfI4seyCnQ=.55dfbd37-d226-4ee9-a53f-ee4a3b611a09@github.com> Message-ID: On Tue, 15 Jul 2025 22:50:00 GMT, Chris Plummer wrote: > StackFrame.SetValues, StackFrame.GetValues, ThreadReference.PopFrames, and ThreadReference.ForceEarlyReturn all need updated language related to OPAQUE_FRAME error. > > (1) The spec for JVMTI says the following for GetLocalsXXX and SetLocalsXXX > > The implementation is unable to set the frame locals > (e.g. the frame at depth is executing a native method). > > However, the JDWP StackFrame.SetValues and GetValues commands only mention OPAQUE_FRAME for SetValues when not called for the topmost frame of a virtual thread suspended at an event. I don't think there is anything to prevent OPAQUE_FRAME due to the thread being native or some other reason as mentioned in the JVMTI spec. The JDWP spec should be updated to reflect this. > > (1) The spec for JVMTI says the following for PopFrame and ForceEarlyReturn: > > The implementation is unable to force the current frame to return > (e.g. current frame is executing a native method). > > However, the JDWP ThreadReference.PopFrames, and ThreadReference.ForceEarlyReturn commands only mention OPAQUE_FRAME when this commands are not called for the topmost frame of a virtual thread suspended at an event. I don't think there is anything to prevent OPAQUE_FRAME due to the thread being native or some other reason as mentioned in the JVMTI spec. The JDWP spec should be updated to reflect this. > > (3) Another issue is that INVALID_SLOT is missing in the JDWP spec for SetValues, but is there for GetValues. It should be mentioned for both commands. src/java.se/share/data/jdwp/jdwp.spec line 2154: > 2152: "corresponding to a native method, " > 2153: "or the implementation is unable to provide this " > 2154: "functionality on this frame.") This is okay but I wonder if you've considered nudging it closer to wording in JVMTI ForceEarlyReturnXXX so it would say the implementation is unable to force the frame to return and use a native frame as an example. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26336#discussion_r2218791028 From dholmes at openjdk.org Mon Jul 21 12:05:41 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 21 Jul 2025 12:05:41 GMT Subject: RFR: 8362611: [GCC static analyzer] memory leak in ps_core.c core_handle_note [v2] In-Reply-To: References: Message-ID: On Mon, 21 Jul 2025 10:17:31 GMT, Lei Zhu wrote: >> Free the `buf` before the early return. > > Lei Zhu has updated the pull request incrementally with one additional commit since the last revision: > > goto err Thanks for the update. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26403#pullrequestreview-3037778314 From duke at openjdk.org Mon Jul 21 12:12:42 2025 From: duke at openjdk.org (duke) Date: Mon, 21 Jul 2025 12:12:42 GMT Subject: RFR: 8362611: [GCC static analyzer] memory leak in ps_core.c core_handle_note [v2] In-Reply-To: References: Message-ID: <2N3JRcK81WRidzu7PgCZ2RA6BNsGcqHErwKFtyi6UGg=.513379e7-d0cd-418b-9040-565bf5655e8e@github.com> On Mon, 21 Jul 2025 10:17:31 GMT, Lei Zhu wrote: >> Free the `buf` before the early return. > > Lei Zhu has updated the pull request incrementally with one additional commit since the last revision: > > goto err @Korov Your change (at version 470a463c23af48a1646052dad624044028f60155) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26403#issuecomment-3096481349 From duke at openjdk.org Mon Jul 21 12:27:47 2025 From: duke at openjdk.org (Lei Zhu) Date: Mon, 21 Jul 2025 12:27:47 GMT Subject: Integrated: 8362611: [GCC static analyzer] memory leak in ps_core.c core_handle_note In-Reply-To: References: Message-ID: On Sat, 19 Jul 2025 18:08:03 GMT, Lei Zhu wrote: > Free the `buf` before the early return. This pull request has now been integrated. Changeset: 644e400c Author: Lei Zhu Committer: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/644e400cd1f8a80df01b4f1755450f86709485f4 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8362611: [GCC static analyzer] memory leak in ps_core.c core_handle_note Reviewed-by: dholmes, mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/26403 From amenkov at openjdk.org Mon Jul 21 18:44:28 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 21 Jul 2025 18:44:28 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread In-Reply-To: References: Message-ID: On Mon, 14 Jul 2025 05:34:57 GMT, David Holmes wrote: > The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads). > > It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed. > > Testing: > - tiers 1-4 > > Thanks src/hotspot/share/runtime/threadSMR.hpp line 78: > 76: // longer protected by a ThreadsListHandle. > 77: // > 78: // Note that for virtual threads, we obtain a reference to the carrier JavaThread This is not correct for `JvmtiExport::cv_external_thread_to_JavaThread` (it does not return carrier's JavaThread). JVMTI has `JvmtiEnvBase::get_threadOop_and_JavaThread` and `JvmtiEnvBase::get_JavaThread_or_null` to get carrier thread ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2219977613 From dholmes at openjdk.org Mon Jul 21 21:45:25 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 21 Jul 2025 21:45:25 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread In-Reply-To: References: Message-ID: On Mon, 21 Jul 2025 18:42:14 GMT, Alex Menkov wrote: >> The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads). >> >> It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed. >> >> Testing: >> - tiers 1-4 >> >> Thanks > > src/hotspot/share/runtime/threadSMR.hpp line 78: > >> 76: // longer protected by a ThreadsListHandle. >> 77: // >> 78: // Note that for virtual threads, we obtain a reference to the carrier JavaThread > > This is not correct for `JvmtiExport::cv_external_thread_to_JavaThread` (it does not return carrier's JavaThread). > JVMTI has `JvmtiEnvBase::get_threadOop_and_JavaThread` and `JvmtiEnvBase::get_JavaThread_or_null` to get carrier thread This code does not document/describe `JvmtiExport::cv_external_thread_to_JavaThread`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2220422664 From amenkov at openjdk.org Mon Jul 21 22:10:24 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 21 Jul 2025 22:10:24 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread In-Reply-To: References: Message-ID: On Mon, 21 Jul 2025 21:43:02 GMT, David Holmes wrote: >> src/hotspot/share/runtime/threadSMR.hpp line 78: >> >>> 76: // longer protected by a ThreadsListHandle. >>> 77: // >>> 78: // Note that for virtual threads, we obtain a reference to the carrier JavaThread >> >> This is not correct for `JvmtiExport::cv_external_thread_to_JavaThread` (it does not return carrier's JavaThread). >> JVMTI has `JvmtiEnvBase::get_threadOop_and_JavaThread` and `JvmtiEnvBase::get_JavaThread_or_null` to get carrier thread > > This code does not document/describe `JvmtiExport::cv_external_thread_to_JavaThread`. This is common comment which describes 2 ways to get protected JavaThread, so to me it looks like it describes both (the rest of the comment is applicable to JvmtiExport::cv_external_thread_to_JavaThread). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2220457004 From dholmes at openjdk.org Tue Jul 22 05:39:38 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 22 Jul 2025 05:39:38 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread In-Reply-To: References: Message-ID: On Mon, 21 Jul 2025 22:07:38 GMT, Alex Menkov wrote: >> This code does not document/describe `JvmtiExport::cv_external_thread_to_JavaThread`. > > This is common comment which describes 2 ways to get protected JavaThread, so to me it looks like it describes both (the rest of the comment is applicable to JvmtiExport::cv_external_thread_to_JavaThread). Sorry confused myself. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2221247224 From dholmes at openjdk.org Tue Jul 22 05:47:37 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 22 Jul 2025 05:47:37 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread [v2] In-Reply-To: References: Message-ID: > The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads). > > It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed. > > Testing: > - tiers 1-4 > > Thanks David Holmes has updated the pull request incrementally with one additional commit since the last revision: Move comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26287/files - new: https://git.openjdk.org/jdk/pull/26287/files/a195fe22..820f26e4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26287&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26287&range=00-01 Stats: 12 lines in 2 files changed: 4 ins; 5 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26287.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26287/head:pull/26287 PR: https://git.openjdk.org/jdk/pull/26287 From cjplummer at openjdk.org Tue Jul 22 06:11:45 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 22 Jul 2025 06:11:45 GMT Subject: RFR: 8362304: Fix JDWP spec w.r.t. OPAQUE_FRAME and INVALID_SLOT errors [v2] In-Reply-To: <7AfNhcIuQyu2_RsHWcqupjsQ8WnT_eJRvnfI4seyCnQ=.55dfbd37-d226-4ee9-a53f-ee4a3b611a09@github.com> References: <7AfNhcIuQyu2_RsHWcqupjsQ8WnT_eJRvnfI4seyCnQ=.55dfbd37-d226-4ee9-a53f-ee4a3b611a09@github.com> Message-ID: <9e4irEatV7hiVaIFKdHUq0AHNozfzEllM9bKJt6FJ7o=.e915af88-4fae-4e6e-a284-461f458d5b41@github.com> > StackFrame.SetValues, StackFrame.GetValues, ThreadReference.PopFrames, and ThreadReference.ForceEarlyReturn all need updated language related to OPAQUE_FRAME error. > > (1) The spec for JVMTI says the following for GetLocalsXXX and SetLocalsXXX > > The implementation is unable to set the frame locals > (e.g. the frame at depth is executing a native method). > > However, the JDWP StackFrame.SetValues and GetValues commands only mention OPAQUE_FRAME for SetValues when not called for the topmost frame of a virtual thread suspended at an event. I don't think there is anything to prevent OPAQUE_FRAME due to the thread being native or some other reason as mentioned in the JVMTI spec. The JDWP spec should be updated to reflect this. > > (1) The spec for JVMTI says the following for PopFrame and ForceEarlyReturn: > > The implementation is unable to force the current frame to return > (e.g. current frame is executing a native method). > > However, the JDWP ThreadReference.PopFrames, and ThreadReference.ForceEarlyReturn commands only mention OPAQUE_FRAME when this commands are not called for the topmost frame of a virtual thread suspended at an event. I don't think there is anything to prevent OPAQUE_FRAME due to the thread being native or some other reason as mentioned in the JVMTI spec. The JDWP spec should be updated to reflect this. > > (3) Another issue is that INVALID_SLOT is missing in the JDWP spec for SetValues, but is there for GetValues. It should be mentioned for both commands. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: make workding more like JVMTI spec ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26336/files - new: https://git.openjdk.org/jdk/pull/26336/files/27bfb72a..b99935a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26336&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26336&range=00-01 Stats: 16 lines in 1 file changed: 0 ins; 7 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/26336.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26336/head:pull/26336 PR: https://git.openjdk.org/jdk/pull/26336 From alanb at openjdk.org Tue Jul 22 07:04:39 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 22 Jul 2025 07:04:39 GMT Subject: RFR: 8362304: Fix JDWP spec w.r.t. OPAQUE_FRAME and INVALID_SLOT errors [v2] In-Reply-To: <9e4irEatV7hiVaIFKdHUq0AHNozfzEllM9bKJt6FJ7o=.e915af88-4fae-4e6e-a284-461f458d5b41@github.com> References: <7AfNhcIuQyu2_RsHWcqupjsQ8WnT_eJRvnfI4seyCnQ=.55dfbd37-d226-4ee9-a53f-ee4a3b611a09@github.com> <9e4irEatV7hiVaIFKdHUq0AHNozfzEllM9bKJt6FJ7o=.e915af88-4fae-4e6e-a284-461f458d5b41@github.com> Message-ID: On Tue, 22 Jul 2025 06:11:45 GMT, Chris Plummer wrote: >> StackFrame.SetValues, StackFrame.GetValues, ThreadReference.PopFrames, and ThreadReference.ForceEarlyReturn all need updated language related to OPAQUE_FRAME error. >> >> (1) The spec for JVMTI says the following for GetLocalsXXX and SetLocalsXXX >> >> The implementation is unable to set the frame locals >> (e.g. the frame at depth is executing a native method). >> >> However, the JDWP StackFrame.SetValues and GetValues commands only mention OPAQUE_FRAME for SetValues when not called for the topmost frame of a virtual thread suspended at an event. I don't think there is anything to prevent OPAQUE_FRAME due to the thread being native or some other reason as mentioned in the JVMTI spec. The JDWP spec should be updated to reflect this. >> >> (1) The spec for JVMTI says the following for PopFrame and ForceEarlyReturn: >> >> The implementation is unable to force the current frame to return >> (e.g. current frame is executing a native method). >> >> However, the JDWP ThreadReference.PopFrames, and ThreadReference.ForceEarlyReturn commands only mention OPAQUE_FRAME when this commands are not called for the topmost frame of a virtual thread suspended at an event. I don't think there is anything to prevent OPAQUE_FRAME due to the thread being native or some other reason as mentioned in the JVMTI spec. The JDWP spec should be updated to reflect this. >> >> (3) Another issue is that INVALID_SLOT is missing in the JDWP spec for SetValues, but is there for GetValues. It should be mentioned for both commands. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > make workding more like JVMTI spec Updated version looks good. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26336#pullrequestreview-3041438889 From sspitsyn at openjdk.org Tue Jul 22 08:44:35 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 22 Jul 2025 08:44:35 GMT Subject: RFR: 8362304: Fix JDWP spec w.r.t. OPAQUE_FRAME and INVALID_SLOT errors [v2] In-Reply-To: <9e4irEatV7hiVaIFKdHUq0AHNozfzEllM9bKJt6FJ7o=.e915af88-4fae-4e6e-a284-461f458d5b41@github.com> References: <7AfNhcIuQyu2_RsHWcqupjsQ8WnT_eJRvnfI4seyCnQ=.55dfbd37-d226-4ee9-a53f-ee4a3b611a09@github.com> <9e4irEatV7hiVaIFKdHUq0AHNozfzEllM9bKJt6FJ7o=.e915af88-4fae-4e6e-a284-461f458d5b41@github.com> Message-ID: <8Vv9ybFOzAQiXgxZkeFGQpZLU4jbrrPqV8udicmFZQs=.28924197-f884-4f8d-a42d-1d6539e21b9e@github.com> On Tue, 22 Jul 2025 06:11:45 GMT, Chris Plummer wrote: >> StackFrame.SetValues, StackFrame.GetValues, ThreadReference.PopFrames, and ThreadReference.ForceEarlyReturn all need updated language related to OPAQUE_FRAME error. >> >> (1) The spec for JVMTI says the following for GetLocalsXXX and SetLocalsXXX >> >> The implementation is unable to set the frame locals >> (e.g. the frame at depth is executing a native method). >> >> However, the JDWP StackFrame.SetValues and GetValues commands only mention OPAQUE_FRAME for SetValues when not called for the topmost frame of a virtual thread suspended at an event. I don't think there is anything to prevent OPAQUE_FRAME due to the thread being native or some other reason as mentioned in the JVMTI spec. The JDWP spec should be updated to reflect this. >> >> (1) The spec for JVMTI says the following for PopFrame and ForceEarlyReturn: >> >> The implementation is unable to force the current frame to return >> (e.g. current frame is executing a native method). >> >> However, the JDWP ThreadReference.PopFrames, and ThreadReference.ForceEarlyReturn commands only mention OPAQUE_FRAME when this commands are not called for the topmost frame of a virtual thread suspended at an event. I don't think there is anything to prevent OPAQUE_FRAME due to the thread being native or some other reason as mentioned in the JVMTI spec. The JDWP spec should be updated to reflect this. >> >> (3) Another issue is that INVALID_SLOT is missing in the JDWP spec for SetValues, but is there for GetValues. It should be mentioned for both commands. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > make workding more like JVMTI spec The update looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26336#pullrequestreview-3041868929 From sspitsyn at openjdk.org Tue Jul 22 15:18:00 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 22 Jul 2025 15:18:00 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException In-Reply-To: References: Message-ID: On Fri, 18 Jul 2025 18:44:45 GMT, Serguei Spitsyn wrote: >> If JVMTI `StopThread` is done when the thread is in certain various states (but not all states), after the `async` exception is delivered and handled, hotspot leaves the thread's `interrupted` flag set. The end result is the next time the thread does something like `Thread.sleep()`, it will immediately get an `InterruptedException`. >> >> The fix is to clear the `interrupted` flag in the `JavaThread::handle_async_exception()` after an `async` pending exception has been set to be thrown with the `set_pending_exception()`. >> >> There are a couple of concerns with this fix which would be nice to sort out with reviewers: >> 1. The proposed fix may clear the interrupt state when it was already set prior to the issuing of the `StopThread()` (this concern was raised by @dholmes-ora in a comment of this JBS issue) >> 2. The impacted code path is shared between the class `InstallAsyncExceptionHandshakeClosure` used by the JVMTI `StopThread` implementation and the class `ScopedAsyncExceptionHandshakeClosure` used by the `ScopedMemoryAccess` >> >> I feel that clearing the `interrupted` flag byt the `JavaThread::handle_async_exception()` is a right thing to do even though it was set before the call to `JavaThread::install_async_exception()`. Also, it has to be done for both `StopThread` and `ScopedMemoryAccess`. >> >> The fix also includes minor tweaks of the test `StopThreadTest` to make the issue reproducible with it. >> >> Testing: >> - Mach5 tiers 1-6 are passed >> - Ran the updated reproducer test `hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest` > > Thank you for the comments and suggestions! > I'll give it a try to get rid of the interrupt flag setting. > @sspitsyn It might be useful to reach out to the IDEs to see what they are doing. From a quick test with IntelliJ then it appears to invoke both StopThread and InterruptThread when "Exception to Throw" is used. In that case, it means that Thread.sleep will wakeup, even if StopThread doesn't interrupt. Good suggestion, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3101724868 From alanb at openjdk.org Tue Jul 22 17:54:57 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 22 Jul 2025 17:54:57 GMT Subject: RFR: 8309400: JDI spec needs to clarify when OpaqueFrameException and NativeMethodException are thrown [v3] In-Reply-To: References: Message-ID: On Fri, 18 Jul 2025 23:55:44 GMT, Chris Plummer wrote: >> Fix how ThreadReference.popFrame() and ThreadReference.forceEarlyReturn deal with JDWP OPAQUE_FRAME error. >> >> Before virtual threads, OpaqueFrameException did not exist and these API always threw NativeMethodException when JDWP OPAQUE_FRAME error was returned. For virtual threads OpaqueFrameException was added to handle the case where a virtual thread was not suspended at an event, so the JDI implementation was updated to throw OpaqueFrameException if it detected that a native method was not the cause. It turns out however that JVMTI (and therefore JDWP) can return OPAQUE_FRAME error for reasons other than a native method or the special virtual thread case, and for platform threads we were incorrectly throwing NativeMethodException in these cases. This PR fixes that. For platform threads we now only throw NativeMethodException if a native method is detected, and otherwise throw OpaqueFrameException. >> >> The spec language is also being cleaned up to better align with JVMTI. Rather than calling out all the reasons for OpaqueFrameException, a more generic explanation is given. >> >> This is somewhat of a preliminary PR so I can get some feedback. I still need to do a CSR and complete testing. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > minor rewording Looks good to me. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26335#pullrequestreview-3044191540 From amenkov at openjdk.org Tue Jul 22 20:41:55 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 22 Jul 2025 20:41:55 GMT Subject: RFR: 8362304: Fix JDWP spec w.r.t. OPAQUE_FRAME and INVALID_SLOT errors [v2] In-Reply-To: <9e4irEatV7hiVaIFKdHUq0AHNozfzEllM9bKJt6FJ7o=.e915af88-4fae-4e6e-a284-461f458d5b41@github.com> References: <7AfNhcIuQyu2_RsHWcqupjsQ8WnT_eJRvnfI4seyCnQ=.55dfbd37-d226-4ee9-a53f-ee4a3b611a09@github.com> <9e4irEatV7hiVaIFKdHUq0AHNozfzEllM9bKJt6FJ7o=.e915af88-4fae-4e6e-a284-461f458d5b41@github.com> Message-ID: On Tue, 22 Jul 2025 06:11:45 GMT, Chris Plummer wrote: >> StackFrame.SetValues, StackFrame.GetValues, ThreadReference.PopFrames, and ThreadReference.ForceEarlyReturn all need updated language related to OPAQUE_FRAME error. >> >> (1) The spec for JVMTI says the following for GetLocalsXXX and SetLocalsXXX >> >> The implementation is unable to set the frame locals >> (e.g. the frame at depth is executing a native method). >> >> However, the JDWP StackFrame.SetValues and GetValues commands only mention OPAQUE_FRAME for SetValues when not called for the topmost frame of a virtual thread suspended at an event. I don't think there is anything to prevent OPAQUE_FRAME due to the thread being native or some other reason as mentioned in the JVMTI spec. The JDWP spec should be updated to reflect this. >> >> (1) The spec for JVMTI says the following for PopFrame and ForceEarlyReturn: >> >> The implementation is unable to force the current frame to return >> (e.g. current frame is executing a native method). >> >> However, the JDWP ThreadReference.PopFrames, and ThreadReference.ForceEarlyReturn commands only mention OPAQUE_FRAME when this commands are not called for the topmost frame of a virtual thread suspended at an event. I don't think there is anything to prevent OPAQUE_FRAME due to the thread being native or some other reason as mentioned in the JVMTI spec. The JDWP spec should be updated to reflect this. >> >> (3) Another issue is that INVALID_SLOT is missing in the JDWP spec for SetValues, but is there for GetValues. It should be mentioned for both commands. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > make workding more like JVMTI spec Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26336#pullrequestreview-3044807888 From amenkov at openjdk.org Tue Jul 22 21:58:57 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 22 Jul 2025 21:58:57 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread [v2] In-Reply-To: References: Message-ID: <0a3P5KbREzdT_JPh-1FBuiy4Hd94jATzw7jMIL9_Vwk=.062be141-af57-42b7-bffe-b710bbe5fe02@github.com> On Tue, 22 Jul 2025 05:47:37 GMT, David Holmes wrote: >> The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads). >> >> It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed. >> >> Testing: >> - tiers 1-4 >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Move comment I still think that it would be safer to explicitly specify that caller knows that jthread can be virtual thread (and maybe add assert when a caller works only with platform threads, but passed jthread is virtual), but ok, it's up to you. Currently all callers except `ThreadSnapshotFactory::get_thread_snapshot` use `cv_internal_thread_to_JavaThread` for platform threads only. Do you want to update `ThreadSnapshotFactory::get_thread_snapshot` to utilize new functionality or prefer to do it by separate CR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26287#issuecomment-3104940720 From dholmes at openjdk.org Wed Jul 23 00:03:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 23 Jul 2025 00:03:54 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread [v2] In-Reply-To: <0a3P5KbREzdT_JPh-1FBuiy4Hd94jATzw7jMIL9_Vwk=.062be141-af57-42b7-bffe-b710bbe5fe02@github.com> References: <0a3P5KbREzdT_JPh-1FBuiy4Hd94jATzw7jMIL9_Vwk=.062be141-af57-42b7-bffe-b710bbe5fe02@github.com> Message-ID: On Tue, 22 Jul 2025 21:55:56 GMT, Alex Menkov wrote: > I still think that it would be safer to explicitly specify that caller knows that jthread can be virtual thread I think that retains the risk of the caller not knowing they need to ensure they protect the carrier thread. > Do you want to update ThreadSnapshotFactory::get_thread_snapshot to utilize new functionality No, we had some internal discussions and that code is incorrectly using the JVMTI transition disabler, so it needs a complete overhaul. That will be handled separately. Thanks again for looking at this in depth Alex. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26287#issuecomment-3105187899 From amenkov at openjdk.org Wed Jul 23 00:31:54 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 23 Jul 2025 00:31:54 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread [v2] In-Reply-To: References: Message-ID: On Tue, 22 Jul 2025 05:47:37 GMT, David Holmes wrote: >> The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads). >> >> It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed. >> >> Testing: >> - tiers 1-4 >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Move comment Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26287#pullrequestreview-3045222350 From sspitsyn at openjdk.org Wed Jul 23 07:21:54 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 23 Jul 2025 07:21:54 GMT Subject: RFR: 8309400: JDI spec needs to clarify when OpaqueFrameException and NativeMethodException are thrown [v3] In-Reply-To: References: Message-ID: On Fri, 18 Jul 2025 23:55:44 GMT, Chris Plummer wrote: >> Fix how ThreadReference.popFrame() and ThreadReference.forceEarlyReturn deal with JDWP OPAQUE_FRAME error. >> >> Before virtual threads, OpaqueFrameException did not exist and these API always threw NativeMethodException when JDWP OPAQUE_FRAME error was returned. For virtual threads OpaqueFrameException was added to handle the case where a virtual thread was not suspended at an event, so the JDI implementation was updated to throw OpaqueFrameException if it detected that a native method was not the cause. It turns out however that JVMTI (and therefore JDWP) can return OPAQUE_FRAME error for reasons other than a native method or the special virtual thread case, and for platform threads we were incorrectly throwing NativeMethodException in these cases. This PR fixes that. For platform threads we now only throw NativeMethodException if a native method is detected, and otherwise throw OpaqueFrameException. >> >> The spec language is also being cleaned up to better align with JVMTI. Rather than calling out all the reasons for OpaqueFrameException, a more generic explanation is given. >> >> This is somewhat of a preliminary PR so I can get some feedback. I still need to do a CSR and complete testing. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > minor rewording Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26335#pullrequestreview-3045996893 From zgu at openjdk.org Wed Jul 23 16:25:03 2025 From: zgu at openjdk.org (Zhengyu Gu) Date: Wed, 23 Jul 2025 16:25:03 GMT Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v22] In-Reply-To: References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com> Message-ID: On Fri, 18 Jul 2025 13:13:38 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 33 commits: > > - merge > - 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 > - ... and 23 more: https://git.openjdk.org/jdk/compare/7da274de...295dc853 Looks good! ------------- Marked as reviewed by zgu (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25000#pullrequestreview-3048185454 From ayang at openjdk.org Wed Jul 23 20:13:13 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 23 Jul 2025 20:13:13 GMT Subject: Integrated: 8338977: Parallel: Improve heap resizing heuristics In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com> References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com> Message-ID: On Fri, 2 May 2025 10:23:25 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 This pull request has now been integrated. Changeset: ad510fb2 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/ad510fb25e47098d136515c355164e5177c5b419 Stats: 4362 lines in 31 files changed: 507 ins; 3470 del; 385 mod 8338977: Parallel: Improve heap resizing heuristics Reviewed-by: zgu, gli, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/25000 From ayang at openjdk.org Wed Jul 23 20:13:12 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 23 Jul 2025 20:13:12 GMT Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v22] In-Reply-To: References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com> Message-ID: <_Yg88tIFDmL4WUGVb--Xy-hih_0NrVkmqWU5FfFha4Y=.9e385636-1779-4189-855b-a123cd2b0cd7@github.com> On Fri, 18 Jul 2025 13:13:38 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 33 commits: > > - merge > - 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 > - ... and 23 more: https://git.openjdk.org/jdk/compare/7da274de...295dc853 Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25000#issuecomment-3109989114 From sspitsyn at openjdk.org Thu Jul 24 05:45:55 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 24 Jul 2025 05:45:55 GMT Subject: RFR: 8362304: Fix JDWP spec w.r.t. OPAQUE_FRAME and INVALID_SLOT errors [v2] In-Reply-To: <9e4irEatV7hiVaIFKdHUq0AHNozfzEllM9bKJt6FJ7o=.e915af88-4fae-4e6e-a284-461f458d5b41@github.com> References: <7AfNhcIuQyu2_RsHWcqupjsQ8WnT_eJRvnfI4seyCnQ=.55dfbd37-d226-4ee9-a53f-ee4a3b611a09@github.com> <9e4irEatV7hiVaIFKdHUq0AHNozfzEllM9bKJt6FJ7o=.e915af88-4fae-4e6e-a284-461f458d5b41@github.com> Message-ID: On Tue, 22 Jul 2025 06:11:45 GMT, Chris Plummer wrote: >> StackFrame.SetValues, StackFrame.GetValues, ThreadReference.PopFrames, and ThreadReference.ForceEarlyReturn all need updated language related to OPAQUE_FRAME error. >> >> (1) The spec for JVMTI says the following for GetLocalsXXX and SetLocalsXXX >> >> The implementation is unable to set the frame locals >> (e.g. the frame at depth is executing a native method). >> >> However, the JDWP StackFrame.SetValues and GetValues commands only mention OPAQUE_FRAME for SetValues when not called for the topmost frame of a virtual thread suspended at an event. I don't think there is anything to prevent OPAQUE_FRAME due to the thread being native or some other reason as mentioned in the JVMTI spec. The JDWP spec should be updated to reflect this. >> >> (1) The spec for JVMTI says the following for PopFrame and ForceEarlyReturn: >> >> The implementation is unable to force the current frame to return >> (e.g. current frame is executing a native method). >> >> However, the JDWP ThreadReference.PopFrames, and ThreadReference.ForceEarlyReturn commands only mention OPAQUE_FRAME when this commands are not called for the topmost frame of a virtual thread suspended at an event. I don't think there is anything to prevent OPAQUE_FRAME due to the thread being native or some other reason as mentioned in the JVMTI spec. The JDWP spec should be updated to reflect this. >> >> (3) Another issue is that INVALID_SLOT is missing in the JDWP spec for SetValues, but is there for GetValues. It should be mentioned for both commands. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > make workding more like JVMTI spec I think, this issue needs a Release Note, same as the JVMTI and JNI related enhancements. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26336#issuecomment-3112046691 From rrich at openjdk.org Thu Jul 24 07:28:39 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Thu, 24 Jul 2025 07:28:39 GMT Subject: RFR: 8362482: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java: System.gc() does not provide full GC Message-ID: <3kKyvSopVJNqmnOvWvycADtzAFFcB9lo3wFqJ8OQqEE=.169604ff-8ae9-4d39-85e7-8c9cc69add5b@github.com> Call WhiteBox.fullGC() instead of System.gc() for a guaranteed full GC. It is assumed that one full GC is sufficient for these tests. Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. ------------- Commit messages: - Merge branch 'master' - Use /native option - Use WhiteBox::fullGC instead of System::gc Changes: https://git.openjdk.org/jdk/pull/26363/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26363&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8362482 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26363.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26363/head:pull/26363 PR: https://git.openjdk.org/jdk/pull/26363 From syan at openjdk.org Thu Jul 24 07:28:40 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 24 Jul 2025 07:28:40 GMT Subject: RFR: 8362482: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java: System.gc() does not provide full GC In-Reply-To: <3kKyvSopVJNqmnOvWvycADtzAFFcB9lo3wFqJ8OQqEE=.169604ff-8ae9-4d39-85e7-8c9cc69add5b@github.com> References: <3kKyvSopVJNqmnOvWvycADtzAFFcB9lo3wFqJ8OQqEE=.169604ff-8ae9-4d39-85e7-8c9cc69add5b@github.com> Message-ID: <4TCLhbyyLKe-hnbYHa9sD1nQZQIDsyzitSODY7GYLjM=.1fcd29bd-739b-457a-9f2d-605939deafae@github.com> On Thu, 17 Jul 2025 09:58:34 GMT, Richard Reingruber wrote: > Call WhiteBox.fullGC() instead of System.gc() for a guaranteed full GC. > It is assumed that one full GC is sufficient for these tests. > > Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. test/hotspot/jtreg/serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java line 32: > 30: * @build jdk.test.whitebox.WhiteBox > 31: * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox > 32: * @run junit/othervm -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI --enable-native-access=ALL-UNNAMED UnmountedVThreadNativeMethodAtTop Maybe use '@run junit/othervm/native' more better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26363#discussion_r2213125377 From rrich at openjdk.org Thu Jul 24 07:28:40 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Thu, 24 Jul 2025 07:28:40 GMT Subject: RFR: 8362482: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java: System.gc() does not provide full GC In-Reply-To: <4TCLhbyyLKe-hnbYHa9sD1nQZQIDsyzitSODY7GYLjM=.1fcd29bd-739b-457a-9f2d-605939deafae@github.com> References: <3kKyvSopVJNqmnOvWvycADtzAFFcB9lo3wFqJ8OQqEE=.169604ff-8ae9-4d39-85e7-8c9cc69add5b@github.com> <4TCLhbyyLKe-hnbYHa9sD1nQZQIDsyzitSODY7GYLjM=.1fcd29bd-739b-457a-9f2d-605939deafae@github.com> Message-ID: On Thu, 17 Jul 2025 11:48:15 GMT, SendaoYan wrote: >> Call WhiteBox.fullGC() instead of System.gc() for a guaranteed full GC. >> It is assumed that one full GC is sufficient for these tests. >> >> Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. > > test/hotspot/jtreg/serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java line 32: > >> 30: * @build jdk.test.whitebox.WhiteBox >> 31: * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox >> 32: * @run junit/othervm -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI --enable-native-access=ALL-UNNAMED UnmountedVThreadNativeMethodAtTop > > Maybe use '@run junit/othervm/native' more better. I guess that's better. Thanks for the hint. I wasn't aware of the `/native` option. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26363#discussion_r2213422135 From sspitsyn at openjdk.org Thu Jul 24 08:49:00 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 24 Jul 2025 08:49:00 GMT Subject: RFR: 8362482: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java: System.gc() does not provide full GC In-Reply-To: <3kKyvSopVJNqmnOvWvycADtzAFFcB9lo3wFqJ8OQqEE=.169604ff-8ae9-4d39-85e7-8c9cc69add5b@github.com> References: <3kKyvSopVJNqmnOvWvycADtzAFFcB9lo3wFqJ8OQqEE=.169604ff-8ae9-4d39-85e7-8c9cc69add5b@github.com> Message-ID: On Thu, 17 Jul 2025 09:58:34 GMT, Richard Reingruber wrote: > Call WhiteBox.fullGC() instead of System.gc() for a guaranteed full GC. > It is assumed that one full GC is sufficient for these tests. > > Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. This looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26363#pullrequestreview-3050703326 From sspitsyn at openjdk.org Thu Jul 24 09:48:57 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 24 Jul 2025 09:48:57 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread [v2] In-Reply-To: References: Message-ID: On Tue, 22 Jul 2025 05:47:37 GMT, David Holmes wrote: >> The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads). >> >> It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed. >> >> Testing: >> - tiers 1-4 >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Move comment src/hotspot/share/runtime/threadSMR.cpp line 839: > 837: } > 838: if (java_thread == nullptr) { > 839: // Virtual thread was unmounted, or else carrier has now terminated. Nit: If `java_thread` for a virtual thread is null then this thread is unmounted. The words about the terminated carrier thread are confusing. I have one concern here. Nothing protects this code from facing some unexpected conditions as this function is racy with mounting and unmounting of target virtual thread - this function can observe a `JavaThread` in `mount` or `unmount` transition where the thread identity of a `java.lang.Thread` associated with the `JavaThread` is not consistent (in a VTMS transition the thread identity might not match the stack trace) - nothing guaranties that the result returned by this function remains the same upon return as `mount`/`unmount` of the target virtual thread can be executed concurrently: a mounted virtual thread can be quickly unmounted or an unmounted virtual thread can be quickly mounted So, it seems that this function is going to work correctly if used for target platform threads only or if the `JavaThread*` pointer is not really needed. Otherwise, the association with the `JavaThread` needs to be rechecked and its stability somehow guaranteed with any form of scheduling suspension or a VTMS transition disabler. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2228017957 From dholmes at openjdk.org Thu Jul 24 12:34:05 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 24 Jul 2025 12:34:05 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread [v2] In-Reply-To: References: Message-ID: <91SlomOKdMCW1YfX3koOZAvoQbf-7kODO_rfZb_O_Ag=.83944b59-5a69-4f02-80d5-1eff1091ae29@github.com> On Thu, 24 Jul 2025 12:29:29 GMT, David Holmes wrote: >> src/hotspot/share/runtime/threadSMR.cpp line 839: >> >>> 837: } >>> 838: if (java_thread == nullptr) { >>> 839: // Virtual thread was unmounted, or else carrier has now terminated. >> >> Nit: If `java_thread` for a virtual thread is null then this thread is unmounted. The words about the terminated carrier thread are confusing. >> >> I have one concern here. Nothing protects this code from facing some unexpected conditions as this function is racy with mounting and unmounting of target virtual thread >> - this function can observe a `JavaThread` in `mount` or `unmount` transition where the thread identity of a `java.lang.Thread` associated with the `JavaThread` is not consistent (in a VTMS transition the thread identity might not match the stack trace) >> - nothing guaranties that the result returned by this function remains the same upon return as `mount`/`unmount` of the target virtual thread can be executed concurrently: a mounted virtual thread can be quickly unmounted or an unmounted virtual thread can be quickly mounted >> >> So, it seems that this function is going to work correctly if used for target platform threads only or if the `JavaThread*` pointer is not really needed. Otherwise, the association with the `JavaThread` needs to be rechecked and its stability somehow guaranteed with any form of scheduling suspension or a VTMS transition disabler. > > The java_thread can be null because the carrier of a mounted vthread was not contained in the ThreadsListHandle. > > The only thing this function guarantees is that if the vthread appeared to have a carrier and that carrier is protected by the TLH, then the caller can safely interact with the carrier knowing it can't terminate - same as for regular threads. The caller has to account for the potential async mounting/unmounting of vthread - e.g. by handshaking the reported carrier and then confirming it is still the carrier. Note that `java_thread` may already be null so we don't get to execute line 836. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2228385947 From dholmes at openjdk.org Thu Jul 24 12:34:04 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 24 Jul 2025 12:34:04 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread [v2] In-Reply-To: References: Message-ID: On Thu, 24 Jul 2025 09:44:20 GMT, Serguei Spitsyn wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Move comment > > src/hotspot/share/runtime/threadSMR.cpp line 839: > >> 837: } >> 838: if (java_thread == nullptr) { >> 839: // Virtual thread was unmounted, or else carrier has now terminated. > > Nit: If `java_thread` for a virtual thread is null then this thread is unmounted. The words about the terminated carrier thread are confusing. > > I have one concern here. Nothing protects this code from facing some unexpected conditions as this function is racy with mounting and unmounting of target virtual thread > - this function can observe a `JavaThread` in `mount` or `unmount` transition where the thread identity of a `java.lang.Thread` associated with the `JavaThread` is not consistent (in a VTMS transition the thread identity might not match the stack trace) > - nothing guaranties that the result returned by this function remains the same upon return as `mount`/`unmount` of the target virtual thread can be executed concurrently: a mounted virtual thread can be quickly unmounted or an unmounted virtual thread can be quickly mounted > > So, it seems that this function is going to work correctly if used for target platform threads only or if the `JavaThread*` pointer is not really needed. Otherwise, the association with the `JavaThread` needs to be rechecked and its stability somehow guaranteed with any form of scheduling suspension or a VTMS transition disabler. The java_thread can be null because the carrier of a mounted vthread was not contained in the ThreadsListHandle. The only thing this function guarantees is that if the vthread appeared to have a carrier and that carrier is protected by the TLH, then the caller can safely interact with the carrier knowing it can't terminate - same as for regular threads. The caller has to account for the potential async mounting/unmounting of vthread - e.g. by handshaking the reported carrier and then confirming it is still the carrier. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2228382680 From mgronlun at openjdk.org Thu Jul 24 12:56:05 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 24 Jul 2025 12:56:05 GMT Subject: RFR: 8356587: Missing object ID X in pool jdk.types.Method Message-ID: Greetings, The following change set addresses the data loss resulting in the assertion "Missing object ID X in pool jdk.types.Method". It involves three components: 1. Address a regression introduced by [JDK-835221](https://bugs.openjdk.org/browse/JDK-8352251). By locating JFR_ONLY(Jfr::check_and_process_sample_request(thread);) before the global_poll() in SafepointMechanism::process(), a stacktrace can be captured, and artifacts tagged, during a safepoint. This breaks an invariant as artifacts, i.e. methods, can be tagged in the wrong epoch (also a stacktrace can be stored in the wrong epoch). Must be moved to post global_poll(). 2. Retransform/Redefine classes include a non-safe copy of Method trace flags, leading to stale bits being set onto the new Methods. Method trace flags need to be copied, but must be done under a safepoint. 3. It seems that there has been an increase in the frequency of issuing calls to InstanceKlass::purge_previous_versions(), making scratch klasses and old methods disappear before JFR gets the chance to serialize also tagged old methods. Therefore, we need to ensure that we always tag the latest version of a Method. There is also a cleanup of gratuitous type conversions, from Klass* to InstanceKlass* in the newly introduced MethodTracing subsystem. Testing: jdk_jfr, stress testing Thank you Markus ------------- Commit messages: - 8356587 Changes: https://git.openjdk.org/jdk/pull/26458/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26458&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356587 Stats: 304 lines in 23 files changed: 123 ins; 106 del; 75 mod Patch: https://git.openjdk.org/jdk/pull/26458.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26458/head:pull/26458 PR: https://git.openjdk.org/jdk/pull/26458 From sspitsyn at openjdk.org Thu Jul 24 15:47:55 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 24 Jul 2025 15:47:55 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread [v2] In-Reply-To: <91SlomOKdMCW1YfX3koOZAvoQbf-7kODO_rfZb_O_Ag=.83944b59-5a69-4f02-80d5-1eff1091ae29@github.com> References: <91SlomOKdMCW1YfX3koOZAvoQbf-7kODO_rfZb_O_Ag=.83944b59-5a69-4f02-80d5-1eff1091ae29@github.com> Message-ID: On Thu, 24 Jul 2025 12:31:04 GMT, David Holmes wrote: >> The java_thread can be null because the carrier of a mounted vthread was not contained in the ThreadsListHandle. >> >> The only thing this function guarantees is that if the vthread appeared to have a carrier and that carrier is protected by the TLH, then the caller can safely interact with the carrier knowing it can't terminate - same as for regular threads. The caller has to account for the potential async mounting/unmounting of vthread - e.g. by handshaking the reported carrier and then confirming it is still the carrier. > > Note that `java_thread` may already be null so we don't get to execute line 836. Thanks, David. The potential issue I'm still concerned about is that a subsequent handshaking can observe the JavaThread (and virtual thread as well) in a VTMS transition when there is no protection with a `VTMSTransitionDisabler`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2228896900 From mbaesken at openjdk.org Thu Jul 24 16:39:24 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 24 Jul 2025 16:39:24 GMT Subject: RFR: JDK-8030957 - AIX: Implement OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX In-Reply-To: References: Message-ID: On Tue, 20 May 2025 15:32:21 GMT, Suchismith Roy wrote: > JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957) > > These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created). > > getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo > > For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407) > > Once this issue has been resolved you should not forget to remove the two excludes from jdk/test/ProblemList.txt: > > com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all > com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all Are you sure the perfstat functionality is always available ? In HS we do dynamic resolution (see e.g. os_perf_aix.cpp), but maybe that was needed long time ago and is not really needed any more? But please check this . If we only address minimum AIX 7.2 we can probably simplify this approach or even go away from the current dynamic loading approach. See also https://bugs.openjdk.org/browse/JDK-8222719 where I did already some cleanup (but kept the AIX 7.1 vs. 7.2 ) . There is still an fflush(stdout); in UnixOperatingSystem.c - guess this is not needed any more? Maybe you can check the system tools you mentioned with 'trace' or 'tprof' or something similar to find out more about what they do and why they differ? src/jdk.management/aix/native/libmanagement_ext/UnixOperatingSystem.c line 57: > 55: > 56: ret = perfstat_cpu_total(NULL, &cpu_total, sizeof(perfstat_cpu_total_t), 1); > 57: if (ret <= 0) { I noticed that we check for retval < 0 in os_perf_aix.cpp, should we align this in some way ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-2896875648 PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3048932756 PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3056023114 PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3106958683 PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2099545296 From sroy at openjdk.org Thu Jul 24 16:39:24 2025 From: sroy at openjdk.org (Suchismith Roy) Date: Thu, 24 Jul 2025 16:39:24 GMT Subject: RFR: JDK-8030957 - AIX: Implement OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX In-Reply-To: References: Message-ID: On Wed, 21 May 2025 07:21:02 GMT, Matthias Baesken wrote: > Are you sure the perfstat functionality is always available ? In HS we do dynamic resolution (see e.g. os_perf_aix.cpp), but maybe that was needed long time ago and is not really needed any more? But please check this . I tried with a standalone program and did not face any issues. @MBaesken would it be possible for you to try this patch once to see if the load values are realistic / accurate ? Else if you can provide some use case that I can try. > There is still an fflush(stdout); in UnixOperatingSystem.c - guess this is not needed any more? @MBaesken we tried testing both semeru and temurin again system tools like nmon/topas but the values differ for both. This probably has something to do with how topas/nmon is working behind the hood.. Do you suggest any different test ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-2908856936 PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-2908858697 PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3103606269 From mbaesken at openjdk.org Thu Jul 24 16:39:24 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 24 Jul 2025 16:39:24 GMT Subject: RFR: JDK-8030957 - AIX: Implement OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX In-Reply-To: References: Message-ID: <5NK0FwuLj_FA4jAMxYYTJ2eqUF3reAx4y3EzhYe57Hc=.5652418f-6adb-4f58-8cc4-de3f362a3d9f@github.com> On Mon, 26 May 2025 07:39:59 GMT, Suchismith Roy wrote: > > Are you sure the perfstat functionality is always available ? In HS we do dynamic resolution (see e.g. os_perf_aix.cpp), but maybe that was needed long time ago and is not really needed any more? But please check this . > > I tried with a standalone program and did not face any issues. I was more thinking about different AIX machines setups/OS levels/installations. Is the perfstat functionality always there 'these days' ? > would it be possible for you to try this patch once to see if the load values are realistic / accurate ? Not 100% sure how, should we compare with values provided by other tools (system tools etc.) ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-2908902195 PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-2908903417 From sroy at openjdk.org Thu Jul 24 16:39:24 2025 From: sroy at openjdk.org (Suchismith Roy) Date: Thu, 24 Jul 2025 16:39:24 GMT Subject: RFR: JDK-8030957 - AIX: Implement OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX Message-ID: JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957) These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created). getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407) Once this issue has been resolved you should not forget to remove the two excludes from jdk/test/ProblemList.txt: com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all ------------- Commit messages: - Update UnixOperatingSystem.c - Merge branch 'openjdk:master' into cpuprocessload - cleanup - system cpu load - restore problem list - cpu process load Changes: https://git.openjdk.org/jdk/pull/25332/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25332&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8030957 Stats: 78 lines in 2 files changed: 72 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25332.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25332/head:pull/25332 PR: https://git.openjdk.org/jdk/pull/25332 From sroy at openjdk.org Thu Jul 24 16:39:25 2025 From: sroy at openjdk.org (Suchismith Roy) Date: Thu, 24 Jul 2025 16:39:25 GMT Subject: RFR: JDK-8030957 - AIX: Implement OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX In-Reply-To: <5NK0FwuLj_FA4jAMxYYTJ2eqUF3reAx4y3EzhYe57Hc=.5652418f-6adb-4f58-8cc4-de3f362a3d9f@github.com> References: <5NK0FwuLj_FA4jAMxYYTJ2eqUF3reAx4y3EzhYe57Hc=.5652418f-6adb-4f58-8cc4-de3f362a3d9f@github.com> Message-ID: On Mon, 26 May 2025 07:57:35 GMT, Matthias Baesken wrote: > > > Are you sure the perfstat functionality is always available ? In HS we do dynamic resolution (see e.g. os_perf_aix.cpp), but maybe that was needed long time ago and is not really needed any more? But please check this . > > > > > > I tried with a standalone program and did not face any issues. > > I was more thinking about different AIX machines setups/OS levels/installations. Is the perfstat functionality always there 'these days' ? Hi @MBaesken It seems perfstat is available since AIX 5. I see there is dynamic loading done in libperfstat.cpp. How to confirm if that is necessary ? I did not face issues in this program and also standalone C++ program on AIX 7.2 ------------- PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3045433644 From mbaesken at openjdk.org Thu Jul 24 16:39:25 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 24 Jul 2025 16:39:25 GMT Subject: RFR: JDK-8030957 - AIX: Implement OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX In-Reply-To: References: <5NK0FwuLj_FA4jAMxYYTJ2eqUF3reAx4y3EzhYe57Hc=.5652418f-6adb-4f58-8cc4-de3f362a3d9f@github.com> Message-ID: On Mon, 7 Jul 2025 14:30:49 GMT, Suchismith Roy wrote: > How to confirm if that is necessary ? I did not face issues in this program and also standalone C++ program on AIX 7.2 We did this not only because of (un)availability of libperfstat , but also to address different versions (with different functionality) of libperfstat at runtime. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3048921407 From sspitsyn at openjdk.org Thu Jul 24 17:37:53 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 24 Jul 2025 17:37:53 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread [v2] In-Reply-To: References: <91SlomOKdMCW1YfX3koOZAvoQbf-7kODO_rfZb_O_Ag=.83944b59-5a69-4f02-80d5-1eff1091ae29@github.com> Message-ID: On Thu, 24 Jul 2025 15:45:02 GMT, Serguei Spitsyn wrote: >> Note that `java_thread` may already be null so we don't get to execute line 836. > > Thanks, David. The potential issue I'm still concerned about is that a subsequent handshaking can also observe the JavaThread (and virtual thread as well) in a VTMS transition when there is no protection with a `VTMSTransitionDisabler`. > Note that java_thread may already be null so we don't get to execute line 836. Right. I guess, this answers my comment about the line 839. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2229142376 From dholmes at openjdk.org Thu Jul 24 20:37:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 24 Jul 2025 20:37:54 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread [v2] In-Reply-To: References: <91SlomOKdMCW1YfX3koOZAvoQbf-7kODO_rfZb_O_Ag=.83944b59-5a69-4f02-80d5-1eff1091ae29@github.com> Message-ID: On Thu, 24 Jul 2025 17:35:23 GMT, Serguei Spitsyn wrote: >> Thanks, David. The potential issue I'm still concerned about is that a subsequent handshaking can also observe the JavaThread (and virtual thread as well) in a VTMS transition when there is no protection with a `VTMSTransitionDisabler`. > >> Note that java_thread may already be null so we don't get to execute line 836. > > Right. I guess, this answers my comment about the line 839. Once in the handshake the carrier (and thus virtual thread) is "frozen" with regards to any transition. It could be anywhere in the process of mounting/unmounting (depending of course exactly where the carrier might respond to the handshake request), and the actual handshake operation has to deal with that. But that is true no matter how you extracted a reference to the carrier. As I said before the only thing this change guarantees is that the carrier is protected by the TLH and can't fully terminate whilst handshaking with it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2229522833 From alanb at openjdk.org Fri Jul 25 05:47:54 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 25 Jul 2025 05:47:54 GMT Subject: RFR: 8362304: Fix JDWP spec w.r.t. OPAQUE_FRAME and INVALID_SLOT errors [v2] In-Reply-To: References: <7AfNhcIuQyu2_RsHWcqupjsQ8WnT_eJRvnfI4seyCnQ=.55dfbd37-d226-4ee9-a53f-ee4a3b611a09@github.com> <9e4irEatV7hiVaIFKdHUq0AHNozfzEllM9bKJt6FJ7o=.e915af88-4fae-4e6e-a284-461f458d5b41@github.com> Message-ID: On Thu, 24 Jul 2025 05:43:16 GMT, Serguei Spitsyn wrote: > I think, this issue needs a Release Note, same as the JNI related enhancement. Not sure about the JVMTI related spec update as it has pure spec clarifications which do not have even minor compatibility issues. I agree. Also one release note to cover the 3 interfaces would be clearer than separate notes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26336#issuecomment-3116479805 From sspitsyn at openjdk.org Fri Jul 25 06:24:54 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 25 Jul 2025 06:24:54 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread [v2] In-Reply-To: References: Message-ID: On Tue, 22 Jul 2025 05:47:37 GMT, David Holmes wrote: >> The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads). >> >> It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed. >> >> Testing: >> - tiers 1-4 >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Move comment This looks okay to me. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26287#pullrequestreview-3054238698 From sspitsyn at openjdk.org Fri Jul 25 06:24:55 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 25 Jul 2025 06:24:55 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread [v2] In-Reply-To: References: <91SlomOKdMCW1YfX3koOZAvoQbf-7kODO_rfZb_O_Ag=.83944b59-5a69-4f02-80d5-1eff1091ae29@github.com> Message-ID: <5HvJlFh8C74DNdSsOd9GKizsC0He6Wkyfr_4cT_c0XI=.2b823eb0-3429-415c-a80e-af751bcf5923@github.com> On Thu, 24 Jul 2025 20:35:25 GMT, David Holmes wrote: >>> Note that java_thread may already be null so we don't get to execute line 836. >> >> Right. I guess, this answers my comment about the line 839. > > Once in the handshake the carrier (and thus virtual thread) is "frozen" with regards to any transition. It could be anywhere in the process of mounting/unmounting (depending of course exactly where the carrier might respond to the handshake request), and the actual handshake operation has to deal with that. But that is true no matter how you extracted a reference to the carrier. As I said before the only thing this change guarantees is that the carrier is protected by the TLH and can't fully terminate whilst handshaking with it. Okay, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2230252813 From dholmes at openjdk.org Fri Jul 25 06:41:56 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 25 Jul 2025 06:41:56 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread [v2] In-Reply-To: References: Message-ID: On Fri, 25 Jul 2025 06:21:56 GMT, Serguei Spitsyn wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Move comment > > This looks okay to me. Thanks for the review @sspitsyn ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26287#issuecomment-3116587591 From alanb at openjdk.org Fri Jul 25 07:08:55 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 25 Jul 2025 07:08:55 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread [v2] In-Reply-To: <5HvJlFh8C74DNdSsOd9GKizsC0He6Wkyfr_4cT_c0XI=.2b823eb0-3429-415c-a80e-af751bcf5923@github.com> References: <91SlomOKdMCW1YfX3koOZAvoQbf-7kODO_rfZb_O_Ag=.83944b59-5a69-4f02-80d5-1eff1091ae29@github.com> <5HvJlFh8C74DNdSsOd9GKizsC0He6Wkyfr_4cT_c0XI=.2b823eb0-3429-415c-a80e-af751bcf5923@github.com> Message-ID: On Fri, 25 Jul 2025 06:21:29 GMT, Serguei Spitsyn wrote: >> Once in the handshake the carrier (and thus virtual thread) is "frozen" with regards to any transition. It could be anywhere in the process of mounting/unmounting (depending of course exactly where the carrier might respond to the handshake request), and the actual handshake operation has to deal with that. But that is true no matter how you extracted a reference to the carrier. As I said before the only thing this change guarantees is that the carrier is protected by the TLH and can't fully terminate whilst handshaking with it. > > Okay, thanks. Once this change is in main line then we can sync'up the loom repo and work on the follow-up changes. The loom repo has changes (that are not in main line) for "suspending" an unmounted thread. For the mounted case then we'll need checks in the handshake to ensure that the expected virtual threads is mounted. We'll need stress tests of course and we can collaborate there in advance of proposing changes for main line. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2230330528 From mgronlun at openjdk.org Fri Jul 25 14:16:44 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 25 Jul 2025 14:16:44 GMT Subject: RFR: 8356587: Missing object ID X in pool jdk.types.Method [v2] In-Reply-To: References: Message-ID: > Greetings, > > The following change set addresses the data loss resulting in the assertion "Missing object ID X in pool jdk.types.Method". > > It involves three components: > > 1. Address a regression introduced by [JDK-835221](https://bugs.openjdk.org/browse/JDK-8352251). By locating JFR_ONLY(Jfr::check_and_process_sample_request(thread);) before the global_poll() in SafepointMechanism::process(), a stacktrace can be captured, and artifacts tagged, during a safepoint. This breaks an invariant as artifacts, i.e. methods, can be tagged in the wrong epoch (also a stacktrace can be stored in the wrong epoch). Must be moved to post global_poll(). > > 2. Retransform/Redefine classes include a non-safe copy of Method trace flags, leading to stale bits being set onto the new Methods. Method trace flags need to be copied, but must be done under a safepoint. > > 3. It seems that there has been an increase in the frequency of issuing calls to InstanceKlass::purge_previous_versions(), making scratch klasses and old methods disappear before JFR gets the chance to serialize also tagged old methods. Therefore, we need to ensure that we always tag the latest version of a Method. > > There is also a cleanup of gratuitous type conversions, from Klass* to InstanceKlass* in the newly introduced MethodTracing subsystem. > > Testing: jdk_jfr, stress testing > > Thank you > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: Must support AllowRedefinitionToAddDeleteMethods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26458/files - new: https://git.openjdk.org/jdk/pull/26458/files/4b77421b..a4d6ecc3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26458&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26458&range=00-01 Stats: 25 lines in 4 files changed: 16 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/26458.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26458/head:pull/26458 PR: https://git.openjdk.org/jdk/pull/26458 From duke at openjdk.org Fri Jul 25 16:10:32 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Fri, 25 Jul 2025 16:10:32 GMT Subject: RFR: 8364115: Sort share/services includes Message-ID: <_Cz--W3RLL1j-_xo0w3cW4jilOFzdZ_DFVBlWe_RdVU=.396a7d0d-3ee1-4902-ace2-6ab6b223264b@github.com> This PR sorts the includes in `hotspot/share/services` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`. Passes tier1. ------------- Commit messages: - sort includes Changes: https://git.openjdk.org/jdk/pull/26483/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26483&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364115 Stats: 43 lines in 12 files changed: 22 ins; 19 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26483.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26483/head:pull/26483 PR: https://git.openjdk.org/jdk/pull/26483 From pchilanomate at openjdk.org Fri Jul 25 16:24:54 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 25 Jul 2025 16:24:54 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread [v2] In-Reply-To: References: Message-ID: On Tue, 22 Jul 2025 05:47:37 GMT, David Holmes wrote: >> The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads). >> >> It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed. >> >> Testing: >> - tiers 1-4 >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Move comment LGTM. src/hotspot/share/runtime/threadSMR.hpp line 48: > 46: // perform an operation on a target thread. > 47: // > 48: // There two ways to refer to java.lang.Thread objects so we have two ways Nit: are ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26287#pullrequestreview-3056107193 PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2231550522 From dcubed at openjdk.org Fri Jul 25 18:08:59 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 25 Jul 2025 18:08:59 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread [v2] In-Reply-To: References: <91SlomOKdMCW1YfX3koOZAvoQbf-7kODO_rfZb_O_Ag=.83944b59-5a69-4f02-80d5-1eff1091ae29@github.com> <5HvJlFh8C74DNdSsOd9GKizsC0He6Wkyfr_4cT_c0XI=.2b823eb0-3429-415c-a80e-af751bcf5923@github.com> Message-ID: On Fri, 25 Jul 2025 07:05:55 GMT, Alan Bateman wrote: >> Okay, thanks. > > Once this change is in main line then we can sync'up the loom repo and work on the follow-up changes. The loom repo has changes (that are not in main line) for "suspending" an unmounted thread. For the mounted case then we'll need checks in the handshake to ensure that the expected virtual threads is mounted. We'll need stress tests of course and we can collaborate there in advance of proposing changes for main line. > Note that java_thread may already be null so we don't get to execute line 836. I'm having some trouble with this statement. Working backwards from L836, I see the nullptr check on L826 and the check for non-virtual thread and bail on L827 and L831. However, if we saw nullptr on L826 and we have a virtual thread, then we can get to L836 even when we started off with a null java_thread. So I guess I'm not sure what point you're trying to make with the statement. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2231702449 From dcubed at openjdk.org Fri Jul 25 18:09:00 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 25 Jul 2025 18:09:00 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread [v2] In-Reply-To: References: Message-ID: On Fri, 25 Jul 2025 16:21:57 GMT, Patricio Chilano Mateo wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Move comment > > src/hotspot/share/runtime/threadSMR.hpp line 48: > >> 46: // perform an operation on a target thread. >> 47: // >> 48: // There two ways to refer to java.lang.Thread objects so we have two ways > > Nit: are Just to be more clear: s/There two ways/There are two ways/ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2231707768 From dcubed at openjdk.org Fri Jul 25 18:08:58 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 25 Jul 2025 18:08:58 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread [v2] In-Reply-To: References: Message-ID: On Tue, 22 Jul 2025 05:47:37 GMT, David Holmes wrote: >> The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads). >> >> It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed. >> >> Testing: >> - tiers 1-4 >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Move comment Thumbs up on the changes. I think I only have a few nits. src/hotspot/share/prims/jvmtiExport.cpp line 871: > 869: // > 870: jvmtiError > 871: JvmtiExport::cv_oop_to_JavaThread(ThreadsList * t_list, oop thread_oop, When did `JvmtiExport::cv_oop_to_JavaThread` become unused? src/hotspot/share/runtime/threadSMR.cpp line 833: > 831: return false; > 832: } else { > 833: // For virtual thread's we need to extract the carrier's JavaThread - if any. nit typo: s/thread's/threads/ src/hotspot/share/runtime/threadSMR.hpp line 72: > 70: // : // do stuff with 'jt'... > 71: // > 72: // A JavaThread* that is included in the ThreadsList that is held by Why change just this location from `JavaThread *` to `JavaThread*`? There are other places that you touched that still use `JavaThread *`. src/hotspot/share/runtime/threadSMR.hpp line 310: > 308: inline Iterator end(); > 309: > 310: bool cv_internal_thread_to_JavaThread(jobject jthread, JavaThread** jt_pp, oop* thread_oop_p); I wish I could remember why in the world I put a space before the `*` when I did this code so very long ago... ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26287#pullrequestreview-3056275005 PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2231715585 PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2231668135 PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2231710443 PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2231713403 From cjplummer at openjdk.org Fri Jul 25 23:15:05 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 25 Jul 2025 23:15:05 GMT Subject: RFR: 8361873: [GCC static analyzer] exec_md.c forkedChildProcess potential double 'close' of file descriptor '3' Message-ID: <_Xf1QnVT5aJRUFI5kF9MwNB_xoFF8S0Q1Rcn8HCoTec=.02805f35-fd3a-4b91-b42d-bffa658686ba@github.com> Fix gcc warning about double close. forkedChildProcess() calls closeDescriptors(), which always closes STDERR_FILENO + 1 and STDERR_FILENO + 2. However, if it fails at some point after that, then forkedChildProcess() will attempt to close these same two files again. Fixed by making forkedChildProcess() no longer attempt to close these two files. I first verified the warning by configuring with --with-extra-cflags=-fanalyzer, and then verified the fix by doing the same. Tested by running jdi nsk test. I'll add some more CI testing. ------------- Commit messages: - fix gcc warning about double close() Changes: https://git.openjdk.org/jdk/pull/26487/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26487&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8361873 Stats: 9 lines in 1 file changed: 5 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26487.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26487/head:pull/26487 PR: https://git.openjdk.org/jdk/pull/26487 From sspitsyn at openjdk.org Sat Jul 26 08:14:56 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 26 Jul 2025 08:14:56 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread [v2] In-Reply-To: References: Message-ID: <2LosO9izz8w79NUa6EoEvSFe3w-umGreQM2whKyK_IY=.c5c7a643-c628-4a5c-919d-00b094f47116@github.com> On Fri, 25 Jul 2025 17:55:44 GMT, Daniel D. Daugherty wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Move comment > > src/hotspot/share/prims/jvmtiExport.cpp line 871: > >> 869: // >> 870: jvmtiError >> 871: JvmtiExport::cv_oop_to_JavaThread(ThreadsList * t_list, oop thread_oop, > > When did `JvmtiExport::cv_oop_to_JavaThread` become unused? To support virtual threads the JVMTI is using `JvmtiEnvBase::get_threadOop_and_JavaThread()` which in turn is using the `JvmtiExport::cv_external_thread_to_JavaThread()`. Also, the `JvmtiExport::cv_external_thread_to_JavaThread()` is used directly in some places. When the last usage of `JvmtiExport::cv_oop_to_JavaThread()` become unused I was not sure it is not needed anymore and left it alone. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2232788477 From jpai at openjdk.org Sun Jul 27 06:00:02 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 27 Jul 2025 06:00:02 GMT Subject: RFR: 8361873: [GCC static analyzer] exec_md.c forkedChildProcess potential double 'close' of file descriptor '3' In-Reply-To: <_Xf1QnVT5aJRUFI5kF9MwNB_xoFF8S0Q1Rcn8HCoTec=.02805f35-fd3a-4b91-b42d-bffa658686ba@github.com> References: <_Xf1QnVT5aJRUFI5kF9MwNB_xoFF8S0Q1Rcn8HCoTec=.02805f35-fd3a-4b91-b42d-bffa658686ba@github.com> Message-ID: On Fri, 25 Jul 2025 23:09:48 GMT, Chris Plummer wrote: > Fix gcc warning about double close. forkedChildProcess() calls closeDescriptors(), which always closes STDERR_FILENO + 1 and STDERR_FILENO + 2. However, if it fails at some point after that, then forkedChildProcess() will attempt to close these same two files again. Fixed by making forkedChildProcess() no longer attempt to close these two files. > > I first verified the warning by configuring with --with-extra-cflags=-fanalyzer, and then verified the fix by doing the same. > > Tested by running jdi nsk test. I'll add some more CI testing. This looks reasonable to me. I just have trivial comment about the code comment introduced in this change, which I've added inline. src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 82: > 80: * descriptors afresh. > 81: * > 82: * WARNING: We are not allowed to fail until after these two closes are Hello Chris, would it be better to word this as "We are not allowed to return from this function until after ...."? ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26487#pullrequestreview-3059210605 PR Review Comment: https://git.openjdk.org/jdk/pull/26487#discussion_r2233741615 From stuefe at openjdk.org Sun Jul 27 06:41:01 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sun, 27 Jul 2025 06:41:01 GMT Subject: RFR: 8361873: [GCC static analyzer] exec_md.c forkedChildProcess potential double 'close' of file descriptor '3' In-Reply-To: <_Xf1QnVT5aJRUFI5kF9MwNB_xoFF8S0Q1Rcn8HCoTec=.02805f35-fd3a-4b91-b42d-bffa658686ba@github.com> References: <_Xf1QnVT5aJRUFI5kF9MwNB_xoFF8S0Q1Rcn8HCoTec=.02805f35-fd3a-4b91-b42d-bffa658686ba@github.com> Message-ID: <5eryyx1Kj5NyBK1hYzkPH-HiMAsLkllNVtkJ8rDmr98=.a754d3bb-fa3d-42bc-80e2-714f4f795270@github.com> On Fri, 25 Jul 2025 23:09:48 GMT, Chris Plummer wrote: > Fix gcc warning about double close. forkedChildProcess() calls closeDescriptors(), which always closes STDERR_FILENO + 1 and STDERR_FILENO + 2. However, if it fails at some point after that, then forkedChildProcess() will attempt to close these same two files again. Fixed by making forkedChildProcess() no longer attempt to close these two files. > > I first verified the warning by configuring with --with-extra-cflags=-fanalyzer, and then verified the fix by doing the same. > > Tested by running jdi nsk test. I'll add some more CI testing. Looks good to me. Note that in the official Runtime.exec layer over in libjava, we switched to setting the filedescriptors to FD_CLOEXEC, which seems more elegant and circumvents this and some other problems. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26487#pullrequestreview-3059284460 From cjplummer at openjdk.org Sun Jul 27 18:24:29 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Sun, 27 Jul 2025 18:24:29 GMT Subject: RFR: 8361873: [GCC static analyzer] exec_md.c forkedChildProcess potential double 'close' of file descriptor '3' [v2] In-Reply-To: <_Xf1QnVT5aJRUFI5kF9MwNB_xoFF8S0Q1Rcn8HCoTec=.02805f35-fd3a-4b91-b42d-bffa658686ba@github.com> References: <_Xf1QnVT5aJRUFI5kF9MwNB_xoFF8S0Q1Rcn8HCoTec=.02805f35-fd3a-4b91-b42d-bffa658686ba@github.com> Message-ID: > Fix gcc warning about double close. forkedChildProcess() calls closeDescriptors(), which always closes STDERR_FILENO + 1 and STDERR_FILENO + 2. However, if it fails at some point after that, then forkedChildProcess() will attempt to close these same two files again. Fixed by making forkedChildProcess() no longer attempt to close these two files. > > I first verified the warning by configuring with --with-extra-cflags=-fanalyzer, and then verified the fix by doing the same. > > Tested by running jdi nsk test. I'll add some more CI testing. Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into 8361873_jdwp_close_fd Merge - fix gcc warning about double close() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26487/files - new: https://git.openjdk.org/jdk/pull/26487/files/088932e9..4095d6ce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26487&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26487&range=00-01 Stats: 106271 lines in 2540 files changed: 64936 ins; 26240 del; 15095 mod Patch: https://git.openjdk.org/jdk/pull/26487.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26487/head:pull/26487 PR: https://git.openjdk.org/jdk/pull/26487 From dholmes at openjdk.org Sun Jul 27 21:36:16 2025 From: dholmes at openjdk.org (David Holmes) Date: Sun, 27 Jul 2025 21:36:16 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread [v3] In-Reply-To: References: Message-ID: > The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads). > > It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed. > > Testing: > - tiers 1-4 > > Thanks David Holmes has updated the pull request incrementally with one additional commit since the last revision: Fix comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26287/files - new: https://git.openjdk.org/jdk/pull/26287/files/820f26e4..d863add5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26287&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26287&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26287.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26287/head:pull/26287 PR: https://git.openjdk.org/jdk/pull/26287 From dholmes at openjdk.org Sun Jul 27 21:36:16 2025 From: dholmes at openjdk.org (David Holmes) Date: Sun, 27 Jul 2025 21:36:16 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread [v2] In-Reply-To: References: Message-ID: On Fri, 25 Jul 2025 18:06:38 GMT, Daniel D. Daugherty wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Move comment > > Thumbs up on the changes. I think I only have a few nits. Thanks for the review @dcubed-ojdk ! Just need one Reviewer to re-review the nit fix-ups. Thanks > src/hotspot/share/runtime/threadSMR.cpp line 833: > >> 831: return false; >> 832: } else { >> 833: // For virtual thread's we need to extract the carrier's JavaThread - if any. > > nit typo: s/thread's/threads/ Fixed > src/hotspot/share/runtime/threadSMR.hpp line 72: > >> 70: // : // do stuff with 'jt'... >> 71: // >> 72: // A JavaThread* that is included in the ThreadsList that is held by > > Why change just this location from `JavaThread *` to `JavaThread*`? > There are other places that you touched that still use `JavaThread *`. I started changing them all but changed my mind - I missed reverting this one. Fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26287#issuecomment-3124739300 PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2234139881 PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2234140216 From dholmes at openjdk.org Sun Jul 27 21:36:17 2025 From: dholmes at openjdk.org (David Holmes) Date: Sun, 27 Jul 2025 21:36:17 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread [v2] In-Reply-To: References: <91SlomOKdMCW1YfX3koOZAvoQbf-7kODO_rfZb_O_Ag=.83944b59-5a69-4f02-80d5-1eff1091ae29@github.com> <5HvJlFh8C74DNdSsOd9GKizsC0He6Wkyfr_4cT_c0XI=.2b823eb0-3429-415c-a80e-af751bcf5923@github.com> Message-ID: <80FlQOBuyvlbfxMb8UqBH_G5Ur08BRhrpTKgis5KwyM=.c4bb00ab-3a22-4654-9ba5-60a0515c41d3@github.com> On Fri, 25 Jul 2025 17:48:01 GMT, Daniel D. Daugherty wrote: > then we can get to L836 even when we started off with a null java_thread. Sure. My point was more the other way round - we could have a null JavaThread without the null coming from line 836. The comment was just trying to expand on my previous comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2234139305 From dholmes at openjdk.org Sun Jul 27 21:36:17 2025 From: dholmes at openjdk.org (David Holmes) Date: Sun, 27 Jul 2025 21:36:17 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread [v2] In-Reply-To: References: Message-ID: On Fri, 25 Jul 2025 16:21:57 GMT, Patricio Chilano Mateo wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Move comment > > src/hotspot/share/runtime/threadSMR.hpp line 48: > >> 46: // perform an operation on a target thread. >> 47: // >> 48: // There two ways to refer to java.lang.Thread objects so we have two ways > > Nit: are Thanks for the review @pchilano ! Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2234139658 From sspitsyn at openjdk.org Mon Jul 28 06:35:42 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 28 Jul 2025 06:35:42 GMT Subject: RFR: 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired [v7] In-Reply-To: References: Message-ID: > The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a temporary backward compatibility flag under JDK-8192936 and was immediately marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in JDK 27. > > TBD: Need to submit a related CSR. > > There are two concerns which may require some negotiation with the Runtime (@coleenp @dcubed-ojdk @dholmes-ora) and SQE (@lmesnik) teams: > - Class redefinition/retransformation can impact lambda expressions which are supported with private methods > - Many tests depend on this VM option and are being removed. I'm not sure if it is okay to completely remove those e may want another way to handle this (e.g. problem-listing the impacted tests for now). > > Testing: > - mach5 tiers 1-6 are good > - may need to run mach5 tiers > 6 Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge - Merge - Merge - review: replace RESERVED flag with UNUSED - review: keep right order of the obsoleted VM options - corrected one assert message - 8358890: VM option -XX:AllowRedefinitionToAddDeleteMethods should be obsoleted then expired ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26232/files - new: https://git.openjdk.org/jdk/pull/26232/files/80fc70ec..0edab914 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26232&range=05-06 Stats: 14768 lines in 435 files changed: 7261 ins; 5653 del; 1854 mod Patch: https://git.openjdk.org/jdk/pull/26232.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26232/head:pull/26232 PR: https://git.openjdk.org/jdk/pull/26232 From sspitsyn at openjdk.org Mon Jul 28 06:38:36 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 28 Jul 2025 06:38:36 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException [v2] In-Reply-To: References: Message-ID: > If JVMTI `StopThread` is done when the thread is in certain various states (but not all states), after the `async` exception is delivered and handled, hotspot leaves the thread's `interrupted` flag set. The end result is the next time the thread does something like `Thread.sleep()`, it will immediately get an `InterruptedException`. > > The fix is to clear the `interrupted` flag in the `JavaThread::handle_async_exception()` after an `async` pending exception has been set to be thrown with the `set_pending_exception()`. > > There are a couple of concerns with this fix which would be nice to sort out with reviewers: > 1. The proposed fix may clear the interrupt state when it was already set prior to the issuing of the `StopThread()` (this concern was raised by @dholmes-ora in a comment of this JBS issue) > 2. The impacted code path is shared between the class `InstallAsyncExceptionHandshakeClosure` used by the JVMTI `StopThread` implementation and the class `ScopedAsyncExceptionHandshakeClosure` used by the `ScopedMemoryAccess` > > I feel that clearing the `interrupted` flag byt the `JavaThread::handle_async_exception()` is a right thing to do even though it was set before the call to `JavaThread::install_async_exception()`. Also, it has to be done for both `StopThread` and `ScopedMemoryAccess`. > > The fix also includes minor tweaks of the test `StopThreadTest` to make the issue reproducible with it. > > Testing: > - Mach5 tiers 1-6 are passed > - Ran the updated reproducer test `hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest` Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge - 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26365/files - new: https://git.openjdk.org/jdk/pull/26365/files/cd235460..8338fb55 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26365&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26365&range=00-01 Stats: 14768 lines in 435 files changed: 7261 ins; 5653 del; 1854 mod Patch: https://git.openjdk.org/jdk/pull/26365.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26365/head:pull/26365 PR: https://git.openjdk.org/jdk/pull/26365 From sspitsyn at openjdk.org Mon Jul 28 06:57:42 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 28 Jul 2025 06:57:42 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException [v3] In-Reply-To: References: Message-ID: > If JVMTI `StopThread` is done when the thread is in certain various states (but not all states), after the `async` exception is delivered and handled, hotspot leaves the thread's `interrupted` flag set. The end result is the next time the thread does something like `Thread.sleep()`, it will immediately get an `InterruptedException`. > > The fix is to clear the `interrupted` flag in the `JavaThread::handle_async_exception()` after an `async` pending exception has been set to be thrown with the `set_pending_exception()`. > > There are a couple of concerns with this fix which would be nice to sort out with reviewers: > 1. The proposed fix may clear the interrupt state when it was already set prior to the issuing of the `StopThread()` (this concern was raised by @dholmes-ora in a comment of this JBS issue) > 2. The impacted code path is shared between the class `InstallAsyncExceptionHandshakeClosure` used by the JVMTI `StopThread` implementation and the class `ScopedAsyncExceptionHandshakeClosure` used by the `ScopedMemoryAccess` > > I feel that clearing the `interrupted` flag byt the `JavaThread::handle_async_exception()` is a right thing to do even though it was set before the call to `JavaThread::install_async_exception()`. Also, it has to be done for both `StopThread` and `ScopedMemoryAccess`. > > The fix also includes minor tweaks of the test `StopThreadTest` to make the issue reproducible with it. > > Testing: > - Mach5 tiers 1-6 are passed > - Ran the updated reproducer test `hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest` Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: implemented a suggestion: do not set interrupt flag at all ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26365/files - new: https://git.openjdk.org/jdk/pull/26365/files/8338fb55..fde881f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26365&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26365&range=01-02 Stats: 8 lines in 1 file changed: 3 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26365.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26365/head:pull/26365 PR: https://git.openjdk.org/jdk/pull/26365 From sspitsyn at openjdk.org Mon Jul 28 07:01:58 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 28 Jul 2025 07:01:58 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException [v3] In-Reply-To: References: Message-ID: On Mon, 28 Jul 2025 06:57:42 GMT, Serguei Spitsyn wrote: >> If JVMTI `StopThread` is done when the thread is in certain various states (but not all states), after the `async` exception is delivered and handled, hotspot leaves the thread's `interrupted` flag set. The end result is the next time the thread does something like `Thread.sleep()`, it will immediately get an `InterruptedException`. >> >> The fix is to clear the `interrupted` flag in the `JavaThread::handle_async_exception()` after an `async` pending exception has been set to be thrown with the `set_pending_exception()`. >> >> There are a couple of concerns with this fix which would be nice to sort out with reviewers: >> 1. The proposed fix may clear the interrupt state when it was already set prior to the issuing of the `StopThread()` (this concern was raised by @dholmes-ora in a comment of this JBS issue) >> 2. The impacted code path is shared between the class `InstallAsyncExceptionHandshakeClosure` used by the JVMTI `StopThread` implementation and the class `ScopedAsyncExceptionHandshakeClosure` used by the `ScopedMemoryAccess` >> >> I feel that clearing the `interrupted` flag byt the `JavaThread::handle_async_exception()` is a right thing to do even though it was set before the call to `JavaThread::install_async_exception()`. Also, it has to be done for both `StopThread` and `ScopedMemoryAccess`. >> >> The fix also includes minor tweaks of the test `StopThreadTest` to make the issue reproducible with it. >> >> Testing: >> - Mach5 tiers 1-6 are passed >> - Ran the updated reproducer test `hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest` > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: implemented a suggestion: do not set interrupt flag at all I've implemented and pushed the suggestion from Patricio. The mach5 tiers 1-6 are clean. I'm not sure about correctness of the tweak in the `JavaThread::sleep_nanos()`: @@ -2122,6 +2117,9 @@ bool JavaThread::sleep_nanos(jlong nanos) { jlong nanos_remaining = nanos; for (;;) { + if (has_async_exception_condition()) { + return false; + } // interruption has precedence over timing out if (this->is_interrupted(true)) { return false; The mach5 tiers 1-6 tests are all passed without this tweak. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3125809023 From alanb at openjdk.org Mon Jul 28 10:52:58 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 28 Jul 2025 10:52:58 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException [v3] In-Reply-To: References: Message-ID: <2faiO8M1kDjt63rmbo8EjfXOxA5ggxcpHp4S3Ok3S2A=.b85da477-0c63-47a2-aac8-988254863fd4@github.com> On Mon, 28 Jul 2025 06:58:50 GMT, Serguei Spitsyn wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: implemented a suggestion: do not set interrupt flag at all > > I've implemented and pushed the suggestion from Patricio. The mach5 tiers 1-6 are clean. > I'm not sure about correctness of the tweak in the `JavaThread::sleep_nanos()`: > > @@ -2122,6 +2117,9 @@ bool JavaThread::sleep_nanos(jlong nanos) { > jlong nanos_remaining = nanos; > > for (;;) { > + if (has_async_exception_condition()) { > + return false; > + } > // interruption has precedence over timing out > if (this->is_interrupted(true)) { > return false; > > The mach5 tiers 1-6 tests are all passed without this tweak. > > @sspitsyn It might be useful to reach out to the IDEs to see what they are doing. From a quick test with IntelliJ then it appears to invoke both StopThread and InterruptThread when "Exception to Throw" is used. In that case, it means that Thread.sleep will wakeup, even if StopThread doesn't interrupt. > > Good suggestion, thanks. It would put the onus on the debugger to interrupt, which I think is the right thing to do. it would remove the interrupt from JavaThread::install_async_exception and would mean no change to JavaThread::sleep_nanos. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3126657391 From mgronlun at openjdk.org Mon Jul 28 11:06:10 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 28 Jul 2025 11:06:10 GMT Subject: RFR: 8356587: Missing object ID X in pool jdk.types.Method [v3] In-Reply-To: References: Message-ID: > Greetings, > > The following change set addresses the data loss resulting in the assertion "Missing object ID X in pool jdk.types.Method". > > It involves three components: > > 1. Address a regression introduced by [JDK-835221](https://bugs.openjdk.org/browse/JDK-8352251). By locating JFR_ONLY(Jfr::check_and_process_sample_request(thread);) before the global_poll() in SafepointMechanism::process(), a stacktrace can be captured, and artifacts tagged, during a safepoint. This breaks an invariant as artifacts, i.e. methods, can be tagged in the wrong epoch (also a stacktrace can be stored in the wrong epoch). Must be moved to post global_poll(). > > 2. Retransform/Redefine classes include a non-safe copy of Method trace flags, leading to stale bits being set onto the new Methods. Method trace flags need to be copied, but must be done under a safepoint. > > 3. It seems that there has been an increase in the frequency of issuing calls to InstanceKlass::purge_previous_versions(), making scratch klasses and old methods disappear before JFR gets the chance to serialize also tagged old methods. Therefore, we need to ensure that we always tag the latest version of a Method. > > There is also a cleanup of gratuitous type conversions, from Klass* to InstanceKlass* in the newly introduced MethodTracing subsystem. > > Testing: jdk_jfr, stress testing > > Thank you > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: improved predicate ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26458/files - new: https://git.openjdk.org/jdk/pull/26458/files/a4d6ecc3..933a2261 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26458&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26458&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26458.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26458/head:pull/26458 PR: https://git.openjdk.org/jdk/pull/26458 From clanger at openjdk.org Mon Jul 28 13:19:00 2025 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 28 Jul 2025 13:19:00 GMT Subject: RFR: 8362482: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java: System.gc() does not provide full GC In-Reply-To: <3kKyvSopVJNqmnOvWvycADtzAFFcB9lo3wFqJ8OQqEE=.169604ff-8ae9-4d39-85e7-8c9cc69add5b@github.com> References: <3kKyvSopVJNqmnOvWvycADtzAFFcB9lo3wFqJ8OQqEE=.169604ff-8ae9-4d39-85e7-8c9cc69add5b@github.com> Message-ID: On Thu, 17 Jul 2025 09:58:34 GMT, Richard Reingruber wrote: > Call WhiteBox.fullGC() instead of System.gc() for a guaranteed full GC. > It is assumed that one full GC is sufficient for these tests. > > Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. Marked as reviewed by clanger (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26363#pullrequestreview-3062656908 From rrich at openjdk.org Mon Jul 28 13:19:00 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Mon, 28 Jul 2025 13:19:00 GMT Subject: RFR: 8362482: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java: System.gc() does not provide full GC In-Reply-To: <3kKyvSopVJNqmnOvWvycADtzAFFcB9lo3wFqJ8OQqEE=.169604ff-8ae9-4d39-85e7-8c9cc69add5b@github.com> References: <3kKyvSopVJNqmnOvWvycADtzAFFcB9lo3wFqJ8OQqEE=.169604ff-8ae9-4d39-85e7-8c9cc69add5b@github.com> Message-ID: On Thu, 17 Jul 2025 09:58:34 GMT, Richard Reingruber wrote: > Call WhiteBox.fullGC() instead of System.gc() for a guaranteed full GC. > It is assumed that one full GC is sufficient for these tests. > > Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26363#issuecomment-3127198845 From rrich at openjdk.org Mon Jul 28 13:19:01 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Mon, 28 Jul 2025 13:19:01 GMT Subject: Integrated: 8362482: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java: System.gc() does not provide full GC In-Reply-To: <3kKyvSopVJNqmnOvWvycADtzAFFcB9lo3wFqJ8OQqEE=.169604ff-8ae9-4d39-85e7-8c9cc69add5b@github.com> References: <3kKyvSopVJNqmnOvWvycADtzAFFcB9lo3wFqJ8OQqEE=.169604ff-8ae9-4d39-85e7-8c9cc69add5b@github.com> Message-ID: <_3zNdsKh97gguIrIA7YabPYrtl7nPkXkJSEoE0iswzk=.9ee12440-c50e-4663-9b6d-26a836c9d2cb@github.com> On Thu, 17 Jul 2025 09:58:34 GMT, Richard Reingruber wrote: > Call WhiteBox.fullGC() instead of System.gc() for a guaranteed full GC. > It is assumed that one full GC is sufficient for these tests. > > Testing was done with fastdebug and release builds on the main platforms and also on Linux/PPC64le and AIX. This pull request has now been integrated. Changeset: b4028c91 Author: Richard Reingruber URL: https://git.openjdk.org/jdk/commit/b4028c91d5615f43cbf209eeeb1014966de22a38 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod 8362482: [TESTBUG] serviceability/HeapDump/UnmountedVThreadNativeMethodAtTop.java: System.gc() does not provide full GC Reviewed-by: sspitsyn, clanger ------------- PR: https://git.openjdk.org/jdk/pull/26363 From mbaesken at openjdk.org Mon Jul 28 14:12:58 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 28 Jul 2025 14:12:58 GMT Subject: RFR: 8361873: [GCC static analyzer] exec_md.c forkedChildProcess potential double 'close' of file descriptor '3' [v2] In-Reply-To: References: <_Xf1QnVT5aJRUFI5kF9MwNB_xoFF8S0Q1Rcn8HCoTec=.02805f35-fd3a-4b91-b42d-bffa658686ba@github.com> Message-ID: On Sun, 27 Jul 2025 18:24:29 GMT, Chris Plummer wrote: >> Fix gcc warning about double close. forkedChildProcess() calls closeDescriptors(), which always closes STDERR_FILENO + 1 and STDERR_FILENO + 2. However, if it fails at some point after that, then forkedChildProcess() will attempt to close these same two files again. Fixed by making forkedChildProcess() no longer attempt to close these two files. >> >> I first verified the warning by configuring with --with-extra-cflags=-fanalyzer, and then verified the fix by doing the same. >> >> Tested by running jdi nsk test. I'll add some more CI testing. > > Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into 8361873_jdwp_close_fd > Merge > - fix gcc warning about double close() Marked as reviewed by mbaesken (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26487#pullrequestreview-3062973047 From duke at openjdk.org Mon Jul 28 14:41:25 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Mon, 28 Jul 2025 14:41:25 GMT Subject: RFR: 8364115: Sort share/services includes [v2] In-Reply-To: <_Cz--W3RLL1j-_xo0w3cW4jilOFzdZ_DFVBlWe_RdVU=.396a7d0d-3ee1-4902-ace2-6ab6b223264b@github.com> References: <_Cz--W3RLL1j-_xo0w3cW4jilOFzdZ_DFVBlWe_RdVU=.396a7d0d-3ee1-4902-ace2-6ab6b223264b@github.com> Message-ID: > This PR sorts the includes in `hotspot/share/services` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`. > > Passes tier1. Francesco Andreuzzi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into JDK-8364115 - sort includes ------------- Changes: https://git.openjdk.org/jdk/pull/26483/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26483&range=01 Stats: 42 lines in 12 files changed: 22 ins; 19 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26483.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26483/head:pull/26483 PR: https://git.openjdk.org/jdk/pull/26483 From mgronlun at openjdk.org Mon Jul 28 14:49:32 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 28 Jul 2025 14:49:32 GMT Subject: RFR: 8356587: Missing object ID X in pool jdk.types.Method [v4] In-Reply-To: References: Message-ID: <54d5GvjbJF3AXWowzkFC4HF11OFyHl3Dw41LpKE7ng4=.87fab246-f64a-4d0f-a62e-4314298065a5@github.com> > Greetings, > > The following change set addresses the data loss resulting in the assertion "Missing object ID X in pool jdk.types.Method". > > It involves three components: > > 1. Address a regression introduced by [JDK-835221](https://bugs.openjdk.org/browse/JDK-8352251). By locating JFR_ONLY(Jfr::check_and_process_sample_request(thread);) before the global_poll() in SafepointMechanism::process(), a stacktrace can be captured, and artifacts tagged, during a safepoint. This breaks an invariant as artifacts, i.e. methods, can be tagged in the wrong epoch (also a stacktrace can be stored in the wrong epoch). Must be moved to post global_poll(). > > 2. Retransform/Redefine classes include a non-safe copy of Method trace flags, leading to stale bits being set onto the new Methods. Method trace flags need to be copied, but must be done under a safepoint. > > 3. It seems that there has been an increase in the frequency of issuing calls to InstanceKlass::purge_previous_versions(), making scratch klasses and old methods disappear before JFR gets the chance to serialize also tagged old methods. Therefore, we need to ensure that we always tag the latest version of a Method. > > There is also a cleanup of gratuitous type conversions, from Klass* to InstanceKlass* in the newly introduced MethodTracing subsystem. > > Testing: jdk_jfr, stress testing > > Thank you > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: always use new_methods length ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26458/files - new: https://git.openjdk.org/jdk/pull/26458/files/933a2261..e68e9f3c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26458&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26458&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26458.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26458/head:pull/26458 PR: https://git.openjdk.org/jdk/pull/26458 From mgronlun at openjdk.org Mon Jul 28 14:53:34 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 28 Jul 2025 14:53:34 GMT Subject: RFR: 8356587: Missing object ID X in pool jdk.types.Method [v5] In-Reply-To: References: Message-ID: > Greetings, > > The following change set addresses the data loss resulting in the assertion "Missing object ID X in pool jdk.types.Method". > > It involves three components: > > 1. Address a regression introduced by [JDK-835221](https://bugs.openjdk.org/browse/JDK-8352251). By locating JFR_ONLY(Jfr::check_and_process_sample_request(thread);) before the global_poll() in SafepointMechanism::process(), a stacktrace can be captured, and artifacts tagged, during a safepoint. This breaks an invariant as artifacts, i.e. methods, can be tagged in the wrong epoch (also a stacktrace can be stored in the wrong epoch). Must be moved to post global_poll(). > > 2. Retransform/Redefine classes include a non-safe copy of Method trace flags, leading to stale bits being set onto the new Methods. Method trace flags need to be copied, but must be done under a safepoint. > > 3. It seems that there has been an increase in the frequency of issuing calls to InstanceKlass::purge_previous_versions(), making scratch klasses and old methods disappear before JFR gets the chance to serialize also tagged old methods. Therefore, we need to ensure that we always tag the latest version of a Method. > > There is also a cleanup of gratuitous type conversions, from Klass* to InstanceKlass* in the newly introduced MethodTracing subsystem. > > Testing: jdk_jfr, stress testing > > Thank you > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: removed unused ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26458/files - new: https://git.openjdk.org/jdk/pull/26458/files/e68e9f3c..6504e1b7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26458&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26458&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26458.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26458/head:pull/26458 PR: https://git.openjdk.org/jdk/pull/26458 From egahlin at openjdk.org Mon Jul 28 15:06:57 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Mon, 28 Jul 2025 15:06:57 GMT Subject: RFR: 8356587: Missing object ID X in pool jdk.types.Method [v5] In-Reply-To: References: Message-ID: On Mon, 28 Jul 2025 14:53:34 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> The following change set addresses the data loss resulting in the assertion "Missing object ID X in pool jdk.types.Method". >> >> It involves three components: >> >> 1. Address a regression introduced by [JDK-835221](https://bugs.openjdk.org/browse/JDK-8352251). By locating JFR_ONLY(Jfr::check_and_process_sample_request(thread);) before the global_poll() in SafepointMechanism::process(), a stacktrace can be captured, and artifacts tagged, during a safepoint. This breaks an invariant as artifacts, i.e. methods, can be tagged in the wrong epoch (also a stacktrace can be stored in the wrong epoch). Must be moved to post global_poll(). >> >> 2. Retransform/Redefine classes include a non-safe copy of Method trace flags, leading to stale bits being set onto the new Methods. Method trace flags need to be copied, but must be done under a safepoint. >> >> 3. It seems that there has been an increase in the frequency of issuing calls to InstanceKlass::purge_previous_versions(), making scratch klasses and old methods disappear before JFR gets the chance to serialize also tagged old methods. Therefore, we need to ensure that we always tag the latest version of a Method. >> >> There is also a cleanup of gratuitous type conversions, from Klass* to InstanceKlass* in the newly introduced MethodTracing subsystem. >> >> Testing: jdk_jfr, stress testing >> >> Thank you >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > removed unused Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26458#pullrequestreview-3063256275 From cjplummer at openjdk.org Mon Jul 28 16:01:56 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 28 Jul 2025 16:01:56 GMT Subject: RFR: 8361873: [GCC static analyzer] exec_md.c forkedChildProcess potential double 'close' of file descriptor '3' [v2] In-Reply-To: References: <_Xf1QnVT5aJRUFI5kF9MwNB_xoFF8S0Q1Rcn8HCoTec=.02805f35-fd3a-4b91-b42d-bffa658686ba@github.com> Message-ID: On Sun, 27 Jul 2025 05:56:51 GMT, Jaikiran Pai wrote: >> Chris Plummer has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' into 8361873_jdwp_close_fd >> Merge >> - fix gcc warning about double close() > > src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c line 82: > >> 80: * descriptors afresh. >> 81: * >> 82: * WARNING: We are not allowed to fail until after these two closes are > > Hello Chris, would it be better to word this as "We are not allowed to return from this function until after ...."? The issue is returning with a failure, not simply returning early, although it should only ever return early if there is a failure. I can change "not allowed to fail" with "not allowed to return with a failure" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26487#discussion_r2237077081 From jpai at openjdk.org Mon Jul 28 16:07:54 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 28 Jul 2025 16:07:54 GMT Subject: RFR: 8361873: [GCC static analyzer] exec_md.c forkedChildProcess potential double 'close' of file descriptor '3' [v2] In-Reply-To: References: <_Xf1QnVT5aJRUFI5kF9MwNB_xoFF8S0Q1Rcn8HCoTec=.02805f35-fd3a-4b91-b42d-bffa658686ba@github.com> Message-ID: On Mon, 28 Jul 2025 15:59:01 GMT, Chris Plummer wrote: > I can change "not allowed to fail" with "not allowed to return with a failure" That sounds good to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26487#discussion_r2237100428 From cjplummer at openjdk.org Mon Jul 28 16:18:44 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 28 Jul 2025 16:18:44 GMT Subject: RFR: 8361873: [GCC static analyzer] exec_md.c forkedChildProcess potential double 'close' of file descriptor '3' [v3] In-Reply-To: <_Xf1QnVT5aJRUFI5kF9MwNB_xoFF8S0Q1Rcn8HCoTec=.02805f35-fd3a-4b91-b42d-bffa658686ba@github.com> References: <_Xf1QnVT5aJRUFI5kF9MwNB_xoFF8S0Q1Rcn8HCoTec=.02805f35-fd3a-4b91-b42d-bffa658686ba@github.com> Message-ID: <9XDiWo_GdRo5FZyEIeQ5yo9ySoqBrp6gbqK6tv3HbHk=.66869696-202a-4b98-96ea-4034f38c07b8@github.com> > Fix gcc warning about double close. forkedChildProcess() calls closeDescriptors(), which always closes STDERR_FILENO + 1 and STDERR_FILENO + 2. However, if it fails at some point after that, then forkedChildProcess() will attempt to close these same two files again. Fixed by making forkedChildProcess() no longer attempt to close these two files. > > I first verified the warning by configuring with --with-extra-cflags=-fanalyzer, and then verified the fix by doing the same. > > Tested by running jdi nsk test. I'll add some more CI testing. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Update comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26487/files - new: https://git.openjdk.org/jdk/pull/26487/files/4095d6ce..49ca5abb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26487&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26487&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26487.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26487/head:pull/26487 PR: https://git.openjdk.org/jdk/pull/26487 From cjplummer at openjdk.org Mon Jul 28 16:18:45 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 28 Jul 2025 16:18:45 GMT Subject: RFR: 8361873: [GCC static analyzer] exec_md.c forkedChildProcess potential double 'close' of file descriptor '3' [v2] In-Reply-To: <5eryyx1Kj5NyBK1hYzkPH-HiMAsLkllNVtkJ8rDmr98=.a754d3bb-fa3d-42bc-80e2-714f4f795270@github.com> References: <_Xf1QnVT5aJRUFI5kF9MwNB_xoFF8S0Q1Rcn8HCoTec=.02805f35-fd3a-4b91-b42d-bffa658686ba@github.com> <5eryyx1Kj5NyBK1hYzkPH-HiMAsLkllNVtkJ8rDmr98=.a754d3bb-fa3d-42bc-80e2-714f4f795270@github.com> Message-ID: On Sun, 27 Jul 2025 06:38:34 GMT, Thomas Stuefe wrote: > Note that in the official Runtime.exec layer over in libjava, we switched to setting the filedescriptors to FD_CLOEXEC, which seems more elegant and circumvents this and some other problems. Are you talking about what is being done in os::open()? What about opens done that don't go through os::open() such as opens from app native code? In any case, I think this is beyond the scope of this PR. Maybe an RFE could be filed for it if you think it is worth doing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26487#issuecomment-3127975427 From jpai at openjdk.org Mon Jul 28 16:25:53 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 28 Jul 2025 16:25:53 GMT Subject: RFR: 8361873: [GCC static analyzer] exec_md.c forkedChildProcess potential double 'close' of file descriptor '3' [v3] In-Reply-To: <9XDiWo_GdRo5FZyEIeQ5yo9ySoqBrp6gbqK6tv3HbHk=.66869696-202a-4b98-96ea-4034f38c07b8@github.com> References: <_Xf1QnVT5aJRUFI5kF9MwNB_xoFF8S0Q1Rcn8HCoTec=.02805f35-fd3a-4b91-b42d-bffa658686ba@github.com> <9XDiWo_GdRo5FZyEIeQ5yo9ySoqBrp6gbqK6tv3HbHk=.66869696-202a-4b98-96ea-4034f38c07b8@github.com> Message-ID: On Mon, 28 Jul 2025 16:18:44 GMT, Chris Plummer wrote: >> Fix gcc warning about double close. forkedChildProcess() calls closeDescriptors(), which always closes STDERR_FILENO + 1 and STDERR_FILENO + 2. However, if it fails at some point after that, then forkedChildProcess() will attempt to close these same two files again. Fixed by making forkedChildProcess() no longer attempt to close these two files. >> >> I first verified the warning by configuring with --with-extra-cflags=-fanalyzer, and then verified the fix by doing the same. >> >> Tested by running jdi nsk test. I'll add some more CI testing. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Update comment Thank you Chris for the update. This looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26487#pullrequestreview-3063650779 From pchilanomate at openjdk.org Mon Jul 28 21:52:55 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 28 Jul 2025 21:52:55 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread [v3] In-Reply-To: References: Message-ID: On Sun, 27 Jul 2025 21:36:16 GMT, David Holmes wrote: >> The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads). >> >> It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed. >> >> Testing: >> - tiers 1-4 >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments Marked as reviewed by pchilanomate (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26287#pullrequestreview-3064697749 From dcubed at openjdk.org Mon Jul 28 22:03:55 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 28 Jul 2025 22:03:55 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread [v3] In-Reply-To: References: Message-ID: On Sun, 27 Jul 2025 21:36:16 GMT, David Holmes wrote: >> The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads). >> >> It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed. >> >> Testing: >> - tiers 1-4 >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments Thanks for the updates. Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26287#pullrequestreview-3064713285 From dcubed at openjdk.org Mon Jul 28 22:03:56 2025 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 28 Jul 2025 22:03:56 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread [v2] In-Reply-To: <80FlQOBuyvlbfxMb8UqBH_G5Ur08BRhrpTKgis5KwyM=.c4bb00ab-3a22-4654-9ba5-60a0515c41d3@github.com> References: <91SlomOKdMCW1YfX3koOZAvoQbf-7kODO_rfZb_O_Ag=.83944b59-5a69-4f02-80d5-1eff1091ae29@github.com> <5HvJlFh8C74DNdSsOd9GKizsC0He6Wkyfr_4cT_c0XI=.2b823eb0-3429-415c-a80e-af751bcf5923@github.com> <80FlQOBuyvlbfxMb8UqBH_G5Ur08BRhrpTKgis5KwyM=.c4bb00ab-3a22-4654-9ba5-60a0515c41d3@github.com> Message-ID: On Sun, 27 Jul 2025 21:27:40 GMT, David Holmes wrote: >>> Note that java_thread may already be null so we don't get to execute line 836. >> >> I'm having some trouble with this statement. Working backwards from L836, I see >> the nullptr check on L826 and the check for non-virtual thread and bail on L827 >> and L831. However, if we saw nullptr on L826 and we have a virtual thread, then >> we can get to L836 even when we started off with a null java_thread. >> >> So I guess I'm not sure what point you're trying to make with the statement. > >> then we can get to L836 even when we started off with a null java_thread. > > Sure. My point was more the other way round - we could have a null JavaThread without the null coming from line 836. > > The comment was just trying to expand on my previous comment. Thanks for the clarification. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26287#discussion_r2237939518 From cjplummer at openjdk.org Mon Jul 28 23:09:03 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 28 Jul 2025 23:09:03 GMT Subject: RFR: 8309400: JDI spec needs to clarify when OpaqueFrameException and NativeMethodException are thrown [v3] In-Reply-To: References: Message-ID: On Fri, 18 Jul 2025 23:55:44 GMT, Chris Plummer wrote: >> Fix how ThreadReference.popFrame() and ThreadReference.forceEarlyReturn deal with JDWP OPAQUE_FRAME error. >> >> Before virtual threads, OpaqueFrameException did not exist and these API always threw NativeMethodException when JDWP OPAQUE_FRAME error was returned. For virtual threads OpaqueFrameException was added to handle the case where a virtual thread was not suspended at an event, so the JDI implementation was updated to throw OpaqueFrameException if it detected that a native method was not the cause. It turns out however that JVMTI (and therefore JDWP) can return OPAQUE_FRAME error for reasons other than a native method or the special virtual thread case, and for platform threads we were incorrectly throwing NativeMethodException in these cases. This PR fixes that. For platform threads we now only throw NativeMethodException if a native method is detected, and otherwise throw OpaqueFrameException. >> >> The spec language is also being cleaned up to better align with JVMTI. Rather than calling out all the reasons for OpaqueFrameException, a more generic explanation is given. >> >> This is somewhat of a preliminary PR so I can get some feedback. I still need to do a CSR and complete testing. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > minor rewording The CSR is now ready for review: [JDK-8363896](https://bugs.openjdk.org/browse/JDK-8363896): ------------- PR Comment: https://git.openjdk.org/jdk/pull/26335#issuecomment-3130063409 From dholmes at openjdk.org Mon Jul 28 23:56:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 28 Jul 2025 23:56:54 GMT Subject: RFR: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread [v3] In-Reply-To: References: Message-ID: On Sun, 27 Jul 2025 21:36:16 GMT, David Holmes wrote: >> The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads). >> >> It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed. >> >> Testing: >> - tiers 1-4 >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments Thanks Dan! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26287#issuecomment-3130141978 From dholmes at openjdk.org Mon Jul 28 23:56:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 28 Jul 2025 23:56:54 GMT Subject: Integrated: 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread In-Reply-To: References: Message-ID: On Mon, 14 Jul 2025 05:34:57 GMT, David Holmes wrote: > The `cv_internal_thread_to_JavaThread` method will now check if the thread is a mounted virtual thread, and if so protect the carrier thread. User's of the API that need to deal with virtual threads must still check the carrier themselves as it could change asynchronously, but it is now guaranteed that the carrier JavaThread returned via this method cannot terminate whilst being used (the same as regular platform JavaThreads). > > It was noticed whilst updating the documentation that the `JvmtiExport` variant `cv_oop_to_JavaThread` is unused and so can be removed. > > Testing: > - tiers 1-4 > > Thanks This pull request has now been integrated. Changeset: 46690051 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/4669005123420d8dbe86740dd9bcbee04735bc4f Stats: 84 lines in 4 files changed: 18 ins; 54 del; 12 mod 8361912: ThreadsListHandle::cv_internal_thread_to_JavaThread does not deal with a virtual thread's carrier thread Reviewed-by: pchilanomate, dcubed, amenkov, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/26287 From duke at openjdk.org Tue Jul 29 02:26:08 2025 From: duke at openjdk.org (Lei Zhu) Date: Tue, 29 Jul 2025 02:26:08 GMT Subject: RFR: 8363920: JVMTI Documentation for GetLocalDouble is wrong: refers to long Message-ID: Hi all, Fixed type errors in documentation, minor changes. Thanks! ------------- Commit messages: - 8363920: JVMTI Documentation for GetLocalDouble is wrong: refers to long Changes: https://git.openjdk.org/jdk/pull/26521/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26521&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8363920 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26521.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26521/head:pull/26521 PR: https://git.openjdk.org/jdk/pull/26521 From alanb at openjdk.org Tue Jul 29 06:22:59 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 29 Jul 2025 06:22:59 GMT Subject: RFR: 8363920: JVMTI Documentation for GetLocalDouble is wrong: refers to long In-Reply-To: References: Message-ID: On Tue, 29 Jul 2025 02:20:56 GMT, Lei Zhu wrote: > Hi all, > > Fixed type errors in documentation, minor changes. > > Thanks! Good spot, a long standing copy and paste issue it seems. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26521#pullrequestreview-3065673109 From stuefe at openjdk.org Tue Jul 29 06:25:55 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 29 Jul 2025 06:25:55 GMT Subject: RFR: 8361873: [GCC static analyzer] exec_md.c forkedChildProcess potential double 'close' of file descriptor '3' [v2] In-Reply-To: References: <_Xf1QnVT5aJRUFI5kF9MwNB_xoFF8S0Q1Rcn8HCoTec=.02805f35-fd3a-4b91-b42d-bffa658686ba@github.com> <5eryyx1Kj5NyBK1hYzkPH-HiMAsLkllNVtkJ8rDmr98=.a754d3bb-fa3d-42bc-80e2-714f4f795270@github.com> Message-ID: On Mon, 28 Jul 2025 16:13:04 GMT, Chris Plummer wrote: > > Note that in the official Runtime.exec layer over in libjava, we switched to setting the filedescriptors to FD_CLOEXEC, which seems more elegant and circumvents this and some other problems. > > Are you talking about what is being done in os::open()? What about opens done that don't go through os::open() such as opens from app native code? No, I am talking about this: https://github.com/openjdk/jdk/blob/4669005123420d8dbe86740dd9bcbee04735bc4f/src/java.base/unix/native/libjava/childproc.c#L109 where we close all file descriptors apart from the ones we need to communicate to the jspawnhelper. > > In any case, I think this is beyond the scope of this PR. Maybe an RFE could be filed for it if you think it is worth doing. Sure thing ------------- PR Comment: https://git.openjdk.org/jdk/pull/26487#issuecomment-3130861629 From dholmes at openjdk.org Tue Jul 29 07:08:59 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 29 Jul 2025 07:08:59 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException [v3] In-Reply-To: References: Message-ID: On Mon, 28 Jul 2025 06:57:42 GMT, Serguei Spitsyn wrote: >> If JVMTI `StopThread` is done when the thread is in certain various states (but not all states), after the `async` exception is delivered and handled, hotspot leaves the thread's `interrupted` flag set. The end result is the next time the thread does something like `Thread.sleep()`, it will immediately get an `InterruptedException`. >> >> The fix is to clear the `interrupted` flag in the `JavaThread::handle_async_exception()` after an `async` pending exception has been set to be thrown with the `set_pending_exception()`. >> >> There are a couple of concerns with this fix which would be nice to sort out with reviewers: >> 1. The proposed fix may clear the interrupt state when it was already set prior to the issuing of the `StopThread()` (this concern was raised by @dholmes-ora in a comment of this JBS issue) >> 2. The impacted code path is shared between the class `InstallAsyncExceptionHandshakeClosure` used by the JVMTI `StopThread` implementation and the class `ScopedAsyncExceptionHandshakeClosure` used by the `ScopedMemoryAccess` >> >> I feel that clearing the `interrupted` flag byt the `JavaThread::handle_async_exception()` is a right thing to do even though it was set before the call to `JavaThread::install_async_exception()`. Also, it has to be done for both `StopThread` and `ScopedMemoryAccess`. >> >> The fix also includes minor tweaks of the test `StopThreadTest` to make the issue reproducible with it. >> >> Testing: >> - Mach5 tiers 1-6 are passed >> - Ran the updated reproducer test `hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest` > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: implemented a suggestion: do not set interrupt flag at all FWIW the way this used to work in the past for the blocking methods is that "stop" would install the pending-async-exception and interrupt the thread to unblock it. The thread doing a sleep/park/wait would see that it was interrupted and proceed to throw `InterruptedException`, and in the process clear the interrupt flag (as per the spec). But when we attempted to return to Java from `_thread_in_vm` we would see the pending-async-exception and replaced the pending IE with the the async one (ThreadDeath usually). But if the thread was not blocked in an interruptible blocking method then it would have the interrupt state set. So we basically have always behaved this way and I'm wondering what is driving us to change this behaviour now? FWIW I think the fix is reasonable to avoid messing with the interrupt flag, but the fact Alan seems to want the "stop" to not interrupt at all makes me wonder how stop would then actually work? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3130992741 From duke at openjdk.org Tue Jul 29 08:29:00 2025 From: duke at openjdk.org (duke) Date: Tue, 29 Jul 2025 08:29:00 GMT Subject: RFR: 8363920: JVMTI Documentation for GetLocalDouble is wrong: refers to long In-Reply-To: References: Message-ID: On Tue, 29 Jul 2025 02:20:56 GMT, Lei Zhu wrote: > Hi all, > > Fixed type errors in documentation, minor changes. > > Thanks! @Korov Your change (at version b6a19df4f83266856f9688f4ac204055908b89a8) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26521#issuecomment-3131256382 From sspitsyn at openjdk.org Tue Jul 29 09:45:11 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 29 Jul 2025 09:45:11 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException [v4] In-Reply-To: References: Message-ID: > If JVMTI `StopThread` is done when the thread is in certain various states (but not all states), after the `async` exception is delivered and handled, hotspot leaves the thread's `interrupted` flag set. The end result is the next time the thread does something like `Thread.sleep()`, it will immediately get an `InterruptedException`. > > The fix is to clear the `interrupted` flag in the `JavaThread::handle_async_exception()` after an `async` pending exception has been set to be thrown with the `set_pending_exception()`. > > There are a couple of concerns with this fix which would be nice to sort out with reviewers: > 1. The proposed fix may clear the interrupt state when it was already set prior to the issuing of the `StopThread()` (this concern was raised by @dholmes-ora in a comment of this JBS issue) > 2. The impacted code path is shared between the class `InstallAsyncExceptionHandshakeClosure` used by the JVMTI `StopThread` implementation and the class `ScopedAsyncExceptionHandshakeClosure` used by the `ScopedMemoryAccess` > > I feel that clearing the `interrupted` flag byt the `JavaThread::handle_async_exception()` is a right thing to do even though it was set before the call to `JavaThread::install_async_exception()`. Also, it has to be done for both `StopThread` and `ScopedMemoryAccess`. > > The fix also includes minor tweaks of the test `StopThreadTest` to make the issue reproducible with it. > > Testing: > - Mach5 tiers 1-6 are passed > - Ran the updated reproducer test `hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest` Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: remove tweak from JavaThread::sleep_nanos ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26365/files - new: https://git.openjdk.org/jdk/pull/26365/files/fde881f0..1f7b67c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26365&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26365&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26365.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26365/head:pull/26365 PR: https://git.openjdk.org/jdk/pull/26365 From sspitsyn at openjdk.org Tue Jul 29 09:45:11 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 29 Jul 2025 09:45:11 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException [v3] In-Reply-To: <2faiO8M1kDjt63rmbo8EjfXOxA5ggxcpHp4S3Ok3S2A=.b85da477-0c63-47a2-aac8-988254863fd4@github.com> References: <2faiO8M1kDjt63rmbo8EjfXOxA5ggxcpHp4S3Ok3S2A=.b85da477-0c63-47a2-aac8-988254863fd4@github.com> Message-ID: On Mon, 28 Jul 2025 10:50:23 GMT, Alan Bateman wrote: > It would put the onus on the debugger to interrupt, which I think is the right thing to do. it would remove the interrupt from JavaThread::install_async_exception and would mean no change to JavaThread::sleep_nanos. Thank you for the suggestion. I've tested it and found that a couple of tests are failed including one JCK test. So, at a minimum this approach is going to be more complicated, it would require a supporting JDI update, consultation with the IDE vendors, CSR and a release note. Also, I kind of share the David's concern above. So, I'm thinking if it is okay to separate this effort from the current fix. I can file an enhancement if it makes sense and worth it. As I see, the tweak in `JavaThread::sleep_nanos()` is not really needed, so I'll remove it now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3131566270 From mgronlun at openjdk.org Tue Jul 29 09:58:01 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 29 Jul 2025 09:58:01 GMT Subject: Integrated: 8356587: Missing object ID X in pool jdk.types.Method In-Reply-To: References: Message-ID: <3wd4ZmTVQzjgPIwmzQcfo1OxMsJ7BHVEV99IKJdwBfI=.5438c472-f3d0-4152-bf90-c115d57a13f4@github.com> On Thu, 24 Jul 2025 12:49:36 GMT, Markus Gr?nlund wrote: > Greetings, > > The following change set addresses the data loss resulting in the assertion "Missing object ID X in pool jdk.types.Method". > > It involves three components: > > 1. Address a regression introduced by [JDK-835221](https://bugs.openjdk.org/browse/JDK-8352251). By locating JFR_ONLY(Jfr::check_and_process_sample_request(thread);) before the global_poll() in SafepointMechanism::process(), a stacktrace can be captured, and artifacts tagged, during a safepoint. This breaks an invariant as artifacts, i.e. methods, can be tagged in the wrong epoch (also a stacktrace can be stored in the wrong epoch). Must be moved to post global_poll(). > > 2. Retransform/Redefine classes include a non-safe copy of Method trace flags, leading to stale bits being set onto the new Methods. Method trace flags need to be copied, but must be done under a safepoint. > > 3. It seems that there has been an increase in the frequency of issuing calls to InstanceKlass::purge_previous_versions(), making scratch klasses and old methods disappear before JFR gets the chance to serialize also tagged old methods. Therefore, we need to ensure that we always tag the latest version of a Method. > > There is also a cleanup of gratuitous type conversions, from Klass* to InstanceKlass* in the newly introduced MethodTracing subsystem. > > Testing: jdk_jfr, stress testing > > Thank you > Markus This pull request has now been integrated. Changeset: a3499447 Author: Markus Gr?nlund URL: https://git.openjdk.org/jdk/commit/a34994476e8f4783c9f5a83a9c3db63ad605b323 Stats: 303 lines in 24 files changed: 129 ins; 101 del; 73 mod 8356587: Missing object ID X in pool jdk.types.Method Reviewed-by: egahlin ------------- PR: https://git.openjdk.org/jdk/pull/26458 From mgronlun at openjdk.org Tue Jul 29 10:04:29 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 29 Jul 2025 10:04:29 GMT Subject: [jdk25] RFR: 8356587: Missing object ID X in pool jdk.types.Method Message-ID: 8356587: Missing object ID X in pool jdk.types.Method ------------- Commit messages: - Backport a34994476e8f4783c9f5a83a9c3db63ad605b323 Changes: https://git.openjdk.org/jdk/pull/26529/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26529&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356587 Stats: 303 lines in 24 files changed: 129 ins; 101 del; 73 mod Patch: https://git.openjdk.org/jdk/pull/26529.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26529/head:pull/26529 PR: https://git.openjdk.org/jdk/pull/26529 From egahlin at openjdk.org Tue Jul 29 10:07:54 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 29 Jul 2025 10:07:54 GMT Subject: [jdk25] RFR: 8356587: Missing object ID X in pool jdk.types.Method In-Reply-To: References: Message-ID: On Tue, 29 Jul 2025 09:56:23 GMT, Markus Gr?nlund wrote: > 8356587: Missing object ID X in pool jdk.types.Method Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26529#pullrequestreview-3066684022 From mgronlun at openjdk.org Tue Jul 29 11:44:01 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 29 Jul 2025 11:44:01 GMT Subject: [jdk25] Integrated: 8356587: Missing object ID X in pool jdk.types.Method In-Reply-To: References: Message-ID: On Tue, 29 Jul 2025 09:56:23 GMT, Markus Gr?nlund wrote: > 8356587: Missing object ID X in pool jdk.types.Method This pull request has now been integrated. Changeset: 9fe2aa59 Author: Markus Gr?nlund URL: https://git.openjdk.org/jdk/commit/9fe2aa59ffde71879eeee5cfa10919468c253b34 Stats: 303 lines in 24 files changed: 129 ins; 101 del; 73 mod 8356587: Missing object ID X in pool jdk.types.Method Reviewed-by: egahlin Backport-of: a34994476e8f4783c9f5a83a9c3db63ad605b323 ------------- PR: https://git.openjdk.org/jdk/pull/26529 From alanb at openjdk.org Tue Jul 29 15:25:55 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 29 Jul 2025 15:25:55 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException [v3] In-Reply-To: References: Message-ID: On Tue, 29 Jul 2025 07:06:21 GMT, David Holmes wrote: > FWIW I think the fix is reasonable to avoid messing with the interrupt flag, but the fact Alan seems to want the "stop" to not interrupt at all makes me wonder how stop would then actually work? I don't think the current proposed change (which drop's setting the interrupt flag in install_async_exception) will cause a target thread blocked in sleep to wakeup. A target thread blocked in JavaThread::sleep_nanos will wakeup from park_nanos but will just park again with the remaining time. I assume this is the test failures that Serguei mentions. As you noted, the bug is the side effect of setting the interrupt status of a target thread that is not in a InterruptedException throwing method. It may be that the "Throw Exception" feature in debuggers isn't used much and nobody has noticed. If we can reach out the debugger/IDE maintainers then we might be able to a bit more insight into how this is used. In some debuggers you can't use "Throw Exception" (= StopThread) when the target is blocked in the native code or in the VM. When suspended at a breakpoint then it looks like IntelliJ calls both ThreadReference::stop and ThreadReference::interrupt but I can't tell if the latter is conditional or not. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3133023220 From amenkov at openjdk.org Tue Jul 29 18:11:02 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 29 Jul 2025 18:11:02 GMT Subject: RFR: 8363920: JVMTI Documentation for GetLocalDouble is wrong: refers to long In-Reply-To: References: Message-ID: On Tue, 29 Jul 2025 02:20:56 GMT, Lei Zhu wrote: > Hi all, > > Fixed type errors in documentation, minor changes. > > Thanks! Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26521#pullrequestreview-3068654927 From cjplummer at openjdk.org Tue Jul 29 19:46:03 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 29 Jul 2025 19:46:03 GMT Subject: RFR: 8361873: [GCC static analyzer] exec_md.c forkedChildProcess potential double 'close' of file descriptor '3' [v2] In-Reply-To: References: <_Xf1QnVT5aJRUFI5kF9MwNB_xoFF8S0Q1Rcn8HCoTec=.02805f35-fd3a-4b91-b42d-bffa658686ba@github.com> <5eryyx1Kj5NyBK1hYzkPH-HiMAsLkllNVtkJ8rDmr98=.a754d3bb-fa3d-42bc-80e2-714f4f795270@github.com> Message-ID: On Tue, 29 Jul 2025 06:23:20 GMT, Thomas Stuefe wrote: > No, I am talking about this: > > https://github.com/openjdk/jdk/blob/4669005123420d8dbe86740dd9bcbee04735bc4f/src/java.base/unix/native/libjava/childproc.c#L109 > where we close all file descriptors apart from the ones we need to communicate to the jspawnhelper. > > > In any case, I think this is beyond the scope of this PR. Maybe an RFE could be filed for it if you think it is worth doing. > > Sure thing Ok. I filed [JDK-8364312](https://bugs.openjdk.org/browse/JDK-8364312) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26487#issuecomment-3133805555 From cjplummer at openjdk.org Tue Jul 29 19:46:04 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 29 Jul 2025 19:46:04 GMT Subject: RFR: 8361873: [GCC static analyzer] exec_md.c forkedChildProcess potential double 'close' of file descriptor '3' [v3] In-Reply-To: <9XDiWo_GdRo5FZyEIeQ5yo9ySoqBrp6gbqK6tv3HbHk=.66869696-202a-4b98-96ea-4034f38c07b8@github.com> References: <_Xf1QnVT5aJRUFI5kF9MwNB_xoFF8S0Q1Rcn8HCoTec=.02805f35-fd3a-4b91-b42d-bffa658686ba@github.com> <9XDiWo_GdRo5FZyEIeQ5yo9ySoqBrp6gbqK6tv3HbHk=.66869696-202a-4b98-96ea-4034f38c07b8@github.com> Message-ID: On Mon, 28 Jul 2025 16:18:44 GMT, Chris Plummer wrote: >> Fix gcc warning about double close. forkedChildProcess() calls closeDescriptors(), which always closes STDERR_FILENO + 1 and STDERR_FILENO + 2. However, if it fails at some point after that, then forkedChildProcess() will attempt to close these same two files again. Fixed by making forkedChildProcess() no longer attempt to close these two files. >> >> I first verified the warning by configuring with --with-extra-cflags=-fanalyzer, and then verified the fix by doing the same. >> >> Tested by running jdi nsk test. I'll add some more CI testing. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Update comment Thanks for the reviews Jai, Thomas, and Matthias. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26487#issuecomment-3133809692 From cjplummer at openjdk.org Tue Jul 29 19:46:05 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 29 Jul 2025 19:46:05 GMT Subject: Integrated: 8361873: [GCC static analyzer] exec_md.c forkedChildProcess potential double 'close' of file descriptor '3' In-Reply-To: <_Xf1QnVT5aJRUFI5kF9MwNB_xoFF8S0Q1Rcn8HCoTec=.02805f35-fd3a-4b91-b42d-bffa658686ba@github.com> References: <_Xf1QnVT5aJRUFI5kF9MwNB_xoFF8S0Q1Rcn8HCoTec=.02805f35-fd3a-4b91-b42d-bffa658686ba@github.com> Message-ID: On Fri, 25 Jul 2025 23:09:48 GMT, Chris Plummer wrote: > Fix gcc warning about double close. forkedChildProcess() calls closeDescriptors(), which always closes STDERR_FILENO + 1 and STDERR_FILENO + 2. However, if it fails at some point after that, then forkedChildProcess() will attempt to close these same two files again. Fixed by making forkedChildProcess() no longer attempt to close these two files. > > I first verified the warning by configuring with --with-extra-cflags=-fanalyzer, and then verified the fix by doing the same. > > Tested by running jdi nsk test. I'll add some more CI testing. This pull request has now been integrated. Changeset: d5d311f0 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/d5d311f026f69c56a409d856f5e11cdff0526c6c Stats: 9 lines in 1 file changed: 5 ins; 0 del; 4 mod 8361873: [GCC static analyzer] exec_md.c forkedChildProcess potential double 'close' of file descriptor '3' Reviewed-by: jpai, stuefe, mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/26487 From dholmes at openjdk.org Tue Jul 29 23:47:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 29 Jul 2025 23:47:54 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException [v3] In-Reply-To: References: Message-ID: On Tue, 29 Jul 2025 15:23:29 GMT, Alan Bateman wrote: > I don't think the current proposed change (which drop's setting the interrupt flag in install_async_exception) will cause a target thread blocked in sleep to wakeup. A target thread blocked in JavaThread::sleep_nanos will wakeup from park_nanos but will just park again with the remaining time. I assume this is the test failures that Serguei mentions. Right but that is why there was a tweak to `sleep_nanos`: if (has_async_exception_condition()) { return false; } But that tweak has now been removed hence this fix no longer maintains the functionality of `StopThread`. And again this issue of leaving the interrupt flag set has existed "forever". ------------- PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3134402208 From duke at openjdk.org Wed Jul 30 01:59:54 2025 From: duke at openjdk.org (Lei Zhu) Date: Wed, 30 Jul 2025 01:59:54 GMT Subject: RFR: 8363920: JVMTI Documentation for GetLocalDouble is wrong: refers to long In-Reply-To: References: Message-ID: On Tue, 29 Jul 2025 18:08:29 GMT, Alex Menkov wrote: >> Hi all, >> >> Fixed type errors in documentation, minor changes. >> >> Thanks! > > Marked as reviewed by amenkov (Reviewer). @alexmenkov Thank you for the review! And can you help me execute `/sponsor` command. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26521#issuecomment-3134616477 From sspitsyn at openjdk.org Wed Jul 30 05:14:55 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 30 Jul 2025 05:14:55 GMT Subject: RFR: 8363920: JVMTI Documentation for GetLocalDouble is wrong: refers to long In-Reply-To: References: Message-ID: On Tue, 29 Jul 2025 02:20:56 GMT, Lei Zhu wrote: > Hi all, > > Fixed type errors in documentation, minor changes. > > Thanks! Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26521#pullrequestreview-3069907149 From duke at openjdk.org Wed Jul 30 05:21:00 2025 From: duke at openjdk.org (Lei Zhu) Date: Wed, 30 Jul 2025 05:21:00 GMT Subject: Integrated: 8363920: JVMTI Documentation for GetLocalDouble is wrong: refers to long In-Reply-To: References: Message-ID: On Tue, 29 Jul 2025 02:20:56 GMT, Lei Zhu wrote: > Hi all, > > Fixed type errors in documentation, minor changes. > > Thanks! This pull request has now been integrated. Changeset: 1be412dc Author: Lei Zhu Committer: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/1be412dca08028d37a90cff1d4a67007c6b2d690 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8363920: JVMTI Documentation for GetLocalDouble is wrong: refers to long Reviewed-by: alanb, amenkov, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/26521 From sspitsyn at openjdk.org Wed Jul 30 06:02:56 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 30 Jul 2025 06:02:56 GMT Subject: RFR: 8364115: Sort share/services includes [v2] In-Reply-To: References: <_Cz--W3RLL1j-_xo0w3cW4jilOFzdZ_DFVBlWe_RdVU=.396a7d0d-3ee1-4902-ace2-6ab6b223264b@github.com> Message-ID: On Mon, 28 Jul 2025 14:41:25 GMT, Francesco Andreuzzi wrote: >> This PR sorts the includes in `hotspot/share/services` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`. >> >> Passes tier1. > > Francesco Andreuzzi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' into JDK-8364115 > - sort includes This looks okay ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26483#pullrequestreview-3069986642 From ayang at openjdk.org Wed Jul 30 07:18:01 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 30 Jul 2025 07:18:01 GMT Subject: RFR: 8364115: Sort share/services includes [v2] In-Reply-To: References: <_Cz--W3RLL1j-_xo0w3cW4jilOFzdZ_DFVBlWe_RdVU=.396a7d0d-3ee1-4902-ace2-6ab6b223264b@github.com> Message-ID: On Mon, 28 Jul 2025 14:41:25 GMT, Francesco Andreuzzi wrote: >> This PR sorts the includes in `hotspot/share/services` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`. >> >> Passes tier1. > > Francesco Andreuzzi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' into JDK-8364115 > - sort includes Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26483#pullrequestreview-3070189802 From sspitsyn at openjdk.org Wed Jul 30 07:19:34 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 30 Jul 2025 07:19:34 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException [v5] In-Reply-To: References: Message-ID: > If JVMTI `StopThread` is done when the thread is in certain various states (but not all states), after the `async` exception is delivered and handled, hotspot leaves the thread's `interrupted` flag set. The end result is the next time the thread does something like `Thread.sleep()`, it will immediately get an `InterruptedException`. > > The fix is to clear the `interrupted` flag in the `JavaThread::handle_async_exception()` after an `async` pending exception has been set to be thrown with the `set_pending_exception()`. > > There are a couple of concerns with this fix which would be nice to sort out with reviewers: > 1. The proposed fix may clear the interrupt state when it was already set prior to the issuing of the `StopThread()` (this concern was raised by @dholmes-ora in a comment of this JBS issue) > 2. The impacted code path is shared between the class `InstallAsyncExceptionHandshakeClosure` used by the JVMTI `StopThread` implementation and the class `ScopedAsyncExceptionHandshakeClosure` used by the `ScopedMemoryAccess` > > I feel that clearing the `interrupted` flag byt the `JavaThread::handle_async_exception()` is a right thing to do even though it was set before the call to `JavaThread::install_async_exception()`. Also, it has to be done for both `StopThread` and `ScopedMemoryAccess`. > > The fix also includes minor tweaks of the test `StopThreadTest` to make the issue reproducible with it. > > Testing: > - Mach5 tiers 1-6 are passed > - Ran the updated reproducer test `hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest` Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: restored the tweak in the JavaThread::sleep_nanos ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26365/files - new: https://git.openjdk.org/jdk/pull/26365/files/1f7b67c3..a46ef6f5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26365&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26365&range=03-04 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26365.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26365/head:pull/26365 PR: https://git.openjdk.org/jdk/pull/26365 From sspitsyn at openjdk.org Wed Jul 30 07:19:34 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 30 Jul 2025 07:19:34 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException [v3] In-Reply-To: References: Message-ID: On Tue, 29 Jul 2025 23:45:09 GMT, David Holmes wrote: > But that tweak has now been removed hence this fix no longer maintains the functionality of StopThread. Sorry, this was removed by a mistake. I incorrectly interpreted some code. Restored now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3135132366 From sspitsyn at openjdk.org Wed Jul 30 07:30:54 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 30 Jul 2025 07:30:54 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException [v3] In-Reply-To: References: Message-ID: On Tue, 29 Jul 2025 23:45:09 GMT, David Holmes wrote: > I don't think the current proposed change (which drop's setting the interrupt flag in install_async_exception) will cause a target thread blocked in sleep to wakeup. A target thread blocked in JavaThread::sleep_nanos will wakeup from park_nanos but will just park again with the remaining time. Thank you checking this. I've restored the tweak in the `JavaThread::sleep_nanos()`. > I assume this is the test failures that Serguei mentions. The test failures I mentioned were after an attempt to remove the following lines from the `JavaThread::install_async_exception()`: oop vt_oop = vthread(); if (vt_oop == nullptr || !vt_oop->is_a(vmClasses::BaseVirtualThread_klass())) { // Interrupt thread so it will wake up from a potential wait()/sleep()/park() this->interrupt(); } ``` In order to remove the above a corresponding update in the jdwp/debugger is additionally needed to invoke the JVMTI `ThreadInterrupt()`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3135163510 From duke at openjdk.org Wed Jul 30 07:59:55 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Wed, 30 Jul 2025 07:59:55 GMT Subject: RFR: 8364115: Sort share/services includes [v2] In-Reply-To: References: <_Cz--W3RLL1j-_xo0w3cW4jilOFzdZ_DFVBlWe_RdVU=.396a7d0d-3ee1-4902-ace2-6ab6b223264b@github.com> Message-ID: <6vjiWhh9MBkSMv0aX8btnSZzmRgA-fQigxyQKLfiWtI=.480621a3-cb5e-4281-8a87-def5e9e65606@github.com> On Wed, 30 Jul 2025 07:15:45 GMT, Albert Mingkun Yang wrote: >> Francesco Andreuzzi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: >> >> - Merge branch 'master' into JDK-8364115 >> - sort includes > > Marked as reviewed by ayang (Reviewer). @albertnetymk @sspitsyn thanks for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26483#issuecomment-3135239668 From duke at openjdk.org Wed Jul 30 07:59:56 2025 From: duke at openjdk.org (duke) Date: Wed, 30 Jul 2025 07:59:56 GMT Subject: RFR: 8364115: Sort share/services includes [v2] In-Reply-To: References: <_Cz--W3RLL1j-_xo0w3cW4jilOFzdZ_DFVBlWe_RdVU=.396a7d0d-3ee1-4902-ace2-6ab6b223264b@github.com> Message-ID: On Mon, 28 Jul 2025 14:41:25 GMT, Francesco Andreuzzi wrote: >> This PR sorts the includes in `hotspot/share/services` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`. >> >> Passes tier1. > > Francesco Andreuzzi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' into JDK-8364115 > - sort includes @fandreuz Your change (at version bd7c21eaba4f91797c6aee9ea0af9314a29f78cf) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26483#issuecomment-3135241941 From alanb at openjdk.org Wed Jul 30 08:41:55 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 30 Jul 2025 08:41:55 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException [v5] In-Reply-To: References: Message-ID: On Wed, 30 Jul 2025 07:19:34 GMT, Serguei Spitsyn wrote: >> If JVMTI `StopThread` is done when the thread is in certain various states (but not all states), after the `async` exception is delivered and handled, hotspot leaves the thread's `interrupted` flag set. The end result is the next time the thread does something like `Thread.sleep()`, it will immediately get an `InterruptedException`. >> >> The fix is to clear the `interrupted` flag in the `JavaThread::handle_async_exception()` after an `async` pending exception has been set to be thrown with the `set_pending_exception()`. >> >> There are a couple of concerns with this fix which would be nice to sort out with reviewers: >> 1. The proposed fix may clear the interrupt state when it was already set prior to the issuing of the `StopThread()` (this concern was raised by @dholmes-ora in a comment of this JBS issue) >> 2. The impacted code path is shared between the class `InstallAsyncExceptionHandshakeClosure` used by the JVMTI `StopThread` implementation and the class `ScopedAsyncExceptionHandshakeClosure` used by the `ScopedMemoryAccess` >> >> I feel that clearing the `interrupted` flag byt the `JavaThread::handle_async_exception()` is a right thing to do even though it was set before the call to `JavaThread::install_async_exception()`. Also, it has to be done for both `StopThread` and `ScopedMemoryAccess`. >> >> The fix also includes minor tweaks of the test `StopThreadTest` to make the issue reproducible with it. >> >> Testing: >> - Mach5 tiers 1-6 are passed >> - Ran the updated reproducer test `hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest` > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: restored the tweak in the JavaThread::sleep_nanos The latest update to have JavaThread::sleep_nanos to bail out if there is async exception looks okay. Combined it means that a StopThread when the target platform thread is in Thread.sleep and Object.wait will cause both to wakeup and throw the exception, without the side effect of setting the interrupt status. So I think it's a good approach. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3135364067 From alanb at openjdk.org Wed Jul 30 08:46:56 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 30 Jul 2025 08:46:56 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException [v3] In-Reply-To: References: Message-ID: On Tue, 29 Jul 2025 23:45:09 GMT, David Holmes wrote: > And again this issue of leaving the interrupt flag set has existed "forever". Right, and mostly surfaced when updating JVMTI to support virtual threads. The related issue is that JVMTI InterruptThread doesn't cause a platform thread to wakeup from interruptible I/O operations. It works when the target is a virtual thread because it's an upcall to Thread::interrupt, not so for platform threads. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26365#issuecomment-3135380028 From shade at openjdk.org Wed Jul 30 10:32:04 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 30 Jul 2025 10:32:04 GMT Subject: RFR: 8364115: Sort share/services includes [v2] In-Reply-To: References: <_Cz--W3RLL1j-_xo0w3cW4jilOFzdZ_DFVBlWe_RdVU=.396a7d0d-3ee1-4902-ace2-6ab6b223264b@github.com> Message-ID: On Mon, 28 Jul 2025 14:41:25 GMT, Francesco Andreuzzi wrote: >> This PR sorts the includes in `hotspot/share/services` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`. >> >> Passes tier1. > > Francesco Andreuzzi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' into JDK-8364115 > - sort includes Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26483#pullrequestreview-3070803706 From duke at openjdk.org Wed Jul 30 10:32:05 2025 From: duke at openjdk.org (Francesco Andreuzzi) Date: Wed, 30 Jul 2025 10:32:05 GMT Subject: Integrated: 8364115: Sort share/services includes In-Reply-To: <_Cz--W3RLL1j-_xo0w3cW4jilOFzdZ_DFVBlWe_RdVU=.396a7d0d-3ee1-4902-ace2-6ab6b223264b@github.com> References: <_Cz--W3RLL1j-_xo0w3cW4jilOFzdZ_DFVBlWe_RdVU=.396a7d0d-3ee1-4902-ace2-6ab6b223264b@github.com> Message-ID: On Fri, 25 Jul 2025 16:05:15 GMT, Francesco Andreuzzi wrote: > This PR sorts the includes in `hotspot/share/services` using `SortIncludes.java`. I'm also adding the directory to `TestIncludesAreSorted`. > > Passes tier1. This pull request has now been integrated. Changeset: c8517356 Author: Francesco Andreuzzi Committer: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/c8517356314c9dd1123401a21968009066053e5b Stats: 42 lines in 12 files changed: 22 ins; 19 del; 1 mod 8364115: Sort share/services includes Reviewed-by: sspitsyn, ayang, shade ------------- PR: https://git.openjdk.org/jdk/pull/26483 From kevinw at openjdk.org Wed Jul 30 11:31:07 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 30 Jul 2025 11:31:07 GMT Subject: RFR: 8364227: MBeanServer registerMBean throws NPE Message-ID: A long-standing omission where MBeanServer.registerMBean documents exception behaviour, but we actually throw an NPE. We should recognise a null object and return the wrapped exception we document. This wrapping behaviour is common elsewhere in this area, e.g. unregisterMBean which checks for a null name and throws RuntimeOperationsException. Docs: https://docs.oracle.com/en/java/javase/24/docs/api/java.management/javax/management/MBeanServer.html#registerMBean(java.lang.Object,javax.management.ObjectName) Throws: RuntimeOperationsException - Wraps a java.lang.IllegalArgumentException: The object passed in parameter is null or no object name is specified. Current behaviour: $ java MBS_NPE.java Exception in thread "main" java.lang.NullPointerException: Cannot invoke "Object.getClass()" because "object" is null at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:296) at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511) at MBS_NPE.main(MBS_NPE.java:11) Should be changed to: $ java MBS_NPE.java javax.management.RuntimeOperationsException: Exception occurred trying to register the MBean at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:297) at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511) at MBS_NPE.main(MBS_NPE.java:11) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.execute(SourceLauncher.java:258) at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.run(SourceLauncher.java:138) at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.main(SourceLauncher.java:76) Caused by: java.lang.IllegalArgumentException: Object cannot be null at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:295) ... 7 more ------------- Commit messages: - 8364227: MBeanServer registerMBean throws NPE Changes: https://git.openjdk.org/jdk/pull/26548/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26548&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364227 Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26548.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26548/head:pull/26548 PR: https://git.openjdk.org/jdk/pull/26548 From alanb at openjdk.org Wed Jul 30 11:57:00 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 30 Jul 2025 11:57:00 GMT Subject: RFR: 8364227: MBeanServer registerMBean throws NPE In-Reply-To: References: Message-ID: On Wed, 30 Jul 2025 11:19:33 GMT, Kevin Walls wrote: > A long-standing omission where MBeanServer.registerMBean documents exception behaviour, but we actually throw an NPE. We should recognise a null object and return the wrapped exception we document. > > This wrapping behaviour is common elsewhere in this area, e.g. unregisterMBean which checks for a null name and throws RuntimeOperationsException. > > Docs: > https://docs.oracle.com/en/java/javase/24/docs/api/java.management/javax/management/MBeanServer.html#registerMBean(java.lang.Object,javax.management.ObjectName) > > Throws: > RuntimeOperationsException - Wraps a java.lang.IllegalArgumentException: The object passed in parameter is null or no object name is specified. > > > Current behaviour: > > > $ java MBS_NPE.java > Exception in thread "main" java.lang.NullPointerException: Cannot invoke "Object.getClass()" because "object" is null > at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:296) > at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511) > at MBS_NPE.main(MBS_NPE.java:11) > > > Should be changed to: > > > $ java MBS_NPE.java > javax.management.RuntimeOperationsException: Exception occurred trying to register the MBean > at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:297) > at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511) > at MBS_NPE.main(MBS_NPE.java:11) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.execute(SourceLauncher.java:258) > at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.run(SourceLauncher.java:138) > at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.main(SourceLauncher.java:76) > Caused by: java.lang.IllegalArgumentException: Object cannot be null > at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:295) > ... 7 more I assume a CSR should be created to track the behavior. I don't expect there is code catching IAE instead of RuntimeOperationsException for this scenario but it's possible. Are you planning to add a test? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26548#issuecomment-3135955498 From kevinw at openjdk.org Wed Jul 30 12:42:52 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 30 Jul 2025 12:42:52 GMT Subject: RFR: 8364227: MBeanServer registerMBean throws NPE In-Reply-To: References: Message-ID: On Wed, 30 Jul 2025 11:53:59 GMT, Alan Bateman wrote: > I assume a CSR should be created to track the behavior change. I don't expect there is code catching IAE instead of RuntimeOperationsException for this scenario but it's possible. > > Are you planning to add a test? Hi - I wasn't assuming a CSR was needed, as this is making us meet the declared spec, not changing the spec. While it is a behaviour correction, DefaultMBeanServerInterceptor.java has 20 existing examples of the correct behaviour, throwing RuntimeOperationsException wrapping an IllegalArgumentException, so we are fitting an established pattern. The existing RuntimeOperationsException throws suggest code may well exist that catches RuntimeOperationsException on MBeanserver methods. The problem is that today this method throws a "raw" NullPointerException. We probably don't exepct people to be catching that, although maybe catching something more general. Some of our tests do catch ROE, although we have almost no testing of the existing nulls that cause RuntimeOperationsException. For that reason I was not planning to add a test. (e.g. We have "test/jdk/javax/management/modelmbean/InfoSupportTest.java" which tests mmbi.setDescriptor with a null and verifies the RuntimeOperationsException contains IllegalArgumentException) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26548#issuecomment-3136140949 From alanb at openjdk.org Wed Jul 30 13:30:53 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 30 Jul 2025 13:30:53 GMT Subject: RFR: 8364227: MBeanServer registerMBean throws NPE In-Reply-To: References: Message-ID: On Wed, 30 Jul 2025 11:19:33 GMT, Kevin Walls wrote: > A long-standing omission where MBeanServer.registerMBean documents exception behaviour, but we actually throw an NPE. We should recognise a null object and return the wrapped exception we document. > > This wrapping behaviour is common elsewhere in this area, e.g. unregisterMBean which checks for a null name and throws RuntimeOperationsException. > > Docs: > https://docs.oracle.com/en/java/javase/24/docs/api/java.management/javax/management/MBeanServer.html#registerMBean(java.lang.Object,javax.management.ObjectName) > > Throws: > RuntimeOperationsException - Wraps a java.lang.IllegalArgumentException: The object passed in parameter is null or no object name is specified. > > > Current behaviour: > > > $ java MBS_NPE.java > Exception in thread "main" java.lang.NullPointerException: Cannot invoke "Object.getClass()" because "object" is null > at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:296) > at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511) > at MBS_NPE.main(MBS_NPE.java:11) > > > Should be changed to: > > > $ java MBS_NPE.java > javax.management.RuntimeOperationsException: Exception occurred trying to register the MBean > at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:297) > at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511) > at MBS_NPE.main(MBS_NPE.java:11) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.execute(SourceLauncher.java:258) > at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.run(SourceLauncher.java:138) > at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.main(SourceLauncher.java:76) > Caused by: java.lang.IllegalArgumentException: Object cannot be null > at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:295) > ... 7 more CSRs are used to track behavioural changes too. Bug fixes should have tests if feasible. I assume this issue would have been caught a long time ago if there were tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26548#issuecomment-3136359408 From kevinw at openjdk.org Wed Jul 30 14:17:53 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 30 Jul 2025 14:17:53 GMT Subject: RFR: 8364227: MBeanServer registerMBean throws NPE In-Reply-To: References: Message-ID: On Wed, 30 Jul 2025 11:19:33 GMT, Kevin Walls wrote: > A long-standing omission where MBeanServer.registerMBean documents exception behaviour, but we actually throw an NPE. We should recognise a null object and return the wrapped exception we document. > > This wrapping behaviour is common elsewhere in this area, e.g. unregisterMBean which checks for a null name and throws RuntimeOperationsException. > > Docs: > https://docs.oracle.com/en/java/javase/24/docs/api/java.management/javax/management/MBeanServer.html#registerMBean(java.lang.Object,javax.management.ObjectName) > > Throws: > RuntimeOperationsException - Wraps a java.lang.IllegalArgumentException: The object passed in parameter is null or no object name is specified. > > > Current behaviour: > > > $ java MBS_NPE.java > Exception in thread "main" java.lang.NullPointerException: Cannot invoke "Object.getClass()" because "object" is null > at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:296) > at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511) > at MBS_NPE.main(MBS_NPE.java:11) > > > Should be changed to: > > > $ java MBS_NPE.java > javax.management.RuntimeOperationsException: Exception occurred trying to register the MBean > at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:297) > at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511) > at MBS_NPE.main(MBS_NPE.java:11) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.execute(SourceLauncher.java:258) > at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.run(SourceLauncher.java:138) > at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.main(SourceLauncher.java:76) > Caused by: java.lang.IllegalArgumentException: Object cannot be null > at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:295) > ... 7 more On the CSR, my judgement was that this is superficial enough that a CSR is not necessary. I think that fits with the CSR FAQs. https://wiki.openjdk.org/display/csr/CSR+FAQs Q: Under what conditions does a CSR need to be filed for a purely behavioral change? A: "...if it is estimated enough developers or users would be sufficiently impacted by the change that it should get additional consideration or documentation. A judgment call is involved." On the test, maybe this is an opportunity to add tests for more of those possible NPEs that get wrapped, almost none of which we test, I can look into that and update... ------------- PR Comment: https://git.openjdk.org/jdk/pull/26548#issuecomment-3136552231 From duke at openjdk.org Wed Jul 30 14:52:50 2025 From: duke at openjdk.org (Lei Zhu) Date: Wed, 30 Jul 2025 14:52:50 GMT Subject: RFR: 8362533: Tests sun/management/jmxremote/bootstrap/* duplicate VM flags Message-ID: Hi all, `ProcessTools.createTestJavaProcessBuilder(String... command)` will call `jdk.test.lib.Utils#getTestJavaOpts`, so remove the duplicate vm flags. Trivial fix. Thanks! ------------- Commit messages: - 8362533: Tests sun/management/jmxremote/bootstrap/* duplicate VM flags Changes: https://git.openjdk.org/jdk/pull/26555/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26555&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8362533 Stats: 12 lines in 3 files changed: 0 ins; 8 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26555.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26555/head:pull/26555 PR: https://git.openjdk.org/jdk/pull/26555 From darcy at openjdk.org Wed Jul 30 15:24:56 2025 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 30 Jul 2025 15:24:56 GMT Subject: RFR: 8364227: MBeanServer registerMBean throws NPE In-Reply-To: References: Message-ID: <4TYVJbIuSop9ejWSVL77jJltKri6dk0w_S6j87D_y9U=.bb01df9c-8798-47bc-a37f-2c28f26df828@github.com> On Wed, 30 Jul 2025 11:19:33 GMT, Kevin Walls wrote: > A long-standing omission where MBeanServer.registerMBean documents exception behaviour, but we actually throw an NPE. We should recognise a null object and return the wrapped exception we document. > > This wrapping behaviour is common elsewhere in this area, e.g. unregisterMBean which checks for a null name and throws RuntimeOperationsException. > > Docs: > https://docs.oracle.com/en/java/javase/24/docs/api/java.management/javax/management/MBeanServer.html#registerMBean(java.lang.Object,javax.management.ObjectName) > > Throws: > RuntimeOperationsException - Wraps a java.lang.IllegalArgumentException: The object passed in parameter is null or no object name is specified. > > > Current behaviour: > > > $ java MBS_NPE.java > Exception in thread "main" java.lang.NullPointerException: Cannot invoke "Object.getClass()" because "object" is null > at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:296) > at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511) > at MBS_NPE.main(MBS_NPE.java:11) > > > Should be changed to: > > > $ java MBS_NPE.java > javax.management.RuntimeOperationsException: Exception occurred trying to register the MBean > at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:297) > at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511) > at MBS_NPE.main(MBS_NPE.java:11) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.execute(SourceLauncher.java:258) > at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.run(SourceLauncher.java:138) > at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.main(SourceLauncher.java:76) > Caused by: java.lang.IllegalArgumentException: Object cannot be null > at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:295) > ... 7 more Changing the type of exception thrown is above the line when it come to filing a CSR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26548#issuecomment-3136818045 From pchilanomate at openjdk.org Wed Jul 30 15:36:56 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 30 Jul 2025 15:36:56 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException [v5] In-Reply-To: References: Message-ID: On Wed, 30 Jul 2025 07:19:34 GMT, Serguei Spitsyn wrote: >> If JVMTI `StopThread` is done when the thread is in certain various states (but not all states), after the `async` exception is delivered and handled, hotspot leaves the thread's `interrupted` flag set. The end result is the next time the thread does something like `Thread.sleep()`, it will immediately get an `InterruptedException`. >> >> The fix is to clear the `interrupted` flag in the `JavaThread::handle_async_exception()` after an `async` pending exception has been set to be thrown with the `set_pending_exception()`. >> >> There are a couple of concerns with this fix which would be nice to sort out with reviewers: >> 1. The proposed fix may clear the interrupt state when it was already set prior to the issuing of the `StopThread()` (this concern was raised by @dholmes-ora in a comment of this JBS issue) >> 2. The impacted code path is shared between the class `InstallAsyncExceptionHandshakeClosure` used by the JVMTI `StopThread` implementation and the class `ScopedAsyncExceptionHandshakeClosure` used by the `ScopedMemoryAccess` >> >> I feel that clearing the `interrupted` flag byt the `JavaThread::handle_async_exception()` is a right thing to do even though it was set before the call to `JavaThread::install_async_exception()`. Also, it has to be done for both `StopThread` and `ScopedMemoryAccess`. >> >> The fix also includes minor tweaks of the test `StopThreadTest` to make the issue reproducible with it. >> >> Testing: >> - Mach5 tiers 1-6 are passed >> - Ran the updated reproducer test `hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest` > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review: restored the tweak in the JavaThread::sleep_nanos Changes look good to me, just a few comments below. src/hotspot/share/runtime/javaThread.cpp line 2121: > 2119: for (;;) { > 2120: if (has_async_exception_condition()) { > 2121: return false; The comment above `JavaThread::sleep_nanos` should be updated about this case. Also, back in `JVM_SleepNanos` we should probably skip throwing IE for this case (even though it will be overwritten by the async one later). ------------- PR Review: https://git.openjdk.org/jdk/pull/26365#pullrequestreview-3072155539 PR Review Comment: https://git.openjdk.org/jdk/pull/26365#discussion_r2243072058 From kevinw at openjdk.org Wed Jul 30 15:45:54 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 30 Jul 2025 15:45:54 GMT Subject: RFR: 8364227: MBeanServer registerMBean throws NPE In-Reply-To: References: Message-ID: On Wed, 30 Jul 2025 11:19:33 GMT, Kevin Walls wrote: > A long-standing omission where MBeanServer.registerMBean documents exception behaviour, but we actually throw an NPE. We should recognise a null object and return the wrapped exception we document. > > This wrapping behaviour is common elsewhere in this area, e.g. unregisterMBean which checks for a null name and throws RuntimeOperationsException. > > Docs: > https://docs.oracle.com/en/java/javase/24/docs/api/java.management/javax/management/MBeanServer.html#registerMBean(java.lang.Object,javax.management.ObjectName) > > Throws: > RuntimeOperationsException - Wraps a java.lang.IllegalArgumentException: The object passed in parameter is null or no object name is specified. > > > Current behaviour: > > > $ java MBS_NPE.java > Exception in thread "main" java.lang.NullPointerException: Cannot invoke "Object.getClass()" because "object" is null > at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:296) > at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511) > at MBS_NPE.main(MBS_NPE.java:11) > > > Should be changed to: > > > $ java MBS_NPE.java > javax.management.RuntimeOperationsException: Exception occurred trying to register the MBean > at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:297) > at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511) > at MBS_NPE.main(MBS_NPE.java:11) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.execute(SourceLauncher.java:258) > at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.run(SourceLauncher.java:138) > at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.main(SourceLauncher.java:76) > Caused by: java.lang.IllegalArgumentException: Object cannot be null > at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:295) > ... 7 more OK thanks, will add CSR. (This did seem fairly trivial, bringing one method in line with the others, but sure.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26548#issuecomment-3136888427 From sroy at openjdk.org Wed Jul 30 16:55:11 2025 From: sroy at openjdk.org (Suchismith Roy) Date: Wed, 30 Jul 2025 16:55:11 GMT Subject: RFR: JDK-8030957 - AIX: Implement OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v2] In-Reply-To: References: Message-ID: > JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957) > > These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created). > > getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo > > For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407) > > Once this issue has been resolved you should not forget to remove the two excludes from jdk/test/ProblemList.txt: > > com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all > com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all Suchismith Roy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' into cpuprocessload - Update UnixOperatingSystem.c - Merge branch 'openjdk:master' into cpuprocessload - cleanup - system cpu load - restore problem list - cpu process load ------------- Changes: https://git.openjdk.org/jdk/pull/25332/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25332&range=01 Stats: 79 lines in 2 files changed: 72 ins; 3 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25332.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25332/head:pull/25332 PR: https://git.openjdk.org/jdk/pull/25332 From sroy at openjdk.org Wed Jul 30 16:55:12 2025 From: sroy at openjdk.org (Suchismith Roy) Date: Wed, 30 Jul 2025 16:55:12 GMT Subject: RFR: JDK-8030957 - AIX: Implement OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX In-Reply-To: References: Message-ID: On Wed, 23 Jul 2025 10:47:24 GMT, Matthias Baesken wrote: > Maybe you can check the system tools you mentioned with 'trace' or 'tprof' or something similar to find out more about what they do and why they differ? Couldn't get much insights from that . I tried one case where I ran the same class file against Temurin and Semeru java binaries. I see almost similar cpu load values reported by both. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3137131066 From kevinw at openjdk.org Wed Jul 30 17:12:20 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 30 Jul 2025 17:12:20 GMT Subject: RFR: 8364227: MBeanServer registerMBean throws NPE [v2] In-Reply-To: References: Message-ID: > A long-standing omission where MBeanServer.registerMBean documents exception behaviour, but we actually throw an NPE. We should recognise a null object and return the wrapped exception we document. > > This wrapping behaviour is common elsewhere in this area, e.g. unregisterMBean which checks for a null name and throws RuntimeOperationsException. > > Docs: > https://docs.oracle.com/en/java/javase/24/docs/api/java.management/javax/management/MBeanServer.html#registerMBean(java.lang.Object,javax.management.ObjectName) > > Throws: > RuntimeOperationsException - Wraps a java.lang.IllegalArgumentException: The object passed in parameter is null or no object name is specified. > > > Current behaviour: > > > $ java MBS_NPE.java > Exception in thread "main" java.lang.NullPointerException: Cannot invoke "Object.getClass()" because "object" is null > at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:296) > at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511) > at MBS_NPE.main(MBS_NPE.java:11) > > > Should be changed to: > > > $ java MBS_NPE.java > javax.management.RuntimeOperationsException: Exception occurred trying to register the MBean > at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:297) > at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511) > at MBS_NPE.main(MBS_NPE.java:11) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.execute(SourceLauncher.java:258) > at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.run(SourceLauncher.java:138) > at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.main(SourceLauncher.java:76) > Caused by: java.lang.IllegalArgumentException: Object cannot be null > at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:295) > ... 7 more Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: - comment update - Add test for exceptions thrown in response to null params. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26548/files - new: https://git.openjdk.org/jdk/pull/26548/files/3d501c7b..82f2a8d7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26548&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26548&range=00-01 Stats: 189 lines in 1 file changed: 189 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26548.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26548/head:pull/26548 PR: https://git.openjdk.org/jdk/pull/26548 From kevinw at openjdk.org Wed Jul 30 17:54:34 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 30 Jul 2025 17:54:34 GMT Subject: RFR: 8364227: MBeanServer registerMBean throws NPE [v3] In-Reply-To: References: Message-ID: > A long-standing omission where MBeanServer.registerMBean documents exception behaviour, but we actually throw an NPE. We should recognise a null object and return the wrapped exception we document. > > This wrapping behaviour is common elsewhere in this area, e.g. unregisterMBean which checks for a null name and throws RuntimeOperationsException. > > Docs: > https://docs.oracle.com/en/java/javase/24/docs/api/java.management/javax/management/MBeanServer.html#registerMBean(java.lang.Object,javax.management.ObjectName) > > Throws: > RuntimeOperationsException - Wraps a java.lang.IllegalArgumentException: The object passed in parameter is null or no object name is specified. > > > Current behaviour: > > > $ java MBS_NPE.java > Exception in thread "main" java.lang.NullPointerException: Cannot invoke "Object.getClass()" because "object" is null > at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:296) > at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511) > at MBS_NPE.main(MBS_NPE.java:11) > > > Should be changed to: > > > $ java MBS_NPE.java > javax.management.RuntimeOperationsException: Exception occurred trying to register the MBean > at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:297) > at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511) > at MBS_NPE.main(MBS_NPE.java:11) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.execute(SourceLauncher.java:258) > at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.run(SourceLauncher.java:138) > at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.main(SourceLauncher.java:76) > Caused by: java.lang.IllegalArgumentException: Object cannot be null > at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:295) > ... 7 more Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: One more case ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26548/files - new: https://git.openjdk.org/jdk/pull/26548/files/82f2a8d7..671c6eaa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26548&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26548&range=01-02 Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26548.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26548/head:pull/26548 PR: https://git.openjdk.org/jdk/pull/26548 From kevinw at openjdk.org Wed Jul 30 17:54:34 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 30 Jul 2025 17:54:34 GMT Subject: RFR: 8364227: MBeanServer registerMBean throws NPE [v2] In-Reply-To: References: Message-ID: On Wed, 30 Jul 2025 17:12:20 GMT, Kevin Walls wrote: >> A long-standing omission where MBeanServer.registerMBean documents exception behaviour, but we actually throw an NPE. We should recognise a null object and return the wrapped exception we document. >> >> This wrapping behaviour is common elsewhere in this area, e.g. unregisterMBean which checks for a null name and throws RuntimeOperationsException. >> >> Docs: >> https://docs.oracle.com/en/java/javase/24/docs/api/java.management/javax/management/MBeanServer.html#registerMBean(java.lang.Object,javax.management.ObjectName) >> >> Throws: >> RuntimeOperationsException - Wraps a java.lang.IllegalArgumentException: The object passed in parameter is null or no object name is specified. >> >> >> Current behaviour: >> >> >> $ java MBS_NPE.java >> Exception in thread "main" java.lang.NullPointerException: Cannot invoke "Object.getClass()" because "object" is null >> at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:296) >> at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511) >> at MBS_NPE.main(MBS_NPE.java:11) >> >> >> Should be changed to: >> >> >> $ java MBS_NPE.java >> javax.management.RuntimeOperationsException: Exception occurred trying to register the MBean >> at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:297) >> at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511) >> at MBS_NPE.main(MBS_NPE.java:11) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:565) >> at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.execute(SourceLauncher.java:258) >> at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.run(SourceLauncher.java:138) >> at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.main(SourceLauncher.java:76) >> Caused by: java.lang.IllegalArgumentException: Object cannot be null >> at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:295) >> ... 7 more > > Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: > > - comment update > - Add test for exceptions thrown in response to null params. I've populated the CSR. Added a test, it does 16 tests that methods throw what we expect when given various null params. e.g. ----------System.out:(60/2902)---------- 1 Checking: javax.management.RuntimeOperationsException: Exception occurred during MBean creation Got expected cause: java.lang.IllegalArgumentException: The class name cannot be null 2 Checking: javax.management.RuntimeOperationsException: Exception occurred during MBean creation Got expected cause: java.lang.IllegalArgumentException: Invalid name->*:type=Foo 3 Checking: javax.management.RuntimeOperationsException: Exception occurred trying to register the MBean Got expected cause: java.lang.IllegalArgumentException: Object cannot be null ...etc... ------------- PR Comment: https://git.openjdk.org/jdk/pull/26548#issuecomment-3137313751 From lmesnik at openjdk.org Wed Jul 30 22:09:00 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 30 Jul 2025 22:09:00 GMT Subject: RFR: 8362533: Tests sun/management/jmxremote/bootstrap/* duplicate VM flags In-Reply-To: References: Message-ID: On Wed, 30 Jul 2025 14:47:54 GMT, Lei Zhu wrote: > Hi all, > > `ProcessTools.createTestJavaProcessBuilder(String... command)` will call `jdk.test.lib.Utils#getTestJavaOpts`, so remove the duplicate vm flags. Trivial fix. > > Thanks! Changes requested by lmesnik (Reviewer). test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java line 183: > 181: > 182: List command = new ArrayList<>(); > 183: Collections.addAll(command, Utils.getTestJavaOpts()); Comment generic to all three test fixes: Shouldn't be command.add(TEST_CLASS_PATH); command.add(className); also removed? The ProcessTools.createTestJavaProcessBuilder(command); uses standard classpath that should fit this test needs. If needed, property "test.noclasspath", mgith be use to don't add classpath. See jdk/test/lib/process/ProcessTools.java:161 private static ProcessBuilder createJavaProcessBuilder(String... command) { ... String noCPString = System.getProperty("test.noclasspath", "false"); ------------- PR Review: https://git.openjdk.org/jdk/pull/26555#pullrequestreview-3073452917 PR Review Comment: https://git.openjdk.org/jdk/pull/26555#discussion_r2243946685 From duke at openjdk.org Wed Jul 30 22:41:12 2025 From: duke at openjdk.org (duke) Date: Wed, 30 Jul 2025 22:41:12 GMT Subject: Withdrawn: 8356548: Avoid using ASM to parse latest class files in tests In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:57:05 GMT, Chen Liang wrote: > For early eval; test by changing the ClassReader max accepted version of test ASM to 24 instead of 25 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25124 From sspitsyn at openjdk.org Wed Jul 30 22:52:56 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 30 Jul 2025 22:52:56 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException [v5] In-Reply-To: References: Message-ID: On Wed, 30 Jul 2025 15:22:12 GMT, Patricio Chilano Mateo wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: restored the tweak in the JavaThread::sleep_nanos > > src/hotspot/share/runtime/javaThread.cpp line 2121: > >> 2119: for (;;) { >> 2120: if (has_async_exception_condition()) { >> 2121: return false; > > The comment above `JavaThread::sleep_nanos` should be updated about this case. > Also, back in `JVM_SleepNanos` we should probably skip throwing IE for this case (even though it will be overwritten by the async one later). Good suggestion, will address it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26365#discussion_r2244007729 From sspitsyn at openjdk.org Thu Jul 31 03:37:35 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 31 Jul 2025 03:37:35 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException [v6] In-Reply-To: References: Message-ID: > If JVMTI `StopThread` is done when the thread is in certain various states (but not all states), after the `async` exception is delivered and handled, hotspot leaves the thread's `interrupted` flag set. The end result is the next time the thread does something like `Thread.sleep()`, it will immediately get an `InterruptedException`. > > The fix is to clear the `interrupted` flag in the `JavaThread::handle_async_exception()` after an `async` pending exception has been set to be thrown with the `set_pending_exception()`. > > There are a couple of concerns with this fix which would be nice to sort out with reviewers: > 1. The proposed fix may clear the interrupt state when it was already set prior to the issuing of the `StopThread()` (this concern was raised by @dholmes-ora in a comment of this JBS issue) > 2. The impacted code path is shared between the class `InstallAsyncExceptionHandshakeClosure` used by the JVMTI `StopThread` implementation and the class `ScopedAsyncExceptionHandshakeClosure` used by the `ScopedMemoryAccess` > > I feel that clearing the `interrupted` flag byt the `JavaThread::handle_async_exception()` is a right thing to do even though it was set before the call to `JavaThread::install_async_exception()`. Also, it has to be done for both `StopThread` and `ScopedMemoryAccess`. > > The fix also includes minor tweaks of the test `StopThreadTest` to make the issue reproducible with it. > > Testing: > - Mach5 tiers 1-6 are passed > - Ran the updated reproducer test `hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest` Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review: correct comment in sleep_nanos and avoid trowing IE in JVM_SleepNanos ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26365/files - new: https://git.openjdk.org/jdk/pull/26365/files/a46ef6f5..476665cb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26365&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26365&range=04-05 Stats: 7 lines in 2 files changed: 1 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26365.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26365/head:pull/26365 PR: https://git.openjdk.org/jdk/pull/26365 From sspitsyn at openjdk.org Thu Jul 31 03:45:10 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 31 Jul 2025 03:45:10 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException [v7] In-Reply-To: References: Message-ID: > If JVMTI `StopThread` is done when the thread is in certain various states (but not all states), after the `async` exception is delivered and handled, hotspot leaves the thread's `interrupted` flag set. The end result is the next time the thread does something like `Thread.sleep()`, it will immediately get an `InterruptedException`. > > The fix is to clear the `interrupted` flag in the `JavaThread::handle_async_exception()` after an `async` pending exception has been set to be thrown with the `set_pending_exception()`. > > There are a couple of concerns with this fix which would be nice to sort out with reviewers: > 1. The proposed fix may clear the interrupt state when it was already set prior to the issuing of the `StopThread()` (this concern was raised by @dholmes-ora in a comment of this JBS issue) > 2. The impacted code path is shared between the class `InstallAsyncExceptionHandshakeClosure` used by the JVMTI `StopThread` implementation and the class `ScopedAsyncExceptionHandshakeClosure` used by the `ScopedMemoryAccess` > > I feel that clearing the `interrupted` flag byt the `JavaThread::handle_async_exception()` is a right thing to do even though it was set before the call to `JavaThread::install_async_exception()`. Also, it has to be done for both `StopThread` and `ScopedMemoryAccess`. > > The fix also includes minor tweaks of the test `StopThreadTest` to make the issue reproducible with it. > > Testing: > - Mach5 tiers 1-6 are passed > - Ran the updated reproducer test `hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest` Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: fixed typo: in latest update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26365/files - new: https://git.openjdk.org/jdk/pull/26365/files/476665cb..11bc5a78 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26365&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26365&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26365.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26365/head:pull/26365 PR: https://git.openjdk.org/jdk/pull/26365 From duke at openjdk.org Thu Jul 31 04:54:39 2025 From: duke at openjdk.org (Lei Zhu) Date: Thu, 31 Jul 2025 04:54:39 GMT Subject: RFR: 8362533: Tests sun/management/jmxremote/bootstrap/* duplicate VM flags [v2] In-Reply-To: References: Message-ID: <0XgKkckS1Dk_jyA5ojiQzdopsrs-O5KLu__l7xsQV3g=.da19026b-55a6-4972-9e65-0f712b98ac99@github.com> > Hi all, > > `ProcessTools.createTestJavaProcessBuilder(String... command)` will call `jdk.test.lib.Utils#getTestJavaOpts`, so remove the duplicate vm flags. Trivial fix. > > Thanks! Lei Zhu has updated the pull request incrementally with one additional commit since the last revision: remove duplicate -cp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26555/files - new: https://git.openjdk.org/jdk/pull/26555/files/8e3ddcd7..7a5ff15f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26555&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26555&range=00-01 Stats: 9 lines in 3 files changed: 0 ins; 9 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26555.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26555/head:pull/26555 PR: https://git.openjdk.org/jdk/pull/26555 From duke at openjdk.org Thu Jul 31 04:56:54 2025 From: duke at openjdk.org (Lei Zhu) Date: Thu, 31 Jul 2025 04:56:54 GMT Subject: RFR: 8362533: Tests sun/management/jmxremote/bootstrap/* duplicate VM flags [v2] In-Reply-To: References: Message-ID: <-Nda3pgRAgrJ0gcMYVu1N2YjAKSsMsALexoVdOjK0ks=.54721a85-6b51-4f5b-bdf7-8aa683808fc3@github.com> On Wed, 30 Jul 2025 22:05:15 GMT, Leonid Mesnik wrote: > Comment generic to all three test fixes: Shouldn't be command.add(TEST_CLASS_PATH); command.add(className); also removed? The ProcessTools.createTestJavaProcessBuilder(command); uses standard classpath that should fit this test needs. If needed, property "test.noclasspath", mgith be use to don't add classpath. See jdk/test/lib/process/ProcessTools.java:161 private static ProcessBuilder createJavaProcessBuilder(String... command) { ... String noCPString = System.getProperty("test.noclasspath", "false"); Thanks for review, the duplicate `-cp` has been removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26555#discussion_r2244348086 From ghan at openjdk.org Thu Jul 31 05:54:25 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 31 Jul 2025 05:54:25 GMT Subject: RFR: 8364312: debug agent should set FD_CLOEXEC flag rather than explicitly closing every open file Message-ID: <3BICmMnnerR4xK3jipz7_6tG47e_tD64PoCreMqsRLE=.aa834646-e1cd-49aa-a568-408317791e00@github.com> Create a new function that marks all file descriptors found in /proc/self/fd with the FD_CLOEXEC flag to ensure they are automatically closed upon execution of a new program via exec(). ------------- Commit messages: - 8364312: debug agent should set FD_CLOEXEC flag rather than explicitly closing every open file Changes: https://git.openjdk.org/jdk/pull/26568/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26568&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364312 Stats: 49 lines in 1 file changed: 19 ins; 18 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/26568.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26568/head:pull/26568 PR: https://git.openjdk.org/jdk/pull/26568 From lmesnik at openjdk.org Thu Jul 31 06:06:00 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 31 Jul 2025 06:06:00 GMT Subject: RFR: 8362533: Tests sun/management/jmxremote/bootstrap/* duplicate VM flags [v2] In-Reply-To: <0XgKkckS1Dk_jyA5ojiQzdopsrs-O5KLu__l7xsQV3g=.da19026b-55a6-4972-9e65-0f712b98ac99@github.com> References: <0XgKkckS1Dk_jyA5ojiQzdopsrs-O5KLu__l7xsQV3g=.da19026b-55a6-4972-9e65-0f712b98ac99@github.com> Message-ID: On Thu, 31 Jul 2025 04:54:39 GMT, Lei Zhu wrote: >> Hi all, >> >> `ProcessTools.createTestJavaProcessBuilder(String... command)` will call `jdk.test.lib.Utils#getTestJavaOpts`, so remove the duplicate vm flags. Trivial fix. >> >> Thanks! > > Lei Zhu has updated the pull request incrementally with one additional commit since the last revision: > > remove duplicate -cp Looks good! Thank you for fixing and addressing feedback. ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26555#pullrequestreview-3074076889 From duke at openjdk.org Thu Jul 31 07:11:54 2025 From: duke at openjdk.org (duke) Date: Thu, 31 Jul 2025 07:11:54 GMT Subject: RFR: 8362533: Tests sun/management/jmxremote/bootstrap/* duplicate VM flags [v2] In-Reply-To: <0XgKkckS1Dk_jyA5ojiQzdopsrs-O5KLu__l7xsQV3g=.da19026b-55a6-4972-9e65-0f712b98ac99@github.com> References: <0XgKkckS1Dk_jyA5ojiQzdopsrs-O5KLu__l7xsQV3g=.da19026b-55a6-4972-9e65-0f712b98ac99@github.com> Message-ID: On Thu, 31 Jul 2025 04:54:39 GMT, Lei Zhu wrote: >> Hi all, >> >> `ProcessTools.createTestJavaProcessBuilder(String... command)` will call `jdk.test.lib.Utils#getTestJavaOpts`, so remove the duplicate vm flags. Trivial fix. >> >> Thanks! > > Lei Zhu has updated the pull request incrementally with one additional commit since the last revision: > > remove duplicate -cp @Korov Your change (at version 7a5ff15f74afaa6bbe3e42f4458cd131ba4b8319) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26555#issuecomment-3138803482 From sspitsyn at openjdk.org Thu Jul 31 07:18:54 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 31 Jul 2025 07:18:54 GMT Subject: RFR: 8362533: Tests sun/management/jmxremote/bootstrap/* duplicate VM flags [v2] In-Reply-To: <0XgKkckS1Dk_jyA5ojiQzdopsrs-O5KLu__l7xsQV3g=.da19026b-55a6-4972-9e65-0f712b98ac99@github.com> References: <0XgKkckS1Dk_jyA5ojiQzdopsrs-O5KLu__l7xsQV3g=.da19026b-55a6-4972-9e65-0f712b98ac99@github.com> Message-ID: On Thu, 31 Jul 2025 04:54:39 GMT, Lei Zhu wrote: >> Hi all, >> >> `ProcessTools.createTestJavaProcessBuilder(String... command)` will call `jdk.test.lib.Utils#getTestJavaOpts`, so remove the duplicate vm flags. Trivial fix. >> >> Thanks! > > Lei Zhu has updated the pull request incrementally with one additional commit since the last revision: > > remove duplicate -cp Looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26555#pullrequestreview-3074246189 From sspitsyn at openjdk.org Thu Jul 31 07:31:54 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 31 Jul 2025 07:31:54 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException [v5] In-Reply-To: References: Message-ID: On Wed, 30 Jul 2025 22:49:51 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/runtime/javaThread.cpp line 2121: >> >>> 2119: for (;;) { >>> 2120: if (has_async_exception_condition()) { >>> 2121: return false; >> >> The comment above `JavaThread::sleep_nanos` should be updated about this case. >> Also, back in `JVM_SleepNanos` we should probably skip throwing IE for this case (even though it will be overwritten by the async one later). > > Good suggestion, addressed now. The mach5 tiers 1-6 are good with the latest pushes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26365#discussion_r2244579652 From alanb at openjdk.org Thu Jul 31 07:42:55 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 31 Jul 2025 07:42:55 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException [v7] In-Reply-To: References: Message-ID: On Thu, 31 Jul 2025 03:45:10 GMT, Serguei Spitsyn wrote: >> If JVMTI `StopThread` is done when the thread is in certain various states (but not all states), after the `async` exception is delivered and handled, hotspot leaves the thread's `interrupted` flag set. The end result is the next time the thread does something like `Thread.sleep()`, it will immediately get an `InterruptedException`. >> >> The fix is to clear the `interrupted` flag in the `JavaThread::handle_async_exception()` after an `async` pending exception has been set to be thrown with the `set_pending_exception()`. >> >> There are a couple of concerns with this fix which would be nice to sort out with reviewers: >> 1. The proposed fix may clear the interrupt state when it was already set prior to the issuing of the `StopThread()` (this concern was raised by @dholmes-ora in a comment of this JBS issue) >> 2. The impacted code path is shared between the class `InstallAsyncExceptionHandshakeClosure` used by the JVMTI `StopThread` implementation and the class `ScopedAsyncExceptionHandshakeClosure` used by the `ScopedMemoryAccess` >> >> I feel that clearing the `interrupted` flag byt the `JavaThread::handle_async_exception()` is a right thing to do even though it was set before the call to `JavaThread::install_async_exception()`. Also, it has to be done for both `StopThread` and `ScopedMemoryAccess`. >> >> The fix also includes minor tweaks of the test `StopThreadTest` to make the issue reproducible with it. >> >> Testing: >> - Mach5 tiers 1-6 are passed >> - Ran the updated reproducer test `hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest` > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > fixed typo: in latest update Thanks for getting this to a good place. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26365#pullrequestreview-3074321124 From duke at openjdk.org Thu Jul 31 09:03:00 2025 From: duke at openjdk.org (Lei Zhu) Date: Thu, 31 Jul 2025 09:03:00 GMT Subject: RFR: 8362533: Tests sun/management/jmxremote/bootstrap/* duplicate VM flags [v2] In-Reply-To: References: <0XgKkckS1Dk_jyA5ojiQzdopsrs-O5KLu__l7xsQV3g=.da19026b-55a6-4972-9e65-0f712b98ac99@github.com> Message-ID: On Thu, 31 Jul 2025 07:15:56 GMT, Serguei Spitsyn wrote: >> Lei Zhu has updated the pull request incrementally with one additional commit since the last revision: >> >> remove duplicate -cp > > Looks good. @sspitsyn Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26555#issuecomment-3139123313 From ghan at openjdk.org Thu Jul 31 09:51:35 2025 From: ghan at openjdk.org (Guanqiang Han) Date: Thu, 31 Jul 2025 09:51:35 GMT Subject: RFR: 8364312: debug agent should set FD_CLOEXEC flag rather than explicitly closing every open file [v2] In-Reply-To: <3BICmMnnerR4xK3jipz7_6tG47e_tD64PoCreMqsRLE=.aa834646-e1cd-49aa-a568-408317791e00@github.com> References: <3BICmMnnerR4xK3jipz7_6tG47e_tD64PoCreMqsRLE=.aa834646-e1cd-49aa-a568-408317791e00@github.com> Message-ID: > Create a new function that marks all file descriptors found in /proc/self/fd with the FD_CLOEXEC flag to ensure they are automatically closed upon execution of a new program via exec(). Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision: Update exec_md.c correct an compilation error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26568/files - new: https://git.openjdk.org/jdk/pull/26568/files/54fd3fb3..2e94cb44 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26568&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26568&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26568.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26568/head:pull/26568 PR: https://git.openjdk.org/jdk/pull/26568 From kevinw at openjdk.org Thu Jul 31 13:15:02 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 31 Jul 2025 13:15:02 GMT Subject: RFR: 8362533: Tests sun/management/jmxremote/bootstrap/* duplicate VM flags [v2] In-Reply-To: <0XgKkckS1Dk_jyA5ojiQzdopsrs-O5KLu__l7xsQV3g=.da19026b-55a6-4972-9e65-0f712b98ac99@github.com> References: <0XgKkckS1Dk_jyA5ojiQzdopsrs-O5KLu__l7xsQV3g=.da19026b-55a6-4972-9e65-0f712b98ac99@github.com> Message-ID: On Thu, 31 Jul 2025 04:54:39 GMT, Lei Zhu wrote: >> Hi all, >> >> `ProcessTools.createTestJavaProcessBuilder(String... command)` will call `jdk.test.lib.Utils#getTestJavaOpts`, so remove the duplicate vm flags. Trivial fix. >> >> Thanks! > > Lei Zhu has updated the pull request incrementally with one additional commit since the last revision: > > remove duplicate -cp Looks good. (More than trivial, but good. 8-) ) ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26555#pullrequestreview-3075384021 From duke at openjdk.org Thu Jul 31 13:15:03 2025 From: duke at openjdk.org (Lei Zhu) Date: Thu, 31 Jul 2025 13:15:03 GMT Subject: Integrated: 8362533: Tests sun/management/jmxremote/bootstrap/* duplicate VM flags In-Reply-To: References: Message-ID: On Wed, 30 Jul 2025 14:47:54 GMT, Lei Zhu wrote: > Hi all, > > `ProcessTools.createTestJavaProcessBuilder(String... command)` will call `jdk.test.lib.Utils#getTestJavaOpts`, so remove the duplicate vm flags. Trivial fix. > > Thanks! This pull request has now been integrated. Changeset: 458f033d Author: Lei Zhu Committer: Kevin Walls URL: https://git.openjdk.org/jdk/commit/458f033d4dd3c646028b2f9bab88f9a308cad4af Stats: 21 lines in 3 files changed: 0 ins; 17 del; 4 mod 8362533: Tests sun/management/jmxremote/bootstrap/* duplicate VM flags Reviewed-by: lmesnik, sspitsyn, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/26555 From alanb at openjdk.org Thu Jul 31 15:47:55 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 31 Jul 2025 15:47:55 GMT Subject: RFR: 8364227: MBeanServer registerMBean throws NPE [v3] In-Reply-To: References: Message-ID: On Wed, 30 Jul 2025 17:54:34 GMT, Kevin Walls wrote: >> A long-standing omission where MBeanServer.registerMBean documents exception behaviour, but we actually throw an NPE. We should recognise a null object and return the wrapped exception we document. >> >> This wrapping behaviour is common elsewhere in this area, e.g. unregisterMBean which checks for a null name and throws RuntimeOperationsException. >> >> Docs: >> https://docs.oracle.com/en/java/javase/24/docs/api/java.management/javax/management/MBeanServer.html#registerMBean(java.lang.Object,javax.management.ObjectName) >> >> Throws: >> RuntimeOperationsException - Wraps a java.lang.IllegalArgumentException: The object passed in parameter is null or no object name is specified. >> >> >> Current behaviour: >> >> >> $ java MBS_NPE.java >> Exception in thread "main" java.lang.NullPointerException: Cannot invoke "Object.getClass()" because "object" is null >> at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:296) >> at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511) >> at MBS_NPE.main(MBS_NPE.java:11) >> >> >> Should be changed to: >> >> >> $ java MBS_NPE.java >> javax.management.RuntimeOperationsException: Exception occurred trying to register the MBean >> at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:297) >> at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511) >> at MBS_NPE.main(MBS_NPE.java:11) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:565) >> at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.execute(SourceLauncher.java:258) >> at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.run(SourceLauncher.java:138) >> at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.main(SourceLauncher.java:76) >> Caused by: java.lang.IllegalArgumentException: Object cannot be null >> at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:295) >> ... 7 more > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > One more case I edited the CSR to make it a bit clearer, and added myself as Reviewer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26548#issuecomment-3140463795 From alanb at openjdk.org Thu Jul 31 15:50:55 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 31 Jul 2025 15:50:55 GMT Subject: RFR: 8364227: MBeanServer registerMBean throws NPE [v3] In-Reply-To: References: Message-ID: On Wed, 30 Jul 2025 17:54:34 GMT, Kevin Walls wrote: >> A long-standing omission where MBeanServer.registerMBean documents exception behaviour, but we actually throw an NPE. We should recognise a null object and return the wrapped exception we document. >> >> This wrapping behaviour is common elsewhere in this area, e.g. unregisterMBean which checks for a null name and throws RuntimeOperationsException. >> >> Docs: >> https://docs.oracle.com/en/java/javase/24/docs/api/java.management/javax/management/MBeanServer.html#registerMBean(java.lang.Object,javax.management.ObjectName) >> >> Throws: >> RuntimeOperationsException - Wraps a java.lang.IllegalArgumentException: The object passed in parameter is null or no object name is specified. >> >> >> Current behaviour: >> >> >> $ java MBS_NPE.java >> Exception in thread "main" java.lang.NullPointerException: Cannot invoke "Object.getClass()" because "object" is null >> at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:296) >> at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511) >> at MBS_NPE.main(MBS_NPE.java:11) >> >> >> Should be changed to: >> >> >> $ java MBS_NPE.java >> javax.management.RuntimeOperationsException: Exception occurred trying to register the MBean >> at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:297) >> at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:511) >> at MBS_NPE.main(MBS_NPE.java:11) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:565) >> at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.execute(SourceLauncher.java:258) >> at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.run(SourceLauncher.java:138) >> at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.main(SourceLauncher.java:76) >> Caused by: java.lang.IllegalArgumentException: Object cannot be null >> at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:295) >> ... 7 more > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > One more case test/jdk/javax/management/MBeanServer/ExceptionTestNulls.java line 29: > 27: * @summary Test various null parameters and verify Exceptions thrown > 28: * @modules java.management.rmi > 29: * @run main ExceptionTestNulls The test looks okay but I wonder if you've considered making it a JUnit test? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26548#discussion_r2245767679 From pchilanomate at openjdk.org Thu Jul 31 15:57:55 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 31 Jul 2025 15:57:55 GMT Subject: RFR: 8306324: StopThread results in thread being marked as interrupted, leading to unexpected InterruptedException [v7] In-Reply-To: References: Message-ID: <0pW1wrr7ZPPK3faGmXIAhDi_f9pTaH-e6g8yVfw7g5o=.b068df42-b52d-4f1c-8c32-aaddd496d81f@github.com> On Thu, 31 Jul 2025 03:45:10 GMT, Serguei Spitsyn wrote: >> If JVMTI `StopThread` is done when the thread is in certain various states (but not all states), after the `async` exception is delivered and handled, hotspot leaves the thread's `interrupted` flag set. The end result is the next time the thread does something like `Thread.sleep()`, it will immediately get an `InterruptedException`. >> >> The fix is to clear the `interrupted` flag in the `JavaThread::handle_async_exception()` after an `async` pending exception has been set to be thrown with the `set_pending_exception()`. >> >> There are a couple of concerns with this fix which would be nice to sort out with reviewers: >> 1. The proposed fix may clear the interrupt state when it was already set prior to the issuing of the `StopThread()` (this concern was raised by @dholmes-ora in a comment of this JBS issue) >> 2. The impacted code path is shared between the class `InstallAsyncExceptionHandshakeClosure` used by the JVMTI `StopThread` implementation and the class `ScopedAsyncExceptionHandshakeClosure` used by the `ScopedMemoryAccess` >> >> I feel that clearing the `interrupted` flag byt the `JavaThread::handle_async_exception()` is a right thing to do even though it was set before the call to `JavaThread::install_async_exception()`. Also, it has to be done for both `StopThread` and `ScopedMemoryAccess`. >> >> The fix also includes minor tweaks of the test `StopThreadTest` to make the issue reproducible with it. >> >> Testing: >> - Mach5 tiers 1-6 are passed >> - Ran the updated reproducer test `hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest` > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > fixed typo: in latest update Thanks Serguei, looks good to me. src/hotspot/share/prims/jvm.cpp line 2899: > 2897: // An asynchronous exception could have been thrown on > 2898: // us while we were sleeping. We do not overwrite those. > 2899: if (!HAS_PENDING_EXCEPTION) { Maybe not for this bug but we have this `HAS_PENDING_EXCEPTION` check here and further up but I don't see how we can have a pending exception when calling this method. Based on the comment here seems we just wanted to check the async ones as added now. ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26365#pullrequestreview-3075988282 PR Review Comment: https://git.openjdk.org/jdk/pull/26365#discussion_r2245769502 From kevinw at openjdk.org Thu Jul 31 16:49:54 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 31 Jul 2025 16:49:54 GMT Subject: RFR: 8364227: MBeanServer registerMBean throws NPE [v3] In-Reply-To: References: Message-ID: <9SkMM4987vYvh22RZYgvyLyE4V472fhsjN1HIOccMUM=.23262968-ee25-483a-86ec-0009bf25c5fd@github.com> On Thu, 31 Jul 2025 15:48:12 GMT, Alan Bateman wrote: >> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: >> >> One more case > > test/jdk/javax/management/MBeanServer/ExceptionTestNulls.java line 29: > >> 27: * @summary Test various null parameters and verify Exceptions thrown >> 28: * @modules java.management.rmi >> 29: * @run main ExceptionTestNulls > > The test looks okay but I wonder if you've considered making it a JUnit test? Thanks for the CSR update. I was just following the norm for the area with the test. _Should_ I make this a junit test, is that required, desirable, unnecessary... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26548#discussion_r2245897538 From abarashev at openjdk.org Thu Jul 31 20:55:48 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 31 Jul 2025 20:55:48 GMT Subject: RFR: 8364484: misc tests fail with Received fatal alert: handshake_failure Message-ID: <0zVaQ4IbW2cqGEmbZ9Tnbj3uvAM43Ru4tWXtT3N49WI=.1d71839b-46ba-4c42-ac5b-55bc15f0d42d@github.com> Test was broken by [JDK-8359956](https://bugs.openjdk.org/browse/JDK-8359956) change. ------------- Commit messages: - 8364484 misc tests fail with Received fatal alert: handshake_failure Changes: https://git.openjdk.org/jdk/pull/26583/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26583&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364484 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26583.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26583/head:pull/26583 PR: https://git.openjdk.org/jdk/pull/26583 From abarashev at openjdk.org Thu Jul 31 21:00:09 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 31 Jul 2025 21:00:09 GMT Subject: RFR: 8364484: misc tests fail with Received fatal alert: handshake_failure [v2] In-Reply-To: <0zVaQ4IbW2cqGEmbZ9Tnbj3uvAM43Ru4tWXtT3N49WI=.1d71839b-46ba-4c42-ac5b-55bc15f0d42d@github.com> References: <0zVaQ4IbW2cqGEmbZ9Tnbj3uvAM43Ru4tWXtT3N49WI=.1d71839b-46ba-4c42-ac5b-55bc15f0d42d@github.com> Message-ID: > Test was broken by [JDK-8359956](https://bugs.openjdk.org/browse/JDK-8359956) change. Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: This test has a 2nd main method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26583/files - new: https://git.openjdk.org/jdk/pull/26583/files/7139cb3c..a4c25654 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26583&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26583&range=00-01 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26583.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26583/head:pull/26583 PR: https://git.openjdk.org/jdk/pull/26583 From ascarpino at openjdk.org Thu Jul 31 21:15:55 2025 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Thu, 31 Jul 2025 21:15:55 GMT Subject: RFR: 8364484: misc tests fail with Received fatal alert: handshake_failure [v2] In-Reply-To: References: <0zVaQ4IbW2cqGEmbZ9Tnbj3uvAM43Ru4tWXtT3N49WI=.1d71839b-46ba-4c42-ac5b-55bc15f0d42d@github.com> Message-ID: On Thu, 31 Jul 2025 21:00:09 GMT, Artur Barashev wrote: >> Test was broken by [JDK-8359956](https://bugs.openjdk.org/browse/JDK-8359956) change. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > This test has a 2nd main method The change looks fine ------------- Marked as reviewed by ascarpino (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26583#pullrequestreview-3076899452 From hchao at openjdk.org Thu Jul 31 21:26:59 2025 From: hchao at openjdk.org (Hai-May Chao) Date: Thu, 31 Jul 2025 21:26:59 GMT Subject: RFR: 8364484: misc tests fail with Received fatal alert: handshake_failure [v2] In-Reply-To: References: <0zVaQ4IbW2cqGEmbZ9Tnbj3uvAM43Ru4tWXtT3N49WI=.1d71839b-46ba-4c42-ac5b-55bc15f0d42d@github.com> Message-ID: <6qjc4GhBwGw7iXBS4egXWWkXOwgbpIEH24SqKaC8tK8=.88b9d00c-810f-41c2-908c-ea6f081ad552@github.com> On Thu, 31 Jul 2025 21:00:09 GMT, Artur Barashev wrote: >> Test was broken by [JDK-8359956](https://bugs.openjdk.org/browse/JDK-8359956) change. > > Artur Barashev has updated the pull request incrementally with one additional commit since the last revision: > > This test has a 2nd main method Looks good. ------------- PR Review: https://git.openjdk.org/jdk/pull/26583#pullrequestreview-3076921185 From abarashev at openjdk.org Thu Jul 31 21:27:00 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 31 Jul 2025 21:27:00 GMT Subject: Integrated: 8364484: misc tests fail with Received fatal alert: handshake_failure In-Reply-To: <0zVaQ4IbW2cqGEmbZ9Tnbj3uvAM43Ru4tWXtT3N49WI=.1d71839b-46ba-4c42-ac5b-55bc15f0d42d@github.com> References: <0zVaQ4IbW2cqGEmbZ9Tnbj3uvAM43Ru4tWXtT3N49WI=.1d71839b-46ba-4c42-ac5b-55bc15f0d42d@github.com> Message-ID: On Thu, 31 Jul 2025 20:49:52 GMT, Artur Barashev wrote: > Test was broken by [JDK-8359956](https://bugs.openjdk.org/browse/JDK-8359956) change. This pull request has now been integrated. Changeset: 724e8c07 Author: Artur Barashev URL: https://git.openjdk.org/jdk/commit/724e8c076e1aed05de893ef9366af0e62cc2ac2b Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod 8364484: misc tests fail with Received fatal alert: handshake_failure Reviewed-by: ascarpino ------------- PR: https://git.openjdk.org/jdk/pull/26583