Re: RFR: 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump

2023-11-27 Thread David Holmes
On Tue, 28 Nov 2023 07:38:06 GMT, Taizo Kurashige wrote: >> src/jdk.jcmd/share/man/jcmd.1 line 1: >> >>> 1: .\" Copyright (c) 2012, 2023, Oracle and/or its affiliates. All rights >>> reserved. >> >> This file is generated from markdown sources that Oracle has to maintain. >> Please work with

Re: RFR: 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump

2023-11-27 Thread Taizo Kurashige
On Mon, 30 Oct 2023 16:09:50 GMT, Erik Gahlin wrote: >> Hi, >> >> I fixed the typos for JFR.start and JFR.dump. >> Acconding to issue's description, there is some typo in JFR.stop >> documentation, but I couldn't find that. I confirmed that there is no such >> typo in this repository. So I tho

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v8]

2023-11-27 Thread Stefan Karlsson
On Tue, 28 Nov 2023 05:34:39 GMT, David Holmes wrote: >> Stefan Karlsson has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fix indentation > > test/hotspot/jtreg/runtime/Monitor/MonitorWithDeadObjectTest.java line 88: > >> 86: //

Re: RFR: 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump

2023-11-27 Thread Taizo Kurashige
On Mon, 30 Oct 2023 22:39:34 GMT, David Holmes wrote: >> Hi, >> >> I fixed the typos for JFR.start and JFR.dump. >> Acconding to issue's description, there is some typo in JFR.stop >> documentation, but I couldn't find that. I confirmed that there is no such >> typo in this repository. So I th

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v8]

2023-11-27 Thread Stefan Karlsson
On Tue, 28 Nov 2023 05:26:32 GMT, David Holmes wrote: >> Stefan Karlsson has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fix indentation > > test/hotspot/jtreg/runtime/Monitor/MonitorWithDeadObjectTest.java line 35: > >> 33: >> 34: /*

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v8]

2023-11-27 Thread Stefan Karlsson
On Tue, 28 Nov 2023 05:33:08 GMT, David Holmes wrote: >> @dcubed-ojdk These are the thread routines passed to `pthread_create` and >> must be typed as `void *(*start_routine)(void*)`. > > Though I just noticed the parameter is missing. As @stefank has pointed out > this was copied from another

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v8]

2023-11-27 Thread Stefan Karlsson
On Tue, 28 Nov 2023 05:31:11 GMT, David Holmes wrote: >> test/hotspot/jtreg/runtime/Monitor/libMonitorWithDeadObjectTest.c line 110: >> >>> 108: >>> 109: // Let the GC clear the weak reference to the object. >>> 110: system_gc(env); >> >> A single GC may not be enough... > > @dcubed-ojdk t

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v8]

2023-11-27 Thread Stefan Karlsson
On Mon, 27 Nov 2023 22:46:15 GMT, Daniel D. Daugherty wrote: >> Stefan Karlsson has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fix indentation > > test/hotspot/jtreg/runtime/Monitor/libMonitorWithDeadObjectTest.c line 2: > >> 1: /* >>

Re: RFR: 8320652: ThreadInfo.isInNative needs to be updated to say what executing native code means [v2]

2023-11-27 Thread Alan Bateman
On Tue, 28 Nov 2023 06:06:58 GMT, David Holmes wrote: > Note that there is no answer for the "syscall" case mentioned as it depends > on the code that makes the syscall: if from a native method then yes; if from > the VM then no. Right, if the thread invokes a Java native method then it may or

Re: RFR: 8320652: ThreadInfo.isInNative needs to be updated to say what executing native code means [v2]

2023-11-27 Thread David Holmes
On Tue, 28 Nov 2023 06:00:54 GMT, David Holmes wrote: >> This `isInNative` method intends to provide a way to tell if the thread has >> transitioned from executing Java method to a native method. JVM interpreter >> and compiler provide the support for Java language which is why I think such >

Re: RFR: 8320652: ThreadInfo.isInNative needs to be updated to say what executing native code means [v2]

2023-11-27 Thread David Holmes
On Mon, 27 Nov 2023 20:59:54 GMT, Mandy Chung wrote: >> I would agree, it should state if runtime functions (including those doing a >> syscall) will be counted here. (For JNi i would not need it to be spelled >> out, on the other hand it would help, since it makes clear we don’t mean c2 >> co

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v5]

2023-11-27 Thread David Holmes
On Mon, 27 Nov 2023 02:08:33 GMT, David Holmes wrote: >> Stefan Karlsson has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Split test and use othervm > > test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.j

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v8]

2023-11-27 Thread David Holmes
On Tue, 28 Nov 2023 05:25:17 GMT, David Holmes wrote: >> test/hotspot/jtreg/runtime/Monitor/libMonitorWithDeadObjectTest.c line 131: >> >>> 129: if ((*jvm)->DetachCurrentThread(jvm) != JNI_OK) >>> die("DetachCurrentThread"); >>> 130: >>> 131: return NULL; >> >> Why is this function return

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v8]

2023-11-27 Thread David Holmes
On Mon, 27 Nov 2023 22:50:46 GMT, Daniel D. Daugherty wrote: >> Stefan Karlsson has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fix indentation > > test/hotspot/jtreg/runtime/Monitor/libMonitorWithDeadObjectTest.c line 110: > >> 108:

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v8]

2023-11-27 Thread David Holmes
On Mon, 27 Nov 2023 20:20:01 GMT, Stefan Karlsson wrote: >> In the rewrites made for: >> [JDK-8318757](https://bugs.openjdk.org/browse/JDK-8318757) `VM_ThreadDump >> asserts in interleaved ObjectMonitor::deflate_monitor calls` >> >> I removed the filtering of *owned ObjectMonitors with dead obj

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v5]

2023-11-27 Thread David Holmes
On Mon, 27 Nov 2023 09:27:40 GMT, Stefan Karlsson wrote: >> test/hotspot/jtreg/runtime/Monitor/libMonitorWithDeadObjectTest.c line 47: >> >>> 45: >>> 46: #define check(env, what, msg) \ >>> 47: check_exception((env), (msg)); \ >> >> I'm not understandin

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v8]

2023-11-27 Thread David Holmes
On Mon, 27 Nov 2023 22:53:16 GMT, Daniel D. Daugherty wrote: >> Stefan Karlsson has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fix indentation > > test/hotspot/jtreg/runtime/Monitor/libMonitorWithDeadObjectTest.c line 131: > >> 129:

Re: RFR: 8319935: Ensure only one JvmtiThreadState is created for one JavaThread associated with attached native thread [v5]

2023-11-27 Thread Serguei Spitsyn
On Mon, 13 Nov 2023 23:33:50 GMT, Man Cao wrote: >> Jiangli Zhou has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Address Serguei Spitsyn's comments/suggestions: >> - Remove the redundant thread->is_Java_thread() check from >> JvmtiSam

Re: RFR: 8319935: Ensure only one JvmtiThreadState is created for one JavaThread associated with attached native thread [v3]

2023-11-27 Thread Serguei Spitsyn
On Wed, 22 Nov 2023 23:58:54 GMT, Jiangli Zhou wrote: >> Thank you for filing and fixing this issue! I'm kind of late here. Sorry >> for that. >> Is it hard to create a JTreg test for an attaching native thread? I can help >> if you have a standalone prototype. >> You can look for some example

Re: RFR: 8315149: Add hsperf counters for CPU time of internal GC threads [v48]

2023-11-27 Thread Jonathan Joo
> 8315149: Add hsperf counters for CPU time of internal GC threads Jonathan Joo has updated the pull request incrementally with two additional commits since the last revision: - Fix namespace issues (2) Co-authored-by: Stefan Johansson <54407259+kstef...@users.noreply.github.com> - Fix

Re: RFR: 8320532: Remove Thread/ThreadGroup suspend/resume

2023-11-27 Thread Serguei Spitsyn
On Thu, 23 Nov 2023 09:18:44 GMT, Alan Bateman wrote: > The deadlock prone Thread/ThreadGroup suspend/resume were deprecated since > JDK 1.2, deprecated for removal in Java 14, and re-specified/degraded to > throw UnsupportedOperationException unconditionally in Java 19/20. Early in > Java 23

Re: RFR: 8320239: add dynamic switch for JvmtiVTMSTransitionDisabler sync protocol [v2]

2023-11-27 Thread Leonid Mesnik
On Fri, 17 Nov 2023 10:30:59 GMT, Serguei Spitsyn wrote: >> This is an update for a performance/scalability enhancement. >> >> The `JvmtiVTMSTransitionDisabler`sync protocol is on a performance critical >> path of the virtual threads mount state transitions (VTMS transitions). It >> has a noti

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v8]

2023-11-27 Thread Daniel D . Daugherty
On Thu, 23 Nov 2023 11:21:12 GMT, Stefan Karlsson wrote: >> test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java >> line 61: >> >>> 59: jniMonitorEnter(obj); >>> 60: obj = null; >>> 61: System.gc(); >> >> Again one gc() is generally n

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v8]

2023-11-27 Thread Daniel D . Daugherty
On Mon, 27 Nov 2023 20:20:01 GMT, Stefan Karlsson wrote: >> In the rewrites made for: >> [JDK-8318757](https://bugs.openjdk.org/browse/JDK-8318757) `VM_ThreadDump >> asserts in interleaved ObjectMonitor::deflate_monitor calls` >> >> I removed the filtering of *owned ObjectMonitors with dead obj

Re: RFR: 8320652: ThreadInfo.isInNative needs to be updated to say what executing native code means [v2]

2023-11-27 Thread Mandy Chung
On Mon, 27 Nov 2023 20:31:23 GMT, Alan Bateman wrote: >> This is a docs only change to j.l.management.ThreadInfo::isInNative. >> >> The method currently specifies that it tests if the thread is "executing >> native code via the Java Native Interface (JNI)". It would be clearer to >> say tha

Re: RFR: 8320652: ThreadInfo.isInNative needs to be updated to say what executing native code means [v2]

2023-11-27 Thread Mandy Chung
On Mon, 27 Nov 2023 20:38:03 GMT, Bernd wrote: >> src/java.management/share/classes/java/lang/management/ThreadInfo.java line >> 552: >> >>> 550: * java.lang.invoke.MethodHandle method handle} obtained from the >>> 551: * {@linkplain java.lang.foreign.Linker native linker}. >>> 552:

Re: RFR: 8320652: ThreadInfo.isInNative needs to be updated to say what executing native code means [v2]

2023-11-27 Thread Bernd
On Sat, 25 Nov 2023 07:32:20 GMT, Jaikiran Pai wrote: >> Alan Bateman 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

Re: RFR: 8320652: ThreadInfo.isInNative needs to be updated to say what executing native code means [v2]

2023-11-27 Thread Alan Bateman
> This is a docs only change to j.l.management.ThreadInfo::isInNative. > > The method currently specifies that it tests if the thread is "executing > native code via the Java Native Interface (JNI)". It would be clearer to say > that it tests if the thread is executing a native method, and ex

Re: RFR: 8320652: ThreadInfo.isInNative needs to be updated to say what executing native code means

2023-11-27 Thread Alan Bateman
On Mon, 27 Nov 2023 19:19:18 GMT, Mandy Chung wrote: > I can see why you left out the detail of a downcall handle. Maybe better to > link the text "method handle" to `Linker::downcallHandle` that is how such a > method handle is created. That's a good ideas, I've changed it to link to downcall

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v8]

2023-11-27 Thread Stefan Karlsson
> In the rewrites made for: > [JDK-8318757](https://bugs.openjdk.org/browse/JDK-8318757) `VM_ThreadDump > asserts in interleaved ObjectMonitor::deflate_monitor calls` > > I removed the filtering of *owned ObjectMonitors with dead objects*. The > reasoning was that you should never have an owned

Re: RFR: 8320652: ThreadInfo.isInNative needs to be updated to say what executing native code means

2023-11-27 Thread Mandy Chung
On Thu, 23 Nov 2023 10:25:31 GMT, Alan Bateman wrote: > This is a docs only change to j.l.management.ThreadInfo::isInNative. > > The method currently specifies that it tests if the thread is "executing > native code via the Java Native Interface (JNI)". It would be clearer to say > that it

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v7]

2023-11-27 Thread Serguei Spitsyn
On Mon, 27 Nov 2023 12:58:56 GMT, Stefan Karlsson wrote: >> In the rewrites made for: >> [JDK-8318757](https://bugs.openjdk.org/browse/JDK-8318757) `VM_ThreadDump >> asserts in interleaved ObjectMonitor::deflate_monitor calls` >> >> I removed the filtering of *owned ObjectMonitors with dead obj

Re: RFR: 8313355: javax/management/remote/mandatory/notif/ListenerScaleTest.java failed with "Exception: Failed: ratio=792.2791601423487"

2023-11-27 Thread Serguei Spitsyn
On Tue, 21 Nov 2023 13:01:55 GMT, Kevin Walls wrote: > This test fails occasionally, and can be tuned to avoid most of the failures > ever seen. > > It exists to check that notification work does not scale linearly with number > of MBeans, so it calculates a ratio of the time taken with one, a

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v7]

2023-11-27 Thread Stefan Karlsson
On Mon, 27 Nov 2023 19:04:42 GMT, Serguei Spitsyn wrote: > The fix looks good to me. How was this tested? Thanks. It was tested with the added and updated tests in GHA. Do you have any suggestions for more tests to run? > test/hotspot/jtreg/runtime/Monitor/libMonitorWithDeadObjectTest.c line 1

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v5]

2023-11-27 Thread Stefan Karlsson
On Mon, 27 Nov 2023 18:58:14 GMT, Serguei Spitsyn wrote: >> Yeah, I was thinking the same. Maybe @sspitsyn or @plummercj could give >> guidance here? > > This looks okay. I see no problem with it. OK. Thanks. - PR Review Comment: https://git.openjdk.org/jdk/pull/16783#discussion_r

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v7]

2023-11-27 Thread Serguei Spitsyn
On Mon, 27 Nov 2023 12:58:56 GMT, Stefan Karlsson wrote: >> In the rewrites made for: >> [JDK-8318757](https://bugs.openjdk.org/browse/JDK-8318757) `VM_ThreadDump >> asserts in interleaved ObjectMonitor::deflate_monitor calls` >> >> I removed the filtering of *owned ObjectMonitors with dead obj

Re: RFR: JDK-8318626: GetClassFields does not filter out ConstantPool.constantPoolOop field [v2]

2023-11-27 Thread Serguei Spitsyn
On Tue, 21 Nov 2023 02:58:47 GMT, Alex Menkov wrote: >> FilteredFieldStream is intended to filter out some fields which does not >> represent valid java objects. >> Currently the only filtered field is "constantPoolOop" from >> jdk.internal.reflect.ConstantPool class. >> The change fixes Filter

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v5]

2023-11-27 Thread Serguei Spitsyn
On Mon, 27 Nov 2023 09:44:23 GMT, Stefan Karlsson wrote: >> test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java >> line 53: >> >>> 51: private static native boolean hasEventPosted(); >>> 52: >>> 53: private static void jniMonitorEnterAndLetObjectDie

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v7]

2023-11-27 Thread Serguei Spitsyn
On Mon, 27 Nov 2023 12:58:56 GMT, Stefan Karlsson wrote: >> In the rewrites made for: >> [JDK-8318757](https://bugs.openjdk.org/browse/JDK-8318757) `VM_ThreadDump >> asserts in interleaved ObjectMonitor::deflate_monitor calls` >> >> I removed the filtering of *owned ObjectMonitors with dead obj

Re: RFR: 8314029: Add file name parameter to Compiler.perfmap [v4]

2023-11-27 Thread Yi-Fan Tsai
> `jcmd Compiler.perfmap` uses the hard-coded file name for a perf map: > `/tmp/perf-%d.map`. This change adds an optional argument for specifying a > file name. > > `jcmd PID help Compiler.perfmap` shows the following usage. > > > Compiler.perfmap > Write map file for Linux perf tool. > > Im

Re: RFR: 8319703: Serial: Remove generationSpec

2023-11-27 Thread Albert Mingkun Yang
On Wed, 8 Nov 2023 10:51:19 GMT, Albert Mingkun Yang wrote: > Simple cleanup of removing an unnecessary indirection. The real change is > only 11 LOC, using the global variables directly for young/old gen. Thanks for the review. - PR Comment: https://git.openjdk.org/jdk/pull/16554

Integrated: 8319703: Serial: Remove generationSpec

2023-11-27 Thread Albert Mingkun Yang
On Wed, 8 Nov 2023 10:51:19 GMT, Albert Mingkun Yang wrote: > Simple cleanup of removing an unnecessary indirection. The real change is > only 11 LOC, using the global variables directly for young/old gen. This pull request has now been integrated. Changeset: f9e9131e Author:Albert Mingkun

Re: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite)

2023-11-27 Thread Kevin Walls
On Mon, 27 Nov 2023 15:10:52 GMT, Daniel Fuchs wrote: >> Have you considered naming it "socketConnectTimeout" instead? Or possibly >> "tcpConnectTimeout"? > > If you named it "tcpConnectTimeout" then you could name the (future) property > for [JDK-8320703](https://bugs.openjdk.org/browse/JDK-83

Re: RFR: JDK-8320005 : Native library suffix impact on hotspot code in AIX [v2]

2023-11-27 Thread suchismith1993
On Mon, 27 Nov 2023 11:36:02 GMT, suchismith1993 wrote: > > > i would have to repeat the line 1132 and 1139 in os_aix.cpp again , if > > > the condition fails for .so files, because i have to reload it again and > > > check if the .a exists. In the shared code i had repeat less number of > > >

Re: RFR: JDK-8315706: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java real fix for failure on AIX [v5]

2023-11-27 Thread Joachim Kern
On Fri, 15 Sep 2023 07:22:32 GMT, Joachim Kern wrote: >> After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) , >> the following test started to fail on AIX : >> com/sun/tools/attach/warnings/DynamicLoadWarningTest.java; >> The problem was described in >> [JDK-8309549](https

Re: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite)

2023-11-27 Thread Daniel Fuchs
On Mon, 27 Nov 2023 15:00:54 GMT, Daniel Fuchs wrote: >> On the Property name: there is an existing System Property >> "sun.rmi.transport.connectionTimeout" which is a 15-second idle timeout. >> Having a "connectionTimeout" and this new one as "connectTimeout" could be >> confusing, even in

Re: RFR: JDK-8315706: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java real fix for failure on AIX [v5]

2023-11-27 Thread Thomas Stuefe
On Mon, 27 Nov 2023 13:23:42 GMT, Thomas Stuefe wrote: >> Joachim Kern has updated the pull request incrementally with one additional >> commit since the last revision: >> >> adopt types > > This now causes problems with > > https://github.com/openjdk/jdk/pull/16604#issuecomment-1827661214

Re: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite)

2023-11-27 Thread Daniel Fuchs
On Mon, 27 Nov 2023 14:35:07 GMT, Kevin Walls wrote: >> wrt to the property name initialConnectTimeout might infer that it is an >> initial value which can be subsequentually modified, but that is not >> possible. As such, would sun.rmi.transport.tcp.connectTimeout be more >> appropriate -- dr

Re: RFR: 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite)

2023-11-27 Thread Kevin Walls
On Fri, 24 Nov 2023 16:28:38 GMT, Mark Sheppard wrote: >> Thanks, yes so JMX SSL clients are without socket connect timeout, good to >> have that documented. I logged a parallel RFE for >> SslRMIClientSocketFactory, which should wait for now as it seems wrong to go >> changing that right now

Re: RFR: JDK-8315706: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java real fix for failure on AIX [v5]

2023-11-27 Thread Joachim Kern
On Mon, 27 Nov 2023 13:23:42 GMT, Thomas Stuefe wrote: >> Joachim Kern has updated the pull request incrementally with one additional >> commit since the last revision: >> >> adopt types > > This now causes problems with > > https://github.com/openjdk/jdk/pull/16604#issuecomment-1827661214

Re: RFR: 8319703: Serial: Remove generationSpec

2023-11-27 Thread Thomas Schatzl
On Wed, 8 Nov 2023 10:51:19 GMT, Albert Mingkun Yang wrote: > Simple cleanup of removing an unnecessary indirection. The real change is > only 11 LOC, using the global variables directly for young/old gen. Marked as reviewed by tschatzl (Reviewer). - PR Review: https://git.openjdk

Re: RFR: JDK-8315706: com/sun/tools/attach/warnings/DynamicLoadWarningTest.java real fix for failure on AIX [v5]

2023-11-27 Thread Thomas Stuefe
On Fri, 15 Sep 2023 07:22:32 GMT, Joachim Kern wrote: >> After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) , >> the following test started to fail on AIX : >> com/sun/tools/attach/warnings/DynamicLoadWarningTest.java; >> The problem was described in >> [JDK-8309549](https

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v7]

2023-11-27 Thread Stefan Karlsson
> In the rewrites made for: > [JDK-8318757](https://bugs.openjdk.org/browse/JDK-8318757) `VM_ThreadDump > asserts in interleaved ObjectMonitor::deflate_monitor calls` > > I removed the filtering of *owned ObjectMonitors with dead objects*. The > reasoning was that you should never have an owned

Re: RFR: 8320532: Remove Thread/ThreadGroup suspend/resume

2023-11-27 Thread Serguei Spitsyn
On Thu, 23 Nov 2023 09:18:44 GMT, Alan Bateman wrote: > The deadlock prone Thread/ThreadGroup suspend/resume were deprecated since > JDK 1.2, deprecated for removal in Java 14, and re-specified/degraded to > throw UnsupportedOperationException unconditionally in Java 19/20. Early in > Java 23

Re: RFR: 8315149: Add hsperf counters for CPU time of internal GC threads [v47]

2023-11-27 Thread Stefan Johansson
On Wed, 22 Nov 2023 23:08:36 GMT, Jonathan Joo wrote: >> 8315149: Add hsperf counters for CPU time of internal GC threads > > Jonathan Joo has updated the pull request incrementally with one additional > commit since the last revision: > > Cleanup and address comments My additional testing f

Re: RFR: JDK-8320005 : Native library suffix impact on hotspot code in AIX [v2]

2023-11-27 Thread suchismith1993
On Fri, 24 Nov 2023 14:04:07 GMT, Thomas Stuefe wrote: > > > i would have to repeat the line 1132 and 1139 in os_aix.cpp again , if > > > the condition fails for .so files, because i have to reload it again and > > > check if the .a exists. In the shared code i had repeat less number of > > >

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v6]

2023-11-27 Thread Stefan Karlsson
> In the rewrites made for: > [JDK-8318757](https://bugs.openjdk.org/browse/JDK-8318757) `VM_ThreadDump > asserts in interleaved ObjectMonitor::deflate_monitor calls` > > I removed the filtering of *owned ObjectMonitors with dead objects*. The > reasoning was that you should never have an owned

Re: RFR: JDK-8320005 : Native library suffix impact on hotspot code in AIX [v2]

2023-11-27 Thread suchismith1993
On Fri, 24 Nov 2023 14:04:07 GMT, Thomas Stuefe wrote: > > > i would have to repeat the line 1132 and 1139 in os_aix.cpp again , if > > > the condition fails for .so files, because i have to reload it again and > > > check if the .a exists. In the shared code i had repeat less number of > > >

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v5]

2023-11-27 Thread Stefan Karlsson
On Mon, 27 Nov 2023 02:17:27 GMT, David Holmes wrote: >> Stefan Karlsson has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Split test and use othervm > > test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.j

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v5]

2023-11-27 Thread Stefan Karlsson
On Mon, 27 Nov 2023 02:14:05 GMT, David Holmes wrote: >> Stefan Karlsson has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Split test and use othervm > > test/hotspot/jtreg/runtime/Monitor/libMonitorWithDeadObjectTest.c line 130: > >> 128

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v5]

2023-11-27 Thread Stefan Karlsson
On Mon, 27 Nov 2023 02:09:56 GMT, David Holmes wrote: >> Stefan Karlsson has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Split test and use othervm > > test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.j

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v5]

2023-11-27 Thread Stefan Karlsson
On Mon, 27 Nov 2023 02:03:30 GMT, David Holmes wrote: >> Stefan Karlsson has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Split test and use othervm > > test/hotspot/jtreg/runtime/Monitor/MonitorWithDeadObjectTest.java line 86: > >> 84:

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v5]

2023-11-27 Thread Stefan Karlsson
On Mon, 27 Nov 2023 01:56:01 GMT, David Holmes wrote: >> Stefan Karlsson has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Split test and use othervm > > test/hotspot/jtreg/runtime/Monitor/libMonitorWithDeadObjectTest.c line 161: > >> 159

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v5]

2023-11-27 Thread Stefan Karlsson
On Mon, 27 Nov 2023 01:52:29 GMT, David Holmes wrote: >> Stefan Karlsson has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Split test and use othervm > > test/hotspot/jtreg/runtime/Monitor/libMonitorWithDeadObjectTest.c line 47: > >> 45:

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v5]

2023-11-27 Thread Stefan Karlsson
On Mon, 27 Nov 2023 02:02:08 GMT, David Holmes wrote: >> test/hotspot/jtreg/runtime/Monitor/MonitorWithDeadObjectTest.java line 75: >> >>> 73: private static void testDetachThread() { >>> 74: // Create an ObjectMonitor with a dead object from an >>> 75: // attached thread. >>

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v5]

2023-11-27 Thread Stefan Karlsson
On Mon, 27 Nov 2023 01:43:07 GMT, David Holmes wrote: >> Stefan Karlsson has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Split test and use othervm > > test/hotspot/jtreg/runtime/Monitor/MonitorWithDeadObjectTest.java line 26: > >> 24:

Re: RFR: 8313816: Accessing jmethodID might lead to spurious crashes [v10]

2023-11-27 Thread Jaroslav Bachorik
On Mon, 20 Nov 2023 22:09:47 GMT, Coleen Phillimore wrote: >> Jaroslav Bachorik has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Remove unnecessary assert > > Good analysis for a very subtle bug. I have a couple of comments, and maybe >

Re: RFR: 8313816: Accessing jmethodID might lead to spurious crashes [v8]

2023-11-27 Thread Jaroslav Bachorik
On Sat, 25 Nov 2023 02:20:18 GMT, David Holmes wrote: >> This has gotten a lot more complicated. All I was suggesting was if this: >> >> if (with_method_holders) { >> method->clear_jmethod_id(); >> } >> >> could be changed to >> >> if (method->method_holder() == nullptr) { >> method->clea

Re: RFR: 8313816: Accessing jmethodID might lead to spurious crashes [v10]

2023-11-27 Thread Jaroslav Bachorik
> Please, review this fix for a corner case handling of `jmethodID` values. > > The issue is related to the interplay between `jmethodID` values and method > redefinitions. Each `jmethodID` value is effectively a pointer to a `Method` > instance. Once that method gets redefined, the `jmethodID`