From kevinw at openjdk.org Tue May 2 18:05:11 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 2 May 2023 18:05:11 GMT Subject: jmx-dev RFR: 8307244: Remove redundant class RMIIIOPServerImpl Message-ID: <69iXE2clpZugZG7uCzAmZfSzAaRBTNJnnPpLnVgWb2M=.dcbc8323-489d-4a75-85b1-a7f0b5fea7ba@github.com> Removal of class, looks like it was missed in the JDK9 removal of RMIIIOP. This class is not referenced by other classes or tests. ------------- Commit messages: - 8307244: Remove redundant class RMIIIOPServerImpl Changes: https://git.openjdk.org/jdk/pull/13758/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13758&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307244 Stats: 102 lines in 2 files changed: 0 ins; 101 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13758.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13758/head:pull/13758 PR: https://git.openjdk.org/jdk/pull/13758 From sspitsyn at openjdk.org Tue May 2 18:46:15 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 2 May 2023 18:46:15 GMT Subject: jmx-dev RFR: 8307244: Remove redundant class RMIIIOPServerImpl In-Reply-To: <69iXE2clpZugZG7uCzAmZfSzAaRBTNJnnPpLnVgWb2M=.dcbc8323-489d-4a75-85b1-a7f0b5fea7ba@github.com> References: <69iXE2clpZugZG7uCzAmZfSzAaRBTNJnnPpLnVgWb2M=.dcbc8323-489d-4a75-85b1-a7f0b5fea7ba@github.com> Message-ID: On Tue, 2 May 2023 17:57:14 GMT, Kevin Walls wrote: > Removal of class, looks like it was missed in the JDK9 removal of RMIIIOP. > This class is not referenced by other classes or tests. As I see, this transport was deprecated for some time. But it is not clear in what release. The fix looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13758#pullrequestreview-1409689868 From alanb at openjdk.org Tue May 2 19:37:16 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 2 May 2023 19:37:16 GMT Subject: jmx-dev RFR: 8307244: Remove redundant class RMIIIOPServerImpl In-Reply-To: References: <69iXE2clpZugZG7uCzAmZfSzAaRBTNJnnPpLnVgWb2M=.dcbc8323-489d-4a75-85b1-a7f0b5fea7ba@github.com> Message-ID: On Tue, 2 May 2023 18:43:26 GMT, Serguei Spitsyn wrote: > As I see, this transport was deprecated for some time. > But it is not clear in what release. There were a couple of steps in this. The JSR-160 specification was updated for Java 8 so that the RMI connector wasn't require to support the IIOP transport. RMI-IIOP was eventually removed in Java 11 (JEP 320). As I recall, RMIIIOPServerImpl was for implementers but was/is part of API so it couldn't be removed. I've added the csr label to the PR as this will need to be tracked as an API change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13758#issuecomment-1532038573 From kevinw at openjdk.org Tue May 2 20:31:16 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 2 May 2023 20:31:16 GMT Subject: jmx-dev RFR: 8307244: Remove redundant class RMIIIOPServerImpl In-Reply-To: <69iXE2clpZugZG7uCzAmZfSzAaRBTNJnnPpLnVgWb2M=.dcbc8323-489d-4a75-85b1-a7f0b5fea7ba@github.com> References: <69iXE2clpZugZG7uCzAmZfSzAaRBTNJnnPpLnVgWb2M=.dcbc8323-489d-4a75-85b1-a7f0b5fea7ba@github.com> Message-ID: <9_nK21tIoGI1CEjQEnQaLzHPWwk4E1EyoIJswT3t2DQ=.dc264e8d-66a7-4580-8f44-29a90bb57485@github.com> On Tue, 2 May 2023 17:57:14 GMT, Kevin Walls wrote: > Removal of class, looks like it was missed in the JDK9 removal of RMIIIOP. > This class is not referenced by other classes or tests. Thanks Alan - I had read JDK-8043937 as being where we remove IIOP completely as a transport for JMX (after earlier changes to not build it by default, JDK-8001048 and JDK-8033366). I see https://bugs.openjdk.org/browse/CCC-8043937 records that we deprecated javax.management.remote.rmi.RMIIIOPServerImpl.java I can add a CSR for removal to make this final and complete as I think was intended. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13758#issuecomment-1532105717 From alanb at openjdk.org Wed May 3 05:38:15 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 May 2023 05:38:15 GMT Subject: jmx-dev RFR: 8307244: Remove redundant class RMIIIOPServerImpl In-Reply-To: <69iXE2clpZugZG7uCzAmZfSzAaRBTNJnnPpLnVgWb2M=.dcbc8323-489d-4a75-85b1-a7f0b5fea7ba@github.com> References: <69iXE2clpZugZG7uCzAmZfSzAaRBTNJnnPpLnVgWb2M=.dcbc8323-489d-4a75-85b1-a7f0b5fea7ba@github.com> Message-ID: On Tue, 2 May 2023 17:57:14 GMT, Kevin Walls wrote: > Removal of class, looks like it was missed in the JDK9 removal of RMIIIOP. > This class is not referenced by other classes or tests. JSR-160 MR3 changed RMIConnector to make the IIOP transport optional. For Java 8 this was JDK-8001048. For Java 9, the IIOP transport was removed via JDK-8043937. It should be okay to remove RMIIIOPServerImpl now. There's an example in the RMIConnector javadoc that uses a service URL and the "iiop" protocol, which I think is okay to leave. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13758#issuecomment-1532472950 From dfuchs at openjdk.org Wed May 3 11:31:14 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 3 May 2023 11:31:14 GMT Subject: jmx-dev RFR: 8307244: Remove redundant class RMIIIOPServerImpl In-Reply-To: <69iXE2clpZugZG7uCzAmZfSzAaRBTNJnnPpLnVgWb2M=.dcbc8323-489d-4a75-85b1-a7f0b5fea7ba@github.com> References: <69iXE2clpZugZG7uCzAmZfSzAaRBTNJnnPpLnVgWb2M=.dcbc8323-489d-4a75-85b1-a7f0b5fea7ba@github.com> Message-ID: On Tue, 2 May 2023 17:57:14 GMT, Kevin Walls wrote: > Removal of class, looks like it was missed in the JDK9 removal of RMIIIOP. > This class is not referenced by other classes or tests. Marked as reviewed by dfuchs (Reviewer). Looks good to me. I probably wouldn't have bothered with removing the example of IIOP JMXServiceURL as arguably functional implementations of that might still exist (as long as they don't extend RMIIIOPServerImpl, which is not a requirement). The constructor of RMIIIOPServerImpl throws UnsupportedOperationException unconditionally, so there can't exist any functional subclasses of that class that could be instantiated on Java versions posterior to Java 9. As such removing that class from the public API sounds reasonable. ------------- PR Review: https://git.openjdk.org/jdk/pull/13758#pullrequestreview-1410697538 PR Comment: https://git.openjdk.org/jdk/pull/13758#issuecomment-1532865857 From alanb at openjdk.org Thu May 4 05:53:20 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 4 May 2023 05:53:20 GMT Subject: jmx-dev RFR: 8307244: Remove redundant class RMIIIOPServerImpl In-Reply-To: <69iXE2clpZugZG7uCzAmZfSzAaRBTNJnnPpLnVgWb2M=.dcbc8323-489d-4a75-85b1-a7f0b5fea7ba@github.com> References: <69iXE2clpZugZG7uCzAmZfSzAaRBTNJnnPpLnVgWb2M=.dcbc8323-489d-4a75-85b1-a7f0b5fea7ba@github.com> Message-ID: On Tue, 2 May 2023 17:57:14 GMT, Kevin Walls wrote: > Removal of class, looks like it was missed in the JDK9 removal of RMIIIOP. > This class is not referenced by other classes or tests. Removing RMIIIOPServerImpl is fine, I think I agree with Daniel on leaving out the change to RMIConnector. It may use "iiop" but it just an example. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13758#pullrequestreview-1412327269 From kevinw at openjdk.org Thu May 4 06:37:15 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 4 May 2023 06:37:15 GMT Subject: jmx-dev RFR: 8307244: Remove redundant class RMIIIOPServerImpl In-Reply-To: <69iXE2clpZugZG7uCzAmZfSzAaRBTNJnnPpLnVgWb2M=.dcbc8323-489d-4a75-85b1-a7f0b5fea7ba@github.com> References: <69iXE2clpZugZG7uCzAmZfSzAaRBTNJnnPpLnVgWb2M=.dcbc8323-489d-4a75-85b1-a7f0b5fea7ba@github.com> Message-ID: <7BBC2BD3YUjkcPpAC1M01iXNX-OoUS1B3I9AOmR1qhc=.8b1c06dd-4a5d-45b2-a269-33365eae6971@github.com> On Tue, 2 May 2023 17:57:14 GMT, Kevin Walls wrote: > Removal of class, looks like it was missed in the JDK9 removal of RMIIIOP. > This class is not referenced by other classes or tests. Thanks for all the comments and reviews. On the RMIConnector example, I had thought it was misleading to use as an example something which used to work, but which no longer works. But this change doesn't affect whether other address syntaxes are recognised. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13758#issuecomment-1534159706 From phh at openjdk.org Thu May 4 20:04:15 2023 From: phh at openjdk.org (Paul Hohensee) Date: Thu, 4 May 2023 20:04:15 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of JVM process allocated bytes Message-ID: Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads. Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead. ------------- Commit messages: - 8304074: [JMX] Add an approximation of JVM process allocated bytes Changes: https://git.openjdk.org/jdk/pull/13814/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304074 Stats: 222 lines in 10 files changed: 173 ins; 16 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/13814.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814 PR: https://git.openjdk.org/jdk/pull/13814 From dholmes at openjdk.org Fri May 5 06:48:19 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 5 May 2023 06:48:19 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of JVM process allocated bytes In-Reply-To: References: Message-ID: On Thu, 4 May 2023 19:54:57 GMT, Paul Hohensee wrote: > Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads. > > Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead. src/hotspot/share/services/management.cpp line 2102: > 2100: JVM_ENTRY(jlong, jmm_GetAllThreadAllocatedMemory(JNIEnv *env)) > 2101: // There is a race between threads that exit during the loop and calling > 2102: // exited_allocated_bytes. If the result is initialized with exited_allocated_bytes, If you want a stable and accurate value did you consider holding the Threads_lock while you iterate the threads? Or do it as a safepoint VMop? src/hotspot/share/services/management.cpp line 2106: > 2104: // the loop gets to it and thus not be counted. If, on the other hand and done > 2105: // here, exited_allocated_bytes is added after the loop, the final result might be > 2106: // "too large" because a thread might be counted twice, once in the loop and agsin typo agsin ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1185748115 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1185746920 From shade at openjdk.org Fri May 5 16:56:24 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 5 May 2023 16:56:24 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM In-Reply-To: References: Message-ID: On Thu, 4 May 2023 19:54:57 GMT, Paul Hohensee wrote: > Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads. > > Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead. Some comments follow. src/hotspot/share/include/jmm.h line 55: > 53: JMM_VERSION_2 = 0x20020000, // JDK 10 > 54: JMM_VERSION_3 = 0x20030000, // JDK 14 > 55: JMM_VERSION_3_0 = 0x20030000, What's `JMM_VERSION_3_0`? src/hotspot/share/services/management.cpp line 2115: > 2113: result += size; > 2114: } > 2115: return result + ThreadService::exited_allocated_bytes();; Double `;;`. src/hotspot/share/services/threadService.hpp line 111: > 109: static jlong exited_allocated_bytes() { return _exited_allocated_bytes; } > 110: static void incr_exited_allocated_bytes(jlong size) { > 111: Atomic::add(&_exited_allocated_bytes, size); `Atomic::add(&_exited_allocated_bytes, size, memory_order_relaxed);`, please. No need for overly-strict memory effects for this counter. src/java.management/share/classes/sun/management/ThreadImpl.java line 535: > 533: private static native long getThreadAllocatedMemory0(long id); > 534: private static native void getThreadAllocatedMemory1(long[] ids, long[] result); > 535: private static native long getThreadAllocatedMemory2(); We can call this one `getAllThreadAllocatedMemory`, which obviates the need for `2` as the suffix. src/jdk.management/share/classes/com/sun/management/ThreadMXBean.java line 159: > 157: * > 158: * @return an approximation of the total memory allocated, in bytes, in > 159: * heap memory for the current thread, I am not sure if typos changes in the public API requires a CSR (albeit trivial one). Maybe skip these updates? test/jdk/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java line 221: > 219: // baseline should be positive > 220: Thread curThread = Thread.currentThread(); > 221: long cumulative_size = mbean.getAllThreadAllocatedBytes(); Java style for variables is camel-case, `cumulativeSize`. test/jdk/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java line 286: > 284: } > 285: > 286: private static long checkResult(Thread curThread, There is another `checkResult` below? Should they be replaced by a single method? test/jdk/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java line 377: > 375: throw new RuntimeException(getName() + > 376: " ThreadAllocatedBytes before = " + size1 + > 377: " > ThreadAllocatedBytes after = " + size2); Is this replaceable with `checkResult(...)`? test/jdk/com/sun/management/ThreadMXBean/ThreadAllocatedMemoryArray.java line 120: > 118: long[] sizes1 = mbean.getThreadAllocatedBytes(ids); > 119: for (int i = 0; i < NUM_THREADS; i++) { > 120: checkResult(threads[i], sizes[i], sizes1[i]); Since we are cleaning up the test anyway, can we / should we rename `sizes` -> `before`, `size1` -> `after`? test/jdk/com/sun/management/ThreadMXBean/ThreadAllocatedMemoryArray.java line 164: > 162: > 163: private static void checkResult(Thread curThread, > 164: long prev_size, long curr_size) { camelCase arguments. ------------- PR Review: https://git.openjdk.org/jdk/pull/13814#pullrequestreview-1415057714 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186299709 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186309343 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186260976 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186261881 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186263383 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186265606 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186277116 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186275693 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186275048 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186275416 From shade at openjdk.org Fri May 5 16:56:26 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 5 May 2023 16:56:26 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM In-Reply-To: References: Message-ID: On Fri, 5 May 2023 06:45:10 GMT, David Holmes wrote: >> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads. >> >> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead. > > src/hotspot/share/services/management.cpp line 2102: > >> 2100: JVM_ENTRY(jlong, jmm_GetAllThreadAllocatedMemory(JNIEnv *env)) >> 2101: // There is a race between threads that exit during the loop and calling >> 2102: // exited_allocated_bytes. If the result is initialized with exited_allocated_bytes, > > If you want a stable and accurate value did you consider holding the Threads_lock while you iterate the threads? Or do it as a safepoint VMop? I agree we should strive to get the value as accurate as possible. I think for operational use at scale, we need to avoid doing safepoints. Holding a `ThreadLock` might also penalize other code that (ab)uses threading (we frequently see thousands of threads coming and going, don't ask). But I have a fundamental question here: since SMR/TLH gives us a snapshot of currently live threads, and it also protects us from seeing an exiting thread in bad state (ultimately, a `delete`-d one), why can't we just trust its `cooked_allocated_bytes`, and avoid adding allocated bytes on exit path? If we cannot trust that, can we make it trustable while thread is protected by SMR/TLH? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186299142 From simonis at openjdk.org Fri May 5 17:16:16 2023 From: simonis at openjdk.org (Volker Simonis) Date: Fri, 5 May 2023 17:16:16 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM In-Reply-To: References: Message-ID: <-G4uTOCHpkgf1qjgTS7NYtbUIbWVTOdOgrhN5XU9kT0=.bce10c8b-f69c-4f10-80ef-8573017fa15f@github.com> On Thu, 4 May 2023 19:54:57 GMT, Paul Hohensee wrote: > Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads. > > Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead. Looks good in general. Please find my comments inline. src/hotspot/share/include/jmm.h line 55: > 53: JMM_VERSION_2 = 0x20020000, // JDK 10 > 54: JMM_VERSION_3 = 0x20030000, // JDK 14 > 55: JMM_VERSION_3_0 = 0x20030000, Why do we need `JMM_VERSION_3_0`? We haven't defined `JMM_VERSION_2_0` either. src/hotspot/share/include/jmm.h line 321: > 319: jstring flag_name, > 320: jvalue new_value); > 321: jlong (JNICALL *GetAllThreadAllocatedMemory) I'm not sure here, but I think there's no need to "overwrite" a *reserved* slot if you add this functionality to a new major release as you do. You also haven't done it when you've added `GetOneThreadAllocatedMemory()` with [JDK-8231209](https://bugs.openjdk.org/browse/JDK-8231209). I think we should keep these *reserved* slots for the case when we eventually have to downport new functionality from a later release. src/hotspot/share/services/management.cpp line 2282: > 2280: jmm_FindDeadlockedThreads, > 2281: jmm_SetVMGlobal, > 2282: jmm_GetAllThreadAllocatedMemory, See comment on overwriting the `reserved6` slot above. ------------- PR Review: https://git.openjdk.org/jdk/pull/13814#pullrequestreview-1414984240 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186213343 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186224124 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186301611 From simonis at openjdk.org Fri May 5 17:16:19 2023 From: simonis at openjdk.org (Volker Simonis) Date: Fri, 5 May 2023 17:16:19 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM In-Reply-To: References: Message-ID: On Fri, 5 May 2023 06:45:10 GMT, David Holmes wrote: >> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads. >> >> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead. > > src/hotspot/share/services/management.cpp line 2102: > >> 2100: JVM_ENTRY(jlong, jmm_GetAllThreadAllocatedMemory(JNIEnv *env)) >> 2101: // There is a race between threads that exit during the loop and calling >> 2102: // exited_allocated_bytes. If the result is initialized with exited_allocated_bytes, > > If you want a stable and accurate value did you consider holding the Threads_lock while you iterate the threads? Or do it as a safepoint VMop? The API specification clearly states that this method returns "*an approximation of the total amount of memory allocated in heap*" so in my opinion it is OK to keep it simple here and don't start messing with looks and safepoints. But can't we make this a little more accurate by only adding a threads allocated bytes if it is not `thread->is_terminated()`? Wouldn't that prevent double counting most of the time? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186246289 From phh at openjdk.org Fri May 5 17:32:26 2023 From: phh at openjdk.org (Paul Hohensee) Date: Fri, 5 May 2023 17:32:26 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM In-Reply-To: References: Message-ID: On Fri, 5 May 2023 16:42:29 GMT, Aleksey Shipilev wrote: >> The API specification clearly states that this method returns "*an approximation of the total amount of memory allocated in heap*" so in my opinion it is OK to keep it simple here and don't start messing with looks and safepoints. >> >> But can't we make this a little more accurate by only adding a threads allocated bytes if it is not `thread->is_terminated()`? Wouldn't that prevent double counting most of the time? > > I agree we should strive to get the value as accurate as possible. I think for operational use at scale, we need to avoid doing safepoints. Holding a `ThreadLock` might also penalize other code that (ab)uses threading (we frequently see thousands of threads coming and going, don't ask). > > But I have a fundamental question here: since SMR/TLH gives us a snapshot of currently live threads, and it also protects us from seeing an exiting thread in bad state (ultimately, a `delete`-d one), why can't we just trust its `cooked_allocated_bytes`, and avoid adding allocated bytes on exit path? If we cannot trust that, can we make it trustable while thread is protected by SMR/TLH? I thought about doing those, but both would slow down the app/JVM and very likely introduce p99.9/p100 latency outliers that we'd rather not see just because we're sampling. Also, 1. The existing thread allocated bytes implementation isn't particularly accurate either, in the sense that reality quickly gets away from the method return values. That was a conscious decision to go with speed and efficiency over stability/accuracy, so I went the same way for this implementation. 2. Cloud services sample at fairly long intervals in order to avoid overhead: 1 minute is common and 5 minutes not unheard of. Stability/accuracy within short time frames is unneeded with such long sampling intervals. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186341500 From phh at openjdk.org Fri May 5 20:46:12 2023 From: phh at openjdk.org (Paul Hohensee) Date: Fri, 5 May 2023 20:46:12 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v2] In-Reply-To: References: Message-ID: > Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads. > > Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead. Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13814/files - new: https://git.openjdk.org/jdk/pull/13814/files/d78ec8fa..460c00e4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=00-01 Stats: 55 lines in 8 files changed: 6 ins; 14 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/13814.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814 PR: https://git.openjdk.org/jdk/pull/13814 From phh at openjdk.org Fri May 5 20:56:41 2023 From: phh at openjdk.org (Paul Hohensee) Date: Fri, 5 May 2023 20:56:41 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v3] In-Reply-To: References: Message-ID: > Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads. > > Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead. Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13814/files - new: https://git.openjdk.org/jdk/pull/13814/files/460c00e4..1001b667 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13814.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814 PR: https://git.openjdk.org/jdk/pull/13814 From phh at openjdk.org Fri May 5 20:56:41 2023 From: phh at openjdk.org (Paul Hohensee) Date: Fri, 5 May 2023 20:56:41 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v3] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 16:16:37 GMT, Aleksey Shipilev wrote: >> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision: >> >> 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM > > test/jdk/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java line 286: > >> 284: } >> 285: >> 286: private static long checkResult(Thread curThread, > > There is another `checkResult` below? Should they be replaced by a single method? No, there's only one checkResult method. I changed the result type from void to long. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186491906 From phh at openjdk.org Fri May 5 21:04:32 2023 From: phh at openjdk.org (Paul Hohensee) Date: Fri, 5 May 2023 21:04:32 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v4] In-Reply-To: References: Message-ID: > Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads. > > Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead. Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13814/files - new: https://git.openjdk.org/jdk/pull/13814/files/1001b667..2e2adc0b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=02-03 Stats: 6 lines in 1 file changed: 3 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13814.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814 PR: https://git.openjdk.org/jdk/pull/13814 From phh at openjdk.org Fri May 5 21:04:49 2023 From: phh at openjdk.org (Paul Hohensee) Date: Fri, 5 May 2023 21:04:49 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v4] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 06:43:20 GMT, David Holmes wrote: >> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision: >> >> 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM > > src/hotspot/share/services/management.cpp line 2106: > >> 2104: // the loop gets to it and thus not be counted. If, on the other hand and done >> 2105: // here, exited_allocated_bytes is added after the loop, the final result might be >> 2106: // "too large" because a thread might be counted twice, once in the loop and agsin > > typo agsin Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186498560 From phh at openjdk.org Fri May 5 21:24:15 2023 From: phh at openjdk.org (Paul Hohensee) Date: Fri, 5 May 2023 21:24:15 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v4] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 17:29:30 GMT, Paul Hohensee wrote: >> I agree we should strive to get the value as accurate as possible. I think for operational use at scale, we need to avoid doing safepoints. Holding a `ThreadLock` might also penalize other code that (ab)uses threading (we frequently see thousands of threads coming and going, don't ask). >> >> But I have a fundamental question here: since SMR/TLH gives us a snapshot of currently live threads, and it also protects us from seeing an exiting thread in bad state (ultimately, a `delete`-d one), why can't we just trust its `cooked_allocated_bytes`, and avoid adding allocated bytes on exit path? If we cannot trust that, can we make it trustable while thread is protected by SMR/TLH? > > I thought about doing those, but both would slow down the app/JVM and very likely introduce p99.9/p100 latency outliers that we'd rather not see just because we're sampling. Also, > > 1. The existing thread allocated bytes implementation isn't particularly accurate either, in the sense that reality quickly gets away from the method return values. That was a conscious decision to go with speed and efficiency over stability/accuracy, so I went the same way for this implementation. > 2. Cloud services sample at fairly long intervals in order to avoid overhead: 1 minute is common and 5 minutes not unheard of. Stability/accuracy within short time frames is unneeded with such long sampling intervals. Afaiu, SMR/TLH keeps a terminated thread's TLS accessible, but doesn't stop the termination process. If we initialize result with exited_allocated_bytes, the "too small" possibility is still there. We still have a window between that initialization and the creation of the threads iterator where threads may terminate and thus not be included in the iteration. And new threads may become active during the iteration and not be included. As Aleksey observes, an advantage is that threads that terminate during the iteration will be counted only once and we don't have to check for terminated threads. If we stick with adding exited_allocated_bytes to result after the iteration, Volker is correct that we shouldn't include terminated threads in the sum because their allocated bytes values will have been added to exited_allocated_bytes. We have the same undercount possibility that initializing result with exited_allocated_bytes has, so this (fixed) approach can result in "too small" also, but "too large" goes away. Looks like both approaches are equivalent, so let's go with initializing result with exited_allocated_bytes because it avoids a comparison in the loop. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186508768 From phh at openjdk.org Fri May 5 21:38:47 2023 From: phh at openjdk.org (Paul Hohensee) Date: Fri, 5 May 2023 21:38:47 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v5] In-Reply-To: References: Message-ID: > Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads. > > Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead. Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13814/files - new: https://git.openjdk.org/jdk/pull/13814/files/2e2adc0b..7b922263 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=03-04 Stats: 11 lines in 1 file changed: 0 ins; 4 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/13814.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814 PR: https://git.openjdk.org/jdk/pull/13814 From phh at openjdk.org Fri May 5 21:38:48 2023 From: phh at openjdk.org (Paul Hohensee) Date: Fri, 5 May 2023 21:38:48 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v5] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 16:43:10 GMT, Aleksey Shipilev wrote: >> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision: >> >> 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM > > src/hotspot/share/include/jmm.h line 55: > >> 53: JMM_VERSION_2 = 0x20020000, // JDK 10 >> 54: JMM_VERSION_3 = 0x20030000, // JDK 14 >> 55: JMM_VERSION_3_0 = 0x20030000, > > What's `JMM_VERSION_3_0`? Removed. > src/hotspot/share/services/management.cpp line 2115: > >> 2113: result += size; >> 2114: } >> 2115: return result + ThreadService::exited_allocated_bytes();; > > Double `;;`. Fixed. > src/hotspot/share/services/threadService.hpp line 111: > >> 109: static jlong exited_allocated_bytes() { return _exited_allocated_bytes; } >> 110: static void incr_exited_allocated_bytes(jlong size) { >> 111: Atomic::add(&_exited_allocated_bytes, size); > > `Atomic::add(&_exited_allocated_bytes, size, memory_order_relaxed);`, please. No need for overly-strict memory effects for this counter. Fixed. > src/java.management/share/classes/sun/management/ThreadImpl.java line 535: > >> 533: private static native long getThreadAllocatedMemory0(long id); >> 534: private static native void getThreadAllocatedMemory1(long[] ids, long[] result); >> 535: private static native long getThreadAllocatedMemory2(); > > We can call this one `getAllThreadAllocatedMemory`, which obviates the need for `2` as the suffix. Fixed. > src/jdk.management/share/classes/com/sun/management/ThreadMXBean.java line 159: > >> 157: * >> 158: * @return an approximation of the total memory allocated, in bytes, in >> 159: * heap memory for the current thread, > > I am not sure if typos changes in the public API requires a CSR (albeit trivial one). Maybe skip these updates? Fixed. > test/jdk/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java line 221: > >> 219: // baseline should be positive >> 220: Thread curThread = Thread.currentThread(); >> 221: long cumulative_size = mbean.getAllThreadAllocatedBytes(); > > Java style for variables is camel-case, `cumulativeSize`. Fixed. > test/jdk/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java line 377: > >> 375: throw new RuntimeException(getName() + >> 376: " ThreadAllocatedBytes before = " + size1 + >> 377: " > ThreadAllocatedBytes after = " + size2); > > Is this replaceable with `checkResult(...)`? Yes. Done. > test/jdk/com/sun/management/ThreadMXBean/ThreadAllocatedMemoryArray.java line 120: > >> 118: long[] sizes1 = mbean.getThreadAllocatedBytes(ids); >> 119: for (int i = 0; i < NUM_THREADS; i++) { >> 120: checkResult(threads[i], sizes[i], sizes1[i]); > > Since we are cleaning up the test anyway, can we / should we rename `sizes` -> `before`, `size1` -> `after`? I kept "sizes" since it's use before isn't really "before". I renamed sizes1 to afterSizes. > test/jdk/com/sun/management/ThreadMXBean/ThreadAllocatedMemoryArray.java line 164: > >> 162: >> 163: private static void checkResult(Thread curThread, >> 164: long prev_size, long curr_size) { > > camelCase arguments. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186514932 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186515039 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186513534 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186513639 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186513735 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186513794 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186514728 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186514463 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186514571 From phh at openjdk.org Fri May 5 21:38:48 2023 From: phh at openjdk.org (Paul Hohensee) Date: Fri, 5 May 2023 21:38:48 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v5] In-Reply-To: <-G4uTOCHpkgf1qjgTS7NYtbUIbWVTOdOgrhN5XU9kT0=.bce10c8b-f69c-4f10-80ef-8573017fa15f@github.com> References: <-G4uTOCHpkgf1qjgTS7NYtbUIbWVTOdOgrhN5XU9kT0=.bce10c8b-f69c-4f10-80ef-8573017fa15f@github.com> Message-ID: On Fri, 5 May 2023 15:11:26 GMT, Volker Simonis wrote: >> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision: >> >> 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM > > src/hotspot/share/include/jmm.h line 55: > >> 53: JMM_VERSION_2 = 0x20020000, // JDK 10 >> 54: JMM_VERSION_3 = 0x20030000, // JDK 14 >> 55: JMM_VERSION_3_0 = 0x20030000, > > Why do we need `JMM_VERSION_3_0`? We haven't defined `JMM_VERSION_2_0` either. Removed. > src/hotspot/share/include/jmm.h line 321: > >> 319: jstring flag_name, >> 320: jvalue new_value); >> 321: jlong (JNICALL *GetAllThreadAllocatedMemory) > > I'm not sure here, but I think there's no need to "overwrite" a *reserved* slot if you add this functionality to a new major release as you do. You also haven't done it when you've added `GetOneThreadAllocatedMemory()` with [JDK-8231209](https://bugs.openjdk.org/browse/JDK-8231209). > > I think we should keep these *reserved* slots for the case when we eventually have to downport new functionality from a later release. Done. > src/hotspot/share/services/management.cpp line 2282: > >> 2280: jmm_FindDeadlockedThreads, >> 2281: jmm_SetVMGlobal, >> 2282: jmm_GetAllThreadAllocatedMemory, > > See comment on overwriting the `reserved6` slot above. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186515133 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186515257 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186515422 From dholmes at openjdk.org Mon May 8 02:10:23 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 8 May 2023 02:10:23 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v5] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 21:21:28 GMT, Paul Hohensee wrote: > Afaiu, SMR/TLH keeps a terminated thread's TLS accessible, but doesn't stop the termination process. Incorrect. A thread cannot complete the termination process if it is contained by a TLH - see ` ThreadsSMRSupport::smr_delete` and the call to `wait_until_not_protected`. But not sure that helps with the zero-else-double accounting problem. Any read of the "total accumulated bytes written to date" value is racing with terminating threads. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186966520 From dholmes at openjdk.org Mon May 8 02:24:26 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 8 May 2023 02:24:26 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v5] In-Reply-To: References: Message-ID: <1-dU7miE3DgmLHf1LWgwDrqppK2l2Y5OwYkms3QMCIs=.398dcfe2-12b6-42e7-ac44-1cec2f729432@github.com> On Fri, 5 May 2023 21:38:47 GMT, Paul Hohensee wrote: >> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads. >> >> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead. > > Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision: > > 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM src/hotspot/share/services/management.cpp line 2107: > 2105: // when result is initialized. > 2106: jlong result = ThreadService::exited_allocated_bytes(); > 2107: for (JavaThreadIteratorWithHandle jtiwh; JavaThread *thread = jtiwh.next();) { If you call `exited_allocated_bytes` whilst you have an active `ThreadsListHandle` then you at least ensure you don't miss accounting for threads that are just about to terminate. src/hotspot/share/services/threadService.cpp line 173: > 171: // was not called, e.g., JavaThread::cleanup_failed_attach_current_thread(). > 172: decrement_thread_counts(thread, daemon); > 173: ThreadService::incr_exited_allocated_bytes(thread->cooked_allocated_bytes()); By doing this here you increase the likelihood of double-accounting for this thread. If you do this after the thread is no longer on any threads-list you may miss its contribution entirely, but you won't double-count it. src/jdk.management/share/classes/com/sun/management/ThreadMXBean.java line 111: > 109: * Returns an approximation of the total amount of memory, in bytes, > 110: * allocated in heap memory since the Java virtual machine was launched, > 111: * including the amount allocated by terminated threads. This "including ..." part seems redundant - it is the value allocated since JVM launch. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186967565 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186968365 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1186968949 From simonis at openjdk.org Mon May 8 14:06:28 2023 From: simonis at openjdk.org (Volker Simonis) Date: Mon, 8 May 2023 14:06:28 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v5] In-Reply-To: <1-dU7miE3DgmLHf1LWgwDrqppK2l2Y5OwYkms3QMCIs=.398dcfe2-12b6-42e7-ac44-1cec2f729432@github.com> References: <1-dU7miE3DgmLHf1LWgwDrqppK2l2Y5OwYkms3QMCIs=.398dcfe2-12b6-42e7-ac44-1cec2f729432@github.com> Message-ID: On Mon, 8 May 2023 02:10:48 GMT, David Holmes wrote: >> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision: >> >> 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM > > src/hotspot/share/services/management.cpp line 2107: > >> 2105: // when result is initialized. >> 2106: jlong result = ThreadService::exited_allocated_bytes(); >> 2107: for (JavaThreadIteratorWithHandle jtiwh; JavaThread *thread = jtiwh.next();) { > > If you call `exited_allocated_bytes` whilst you have an active `ThreadsListHandle` then you at least ensure you don't miss accounting for threads that are just about to terminate. Do you mean something like: JavaThreadIteratorWithHandle jtiwh; jlong result = ThreadService::exited_allocated_bytes(); while (JavaThread *thread = jtiwh.next()) { ... That would be fine for me. Otherwise I agree with the current compromise between accuracy and speed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1187488276 From dcubed at openjdk.org Mon May 8 16:44:36 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 8 May 2023 16:44:36 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v5] In-Reply-To: <1-dU7miE3DgmLHf1LWgwDrqppK2l2Y5OwYkms3QMCIs=.398dcfe2-12b6-42e7-ac44-1cec2f729432@github.com> References: <1-dU7miE3DgmLHf1LWgwDrqppK2l2Y5OwYkms3QMCIs=.398dcfe2-12b6-42e7-ac44-1cec2f729432@github.com> Message-ID: On Mon, 8 May 2023 02:13:14 GMT, David Holmes wrote: >> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision: >> >> 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM > > src/hotspot/share/services/threadService.cpp line 173: > >> 171: // was not called, e.g., JavaThread::cleanup_failed_attach_current_thread(). >> 172: decrement_thread_counts(thread, daemon); >> 173: ThreadService::incr_exited_allocated_bytes(thread->cooked_allocated_bytes()); > > By doing this here you increase the likelihood of double-accounting for this thread. If you do this after the thread is no longer on any threads-list you may miss its contribution entirely, but you won't double-count it. If the `thread` is no longer on any ThreadsList, then it is not safe to access `thread`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1187655129 From phh at openjdk.org Mon May 8 20:35:30 2023 From: phh at openjdk.org (Paul Hohensee) Date: Mon, 8 May 2023 20:35:30 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v6] In-Reply-To: References: Message-ID: > Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads. > > Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead. Paul Hohensee has updated the pull request incrementally with two additional commits since the last revision: - 8304074: Implement 32-bit linux Atomic::add() - 8304074: CSR comment updates ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13814/files - new: https://git.openjdk.org/jdk/pull/13814/files/7b922263..4161677c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=04-05 Stats: 61 lines in 8 files changed: 41 ins; 3 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/13814.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814 PR: https://git.openjdk.org/jdk/pull/13814 From phh at openjdk.org Mon May 8 20:45:02 2023 From: phh at openjdk.org (Paul Hohensee) Date: Mon, 8 May 2023 20:45:02 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v7] In-Reply-To: References: Message-ID: > Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads. > > Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead. Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision: CSR comment updates ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13814/files - new: https://git.openjdk.org/jdk/pull/13814/files/4161677c..d9039f3f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=05-06 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13814.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814 PR: https://git.openjdk.org/jdk/pull/13814 From phh at openjdk.org Mon May 8 20:58:32 2023 From: phh at openjdk.org (Paul Hohensee) Date: Mon, 8 May 2023 20:58:32 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v8] In-Reply-To: References: Message-ID: > Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads. > > Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead. Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision: CSR comment updates ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13814/files - new: https://git.openjdk.org/jdk/pull/13814/files/d9039f3f..fcabf083 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=06-07 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13814.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814 PR: https://git.openjdk.org/jdk/pull/13814 From phh at openjdk.org Mon May 8 21:17:10 2023 From: phh at openjdk.org (Paul Hohensee) Date: Mon, 8 May 2023 21:17:10 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v9] In-Reply-To: References: Message-ID: <3LO8c4gYYY8iChP6BjYBzz3AKb4cYApE1NXbEMdvfNE=.51d48af4-27fe-4de1-95c3-427ab2468832@github.com> > Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads. > > Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead. Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision: Implement 32-bit linux Atomic::add() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13814/files - new: https://git.openjdk.org/jdk/pull/13814/files/fcabf083..0bf27fed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=07-08 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13814.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814 PR: https://git.openjdk.org/jdk/pull/13814 From phh at openjdk.org Mon May 8 22:37:51 2023 From: phh at openjdk.org (Paul Hohensee) Date: Mon, 8 May 2023 22:37:51 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v10] In-Reply-To: References: Message-ID: <9AzkFbLMSCIN0tQBqVb6HGlhXHdF0T4V4J7OUnfNFps=.7ed59523-e5c2-438b-a0b2-df0ef85c0d4a@github.com> > Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads. > > Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead. Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision: Implement 32-bit linux Atomic::add() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13814/files - new: https://git.openjdk.org/jdk/pull/13814/files/0bf27fed..c592c8a1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=08-09 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13814.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814 PR: https://git.openjdk.org/jdk/pull/13814 From phh at openjdk.org Mon May 8 23:13:05 2023 From: phh at openjdk.org (Paul Hohensee) Date: Mon, 8 May 2023 23:13:05 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v11] In-Reply-To: References: Message-ID: > Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads. > > Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead. Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision: Implement 32-bit linux Atomic::add() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13814/files - new: https://git.openjdk.org/jdk/pull/13814/files/c592c8a1..75630a07 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13814.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814 PR: https://git.openjdk.org/jdk/pull/13814 From dholmes at openjdk.org Tue May 9 01:07:25 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 9 May 2023 01:07:25 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v5] In-Reply-To: References: <1-dU7miE3DgmLHf1LWgwDrqppK2l2Y5OwYkms3QMCIs=.398dcfe2-12b6-42e7-ac44-1cec2f729432@github.com> Message-ID: On Mon, 8 May 2023 14:03:18 GMT, Volker Simonis wrote: >> src/hotspot/share/services/management.cpp line 2107: >> >>> 2105: // when result is initialized. >>> 2106: jlong result = ThreadService::exited_allocated_bytes(); >>> 2107: for (JavaThreadIteratorWithHandle jtiwh; JavaThread *thread = jtiwh.next();) { >> >> If you call `exited_allocated_bytes` whilst you have an active `ThreadsListHandle` then you at least ensure you don't miss accounting for threads that are just about to terminate. > > Do you mean something like: > > JavaThreadIteratorWithHandle jtiwh; > jlong result = ThreadService::exited_allocated_bytes(); > while (JavaThread *thread = jtiwh.next()) { > ... > > That would be fine for me. Otherwise I agree with the current compromise between accuracy and speed. Yes. Though I realize my comment needed to make clear that you need a thread to update the count after it has removed itself from the thread-list, for this to be an improvement. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1188020260 From dholmes at openjdk.org Tue May 9 01:07:27 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 9 May 2023 01:07:27 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v5] In-Reply-To: References: <1-dU7miE3DgmLHf1LWgwDrqppK2l2Y5OwYkms3QMCIs=.398dcfe2-12b6-42e7-ac44-1cec2f729432@github.com> Message-ID: On Mon, 8 May 2023 16:41:13 GMT, Daniel D. Daugherty wrote: >> src/hotspot/share/services/threadService.cpp line 173: >> >>> 171: // was not called, e.g., JavaThread::cleanup_failed_attach_current_thread(). >>> 172: decrement_thread_counts(thread, daemon); >>> 173: ThreadService::incr_exited_allocated_bytes(thread->cooked_allocated_bytes()); >> >> By doing this here you increase the likelihood of double-accounting for this thread. If you do this after the thread is no longer on any threads-list you may miss its contribution entirely, but you won't double-count it. > > If the `thread` is no longer on any ThreadsList, then it is not safe to access `thread`. @dcubed-ojdk This is the current thread acting on itself ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1188019689 From dholmes at openjdk.org Tue May 9 01:15:38 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 9 May 2023 01:15:38 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v11] In-Reply-To: References: Message-ID: On Mon, 8 May 2023 23:13:05 GMT, Paul Hohensee wrote: >> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads. >> >> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead. > > Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision: > > Implement 32-bit linux Atomic::add() src/hotspot/share/runtime/atomic.hpp line 310: > 308: > 309: // Platform-specific implementation of add. Support for sizes of 4 > 310: // and 8 bytes are required. The class must be default constructable, Comment change seems unnecessary. src/hotspot/share/services/management.cpp line 2107: > 2105: // when result is initialized. The iterator is created and initialized > 2106: // before the call to exited_allocated_bytes to ensure we don't miss > 2107: // accounting for threads that are just about to terminate. Sorry this is only accurate if a thread updates `exited_allocated_bytes` after it removes itself from the Threads-list. src/jdk.management/share/classes/com/sun/management/ThreadMXBean.java line 119: > 117: * @implSpec The default implementation throws UnsupportedOperationException > 118: * if the Java virtual machine implementation does not support thread > 119: * memory allocation measuremust, and otherwise acts as though thread Typo: measuremust ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1188021732 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1188023201 PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1188022520 From phh at openjdk.org Tue May 9 01:28:13 2023 From: phh at openjdk.org (Paul Hohensee) Date: Tue, 9 May 2023 01:28:13 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v12] In-Reply-To: References: Message-ID: > Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads. > > Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead. Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision: Implement 32-bit linux Atomic::add() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13814/files - new: https://git.openjdk.org/jdk/pull/13814/files/75630a07..fbe3c114 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=10-11 Stats: 10 lines in 1 file changed: 1 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/13814.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814 PR: https://git.openjdk.org/jdk/pull/13814 From dholmes at openjdk.org Tue May 9 01:28:15 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 9 May 2023 01:28:15 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v11] In-Reply-To: References: Message-ID: <5H2URzZb5RyC9iJVBHjMjddju_av39gTMtw-d_BQPAM=.9add750e-e988-4e25-8351-63b53230f856@github.com> On Mon, 8 May 2023 23:13:05 GMT, Paul Hohensee wrote: >> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads. >> >> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead. > > Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision: > > Implement 32-bit linux Atomic::add() Also note that the current placement of the `incr_exited_allocated_bytes` skips accounting for hidden threads because those ThreadService methods skip hidden threads. You need to do this update as one of the last actions of a terminating/detaching thread. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13814#issuecomment-1539261740 From dholmes at openjdk.org Tue May 9 01:28:17 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 9 May 2023 01:28:17 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v12] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 01:23:23 GMT, Paul Hohensee wrote: >> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads. >> >> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead. > > Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision: > > Implement 32-bit linux Atomic::add() src/hotspot/share/services/threadService.cpp line 224: > 222: > 223: decrement_thread_counts(jt, daemon); > 224: ThreadService::incr_exited_allocated_bytes(jt->cooked_allocated_bytes()); Again this is too soon. This should be deferred until after the thread has removed itself from the threads-list. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1188026675 From phh at openjdk.org Tue May 9 01:43:17 2023 From: phh at openjdk.org (Paul Hohensee) Date: Tue, 9 May 2023 01:43:17 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v11] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 01:08:19 GMT, David Holmes wrote: >> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision: >> >> Implement 32-bit linux Atomic::add() > > src/hotspot/share/runtime/atomic.hpp line 310: > >> 308: >> 309: // Platform-specific implementation of add. Support for sizes of 4 >> 310: // and 8 bytes are required. The class must be default constructable, > > Comment change seems unnecessary. I found that I had to add 64-bit atomic add support on 32-bit platforms (working on it), so I changed the comment to match the similar cmpxchg one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1188034535 From simonis at openjdk.org Tue May 9 14:24:32 2023 From: simonis at openjdk.org (Volker Simonis) Date: Tue, 9 May 2023 14:24:32 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v5] In-Reply-To: References: <1-dU7miE3DgmLHf1LWgwDrqppK2l2Y5OwYkms3QMCIs=.398dcfe2-12b6-42e7-ac44-1cec2f729432@github.com> Message-ID: On Tue, 9 May 2023 01:02:32 GMT, David Holmes wrote: >> If the `thread` is no longer on any ThreadsList, then it is not safe to access `thread`. > > @dcubed-ojdk This is the current thread acting on itself This method (i.e. `ThreadService::remove_thread()`) is called from `Threads::remove()` *after* the thread was removed from the thread list: void Threads::remove(JavaThread* p, bool is_daemon) { ... // Maintain fast thread list ThreadsSMRSupport::remove_thread(p); ... ThreadService::remove_thread(p, is_daemon); But if we reach here from `JavaThread::cleanup_failed_attach_current_thread()` as the comment implies (`JavaThread::cleanup_failed_attach_current_thread()` calls `Threads::remove()` in the case of an attach failure), calling `ThreadService::incr_exited_allocated_bytes()` is probably irrelevant, because a thread which failed to attach can't allocate anyway. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1188681748 From simonis at openjdk.org Tue May 9 14:32:37 2023 From: simonis at openjdk.org (Volker Simonis) Date: Tue, 9 May 2023 14:32:37 GMT Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v12] In-Reply-To: References: Message-ID: On Tue, 9 May 2023 01:21:14 GMT, David Holmes wrote: >> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision: >> >> Implement 32-bit linux Atomic::add() > > src/hotspot/share/services/threadService.cpp line 224: > >> 222: >> 223: decrement_thread_counts(jt, daemon); >> 224: ThreadService::incr_exited_allocated_bytes(jt->cooked_allocated_bytes()); > > Again this is too soon. This should be deferred until after the thread has removed itself from the threads-list. Here I agree. This method (i.e. `ThreadService::current_thread_exiting()`) is called from `JavaThread::exit()` *before* the call to `Threads::remove()`. I think this call here to `ThreadService::incr_exited_allocated_bytes()` could be removed completely in favor of an unconditional call to `ThreadService::incr_exited_allocated_bytes()` in `ThreadService::remove_thread()` (which will be called by `Threads::remove()` *after* it removed the thread from the thread list). See my comment there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1188698968 From kevinw at openjdk.org Wed May 10 08:49:47 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 10 May 2023 08:49:47 GMT Subject: jmx-dev RFR: 8307244: Remove redundant class RMIIIOPServerImpl [v2] In-Reply-To: <69iXE2clpZugZG7uCzAmZfSzAaRBTNJnnPpLnVgWb2M=.dcbc8323-489d-4a75-85b1-a7f0b5fea7ba@github.com> References: <69iXE2clpZugZG7uCzAmZfSzAaRBTNJnnPpLnVgWb2M=.dcbc8323-489d-4a75-85b1-a7f0b5fea7ba@github.com> Message-ID: > Removal of class, looks like it was missed in the JDK9 removal of RMIIIOP. > This class is not referenced by other classes or tests. Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: example update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13758/files - new: https://git.openjdk.org/jdk/pull/13758/files/8dd59435..1fc1eb6e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13758&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13758&range=00-01 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13758.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13758/head:pull/13758 PR: https://git.openjdk.org/jdk/pull/13758 From kevinw at openjdk.org Wed May 10 08:49:47 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 10 May 2023 08:49:47 GMT Subject: jmx-dev RFR: 8307244: Remove redundant class RMIIIOPServerImpl In-Reply-To: <69iXE2clpZugZG7uCzAmZfSzAaRBTNJnnPpLnVgWb2M=.dcbc8323-489d-4a75-85b1-a7f0b5fea7ba@github.com> References: <69iXE2clpZugZG7uCzAmZfSzAaRBTNJnnPpLnVgWb2M=.dcbc8323-489d-4a75-85b1-a7f0b5fea7ba@github.com> Message-ID: On Tue, 2 May 2023 17:57:14 GMT, Kevin Walls wrote: > Removal of class, looks like it was missed in the JDK9 removal of RMIIIOP. > This class is not referenced by other classes or tests. Putting the example back in RMIConnector, but I was keen to remove "iiop" from search results here, so with a generic placeholder for the protocol. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13758#issuecomment-1541594661 From kevinw at openjdk.org Wed May 10 09:13:40 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 10 May 2023 09:13:40 GMT Subject: jmx-dev RFR: 8307244: Remove redundant class RMIIIOPServerImpl [v3] In-Reply-To: <69iXE2clpZugZG7uCzAmZfSzAaRBTNJnnPpLnVgWb2M=.dcbc8323-489d-4a75-85b1-a7f0b5fea7ba@github.com> References: <69iXE2clpZugZG7uCzAmZfSzAaRBTNJnnPpLnVgWb2M=.dcbc8323-489d-4a75-85b1-a7f0b5fea7ba@github.com> Message-ID: > Removal of class, looks like it was missed in the JDK9 removal of RMIIIOP. > This class is not referenced by other classes or tests. Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: example update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13758/files - new: https://git.openjdk.org/jdk/pull/13758/files/1fc1eb6e..49c6c85f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13758&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13758&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13758.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13758/head:pull/13758 PR: https://git.openjdk.org/jdk/pull/13758 From alanb at openjdk.org Wed May 10 09:13:42 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 10 May 2023 09:13:42 GMT Subject: jmx-dev RFR: 8307244: Remove redundant class RMIIIOPServerImpl [v2] In-Reply-To: References: <69iXE2clpZugZG7uCzAmZfSzAaRBTNJnnPpLnVgWb2M=.dcbc8323-489d-4a75-85b1-a7f0b5fea7ba@github.com> Message-ID: On Wed, 10 May 2023 08:49:47 GMT, Kevin Walls wrote: >> Removal of class, looks like it was missed in the JDK9 removal of RMIIIOP. >> This class is not referenced by other classes or tests. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > example update src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnector.java line 188: > 186: * > 187: * 
> 188:      * service:jmx:protocolname://[host[:port]]/stub/encoded-stub

"protocolname" could be read as literal here. I think change it back to "iiop" or replace it with something that like "myprotocol" that is more obviously an example protocol name.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13758#discussion_r1189583710

From kevinw at openjdk.org  Wed May 10 09:13:42 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 10 May 2023 09:13:42 GMT
Subject: jmx-dev RFR: 8307244: Remove redundant class RMIIIOPServerImpl
 [v2]
In-Reply-To: 
References: <69iXE2clpZugZG7uCzAmZfSzAaRBTNJnnPpLnVgWb2M=.dcbc8323-489d-4a75-85b1-a7f0b5fea7ba@github.com>
 
 
Message-ID: <65OAH8iBRRCTB6Xs4r8HSz20I-zTYxaUCYQBG6-jVws=.e35d29b0-8236-4bd6-97c3-ab5b0ebc809a@github.com>

On Wed, 10 May 2023 09:01:16 GMT, Alan Bateman  wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   example update
>
> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnector.java line 188:
> 
>> 186:      *
>> 187:      * 
>> 188:      * service:jmx:protocolname://[host[:port]]/stub/encoded-stub
> 
> "protocolname" could be read as literal here. I think change it back to "iiop" or replace it with something that like "myprotocol" that is more obviously an example protocol name.

ok

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13758#discussion_r1189585454

From kevinw at openjdk.org  Wed May 10 09:13:43 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 10 May 2023 09:13:43 GMT
Subject: jmx-dev RFR: 8307244: Remove redundant class RMIIIOPServerImpl
 [v2]
In-Reply-To: <65OAH8iBRRCTB6Xs4r8HSz20I-zTYxaUCYQBG6-jVws=.e35d29b0-8236-4bd6-97c3-ab5b0ebc809a@github.com>
References: <69iXE2clpZugZG7uCzAmZfSzAaRBTNJnnPpLnVgWb2M=.dcbc8323-489d-4a75-85b1-a7f0b5fea7ba@github.com>
 
 
 <65OAH8iBRRCTB6Xs4r8HSz20I-zTYxaUCYQBG6-jVws=.e35d29b0-8236-4bd6-97c3-ab5b0ebc809a@github.com>
Message-ID: 

On Wed, 10 May 2023 09:02:40 GMT, Kevin Walls  wrote:

>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnector.java line 188:
>> 
>>> 186:      *
>>> 187:      * 
>>> 188:      * service:jmx:protocolname://[host[:port]]/stub/encoded-stub
>> 
>> "protocolname" could be read as literal here. I think change it back to "iiop" or replace it with something that like "myprotocol" that is more obviously an example protocol name.
>
> ok

Could it really?  But ok, done. 8-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13758#discussion_r1189592303

From kevinw at openjdk.org  Wed May 10 16:48:31 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 10 May 2023 16:48:31 GMT
Subject: jmx-dev Integrated: 8307244: Remove redundant class
 RMIIIOPServerImpl
In-Reply-To: <69iXE2clpZugZG7uCzAmZfSzAaRBTNJnnPpLnVgWb2M=.dcbc8323-489d-4a75-85b1-a7f0b5fea7ba@github.com>
References: <69iXE2clpZugZG7uCzAmZfSzAaRBTNJnnPpLnVgWb2M=.dcbc8323-489d-4a75-85b1-a7f0b5fea7ba@github.com>
Message-ID: 

On Tue, 2 May 2023 17:57:14 GMT, Kevin Walls  wrote:

> Removal of class, looks like it was missed in the JDK9 removal of RMIIIOP.
> This class is not referenced by other classes or tests.

This pull request has now been integrated.

Changeset: 9af1787e
Author:    Kevin Walls 
URL:       https://git.openjdk.org/jdk/commit/9af1787ebe842bcfbf4a03a9deefe19bbd1ee87d
Stats:     97 lines in 2 files changed: 0 ins; 96 del; 1 mod

8307244: Remove redundant class RMIIIOPServerImpl

Reviewed-by: sspitsyn, dfuchs, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/13758

From phh at openjdk.org  Wed May 10 23:57:47 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 10 May 2023 23:57:47 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v13]
In-Reply-To: 
References: 
Message-ID: 

> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
> 
> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.

Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:

  8304074: getTotalThreadAllocatedBytes name change, increment exited_allocated_bytes in ThreadService::remove_thread, add 64-bit atomic add for linux/bsd_x86, stub out for other platforms

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13814/files
  - new: https://git.openjdk.org/jdk/pull/13814/files/fbe3c114..ab830a80

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=11-12

  Stats: 159 lines in 11 files changed: 112 ins; 13 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/13814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814

PR: https://git.openjdk.org/jdk/pull/13814

From dholmes at openjdk.org  Thu May 11 03:44:48 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 11 May 2023 03:44:48 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v13]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 10 May 2023 23:57:47 GMT, Paul Hohensee  wrote:

>> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
>> 
>> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.
>
> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8304074: getTotalThreadAllocatedBytes name change, increment exited_allocated_bytes in ThreadService::remove_thread, add 64-bit atomic add for linux/bsd_x86, stub out for other platforms

src/hotspot/share/services/management.cpp line 2107:

> 2105:     // twice, once in the loop and agsin in exited_allocated_bytes if it's
> 2106:     // removed from the list after it's encountered in the loop but before
> 2107:     // adding exited_allocated_bytes.

This is not an accurate description.

Once we have the TLH we have a fixed set of threads and none of them can update exited_allocated_bytes. If we read exited_allocated_bytes while the TLH is held then the count can be short for two reasons:
1. Newly started threads
2. Terminating threads that already escaped the TLH but which hadn't updated exited_allocated_bytes by the time we read it.
AFAICS with the current logic there is no possibility of double-accounting.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1190602862

From dholmes at openjdk.org  Thu May 11 03:44:49 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 11 May 2023 03:44:49 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v13]
In-Reply-To: 
References: 
 
 
Message-ID: <6F9zxoLzGalf8OfpzEiICx-gOwufx2PCgMlLQIQ6PVM=.8cefee49-1ba7-4163-83f7-7dfb214796d2@github.com>

On Thu, 11 May 2023 03:40:31 GMT, David Holmes  wrote:

>> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8304074: getTotalThreadAllocatedBytes name change, increment exited_allocated_bytes in ThreadService::remove_thread, add 64-bit atomic add for linux/bsd_x86, stub out for other platforms
>
> src/hotspot/share/services/management.cpp line 2107:
> 
>> 2105:     // twice, once in the loop and agsin in exited_allocated_bytes if it's
>> 2106:     // removed from the list after it's encountered in the loop but before
>> 2107:     // adding exited_allocated_bytes.
> 
> This is not an accurate description.
> 
> Once we have the TLH we have a fixed set of threads and none of them can update exited_allocated_bytes. If we read exited_allocated_bytes while the TLH is held then the count can be short for two reasons:
> 1. Newly started threads
> 2. Terminating threads that already escaped the TLH but which hadn't updated exited_allocated_bytes by the time we read it.
> AFAICS with the current logic there is no possibility of double-accounting.

Sorry I thought you had made the change to only update exited_allocated_bytes after the thread removed itself from the threads-list. It really makes things so much simpler.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1190603367

From kevinw at openjdk.org  Thu May 11 12:10:46 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 11 May 2023 12:10:46 GMT
Subject: jmx-dev RFR: 8306806: JMX agent with JDP enabled won't start when
 PerfData is disabled
Message-ID: 

Java Discovery Protocol (perhaps a hidden feature, but maybe should be more widely known!) and -XX:-UsePerfData together cause a failure to startup.

PerfData is the mechanism for communicating the URL and other properties for remote management, so disabling PerfData clearly breaks this.  But there should be a clearer message, and not a fatal error.

e.g.
$ java -XX:-UsePerfData  -Dcom.sun.management.jmxremote.autodiscovery=true -Dcom.sun.management.jmxremote.port=0 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false --version
Warning: Exception thrown by the agent : JDP not starting, PerfData not available: Empty PerfData buffer
java 21-internal 2023-09-19 LTS
...etc...

The use of PerfData is superior to the previous hard-coding of knowledge of the URL protocol and structure, and is required to communicate a dynamically assigned port (JDK-8167337).

-------------

Commit messages:
 - 8306806: JMX agent with JDP enabled won't start when PerfData is disabled

Changes: https://git.openjdk.org/jdk/pull/13928/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13928&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306806
  Stats: 16 lines in 2 files changed: 8 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/13928.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13928/head:pull/13928

PR: https://git.openjdk.org/jdk/pull/13928

From jlu at openjdk.org  Thu May 11 20:21:57 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 20:21:57 GMT
Subject: jmx-dev RFR: 8301991: Convert l10n properties resource bundles
 to UTF-8 native [v6]
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: 

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Convert the merged master changes to UTF-8
 - Merge master and fix conflicts
 - Close streams when finished loading into props
 - Adjust CF test to read in with UTF-8 to fix failing test
 - Reconvert CS.properties to UTF-8
 - Revert all changes to CurrencySymbols.properties
 - Bug6204853 should not be converted
 - Copyright year for CompileProperties
 - Redo translation for CS.properties
 - Spot convert CurrencySymbols.properties
 - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

-------------

Changes: https://git.openjdk.org/jdk/pull/12726/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=05
  Stats: 28877 lines in 493 files changed: 14 ins; 1 del; 28862 mod
  Patch: https://git.openjdk.org/jdk/pull/12726.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12726/head:pull/12726

PR: https://git.openjdk.org/jdk/pull/12726

From jlu at openjdk.org  Thu May 11 21:39:50 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 21:39:50 GMT
Subject: jmx-dev RFR: 8301991: Convert l10n properties resource bundles
 to UTF-8 native [v6]
In-Reply-To: 
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 
Message-ID: 

On Thu, 11 May 2023 20:21:57 GMT, Justin Lu  wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Convert the merged master changes to UTF-8
>  - Merge master and fix conflicts
>  - Close streams when finished loading into props
>  - Adjust CF test to read in with UTF-8 to fix failing test
>  - Reconvert CS.properties to UTF-8
>  - Revert all changes to CurrencySymbols.properties
>  - Bug6204853 should not be converted
>  - Copyright year for CompileProperties
>  - Redo translation for CS.properties
>  - Spot convert CurrencySymbols.properties
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

Wondering if anyone has any thoughts on the consequences of this PR, in relation to Intellj's (and other IDEs) default encoding for .properties files. Intellj sets the default encoding for .properties files to ISO-8859-1, which would be the wrong encoding if the .properties files are converted to UTF-8 native. This would cause certain key,values to be skewed when represented in the file. 

Although the default file-encoding for .properties can be switched to UTF-8, it is not the default.

Wondering what some solutions/thoughts to this are.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1544708830

From naoto at openjdk.org  Thu May 11 21:51:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 11 May 2023 21:51:13 GMT
Subject: jmx-dev RFR: 8301991: Convert l10n properties resource bundles
 to UTF-8 native [v6]
In-Reply-To: 
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 
Message-ID: <2apKDcin5cwY53zz5jOIPhqm7cCWhyYMdsXGU4TauEk=.781d695e-39fe-46f7-bd03-be514ca0b85c@github.com>

On Thu, 11 May 2023 20:21:57 GMT, Justin Lu  wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Convert the merged master changes to UTF-8
>  - Merge master and fix conflicts
>  - Close streams when finished loading into props
>  - Adjust CF test to read in with UTF-8 to fix failing test
>  - Reconvert CS.properties to UTF-8
>  - Revert all changes to CurrencySymbols.properties
>  - Bug6204853 should not be converted
>  - Copyright year for CompileProperties
>  - Redo translation for CS.properties
>  - Spot convert CurrencySymbols.properties
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

I think this is fine, as those properties files are JDK's own. I believe the benefit of moving to UTF-8 outweighs the issue you wrote, which can be remedied by changing the encoding in the IDEs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1544722480

From phh at openjdk.org  Thu May 11 23:01:08 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Thu, 11 May 2023 23:01:08 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v14]
In-Reply-To: 
References: 
Message-ID: 

> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
> 
> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.

Paul Hohensee has updated the pull request incrementally with three additional commits since the last revision:

 - 8304074: set _atomic_add_long_entry = ShouldNotCallThisStub()
 - 8304074: update jmm_GetTotalAllocatedBytes comment
 - 8304074: Use __atomic_add_fetch rather than TBD assembler stub

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13814/files
  - new: https://git.openjdk.org/jdk/pull/13814/files/ab830a80..5515fc59

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=12-13

  Stats: 42 lines in 3 files changed: 16 ins; 15 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/13814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814

PR: https://git.openjdk.org/jdk/pull/13814

From dholmes at openjdk.org  Fri May 12 04:58:42 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 12 May 2023 04:58:42 GMT
Subject: jmx-dev RFR: 8306806: JMX agent with JDP enabled won't start
 when PerfData is disabled
In-Reply-To: 
References: 
Message-ID: 

On Thu, 11 May 2023 11:42:38 GMT, Kevin Walls  wrote:

> Java Discovery Protocol (perhaps a hidden feature, but maybe should be more widely known!) and -XX:-UsePerfData together cause a failure to startup.
> 
> PerfData is the mechanism for communicating the URL and other properties for remote management, so disabling PerfData clearly breaks this.  But there should be a clearer message, and not a fatal error.
> 
> e.g.
> $ java -XX:-UsePerfData  -Dcom.sun.management.jmxremote.autodiscovery=true -Dcom.sun.management.jmxremote.port=0 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false --version
> Warning: Exception thrown by the agent : JDP not starting, PerfData not available: Empty PerfData buffer
> java 21-internal 2023-09-19 LTS
> ...etc...
> 
> The use of PerfData is superior to the previous hard-coding of knowledge of the URL protocol and structure, and is required to communicate a dynamically assigned port (JDK-8167337).

src/jdk.management.agent/share/classes/jdk/internal/agent/Agent.java line 506:

> 504:                 remoteProps = ConnectorAddressLink.importRemoteFrom(0);
> 505:             } catch (IOException ioe) {
> 506:                 warning(AGENT_EXCEPTION, "JDP not starting, PerfData not available: " + ioe.getMessage());

Is this the only possible reason?

As per the JBS link I added there is a general problem about the Java side of the "Perf" code not knowing/realizing that `UsePerfData` can be disabled. Ideally there would be a way to query this, or a specific type of exception that could be thrown to report it.

Will the user understand what this message means? Should it explicitly say "please ensure -XX:-UsePerfData" is not set?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13928#discussion_r1191905273

From kevinw at openjdk.org  Fri May 12 09:15:47 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 12 May 2023 09:15:47 GMT
Subject: jmx-dev RFR: 8306806: JMX agent with JDP enabled won't start
 when PerfData is disabled [v2]
In-Reply-To: 
References: 
Message-ID: 

> Java Discovery Protocol (perhaps a hidden feature, but maybe should be more widely known!) and -XX:-UsePerfData together cause a failure to startup.
> 
> PerfData is the mechanism for communicating the URL and other properties for remote management, so disabling PerfData clearly breaks this.  But there should be a clearer message, and not a fatal error.
> 
> e.g.
> $ java -XX:-UsePerfData  -Dcom.sun.management.jmxremote.autodiscovery=true -Dcom.sun.management.jmxremote.port=0 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false --version
> Warning: Exception thrown by the agent : JDP not starting, PerfData not available: Empty PerfData buffer
> java 21-internal 2023-09-19 LTS
> ...etc...
> 
> The use of PerfData is superior to the previous hard-coding of knowledge of the URL protocol and structure, and is required to communicate a dynamically assigned port (JDK-8167337).

Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:

 - undo (C)
 - Handle BufferUndeflowException to leave IOException free for other failures

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13928/files
  - new: https://git.openjdk.org/jdk/pull/13928/files/fa0fa449..4dcaf76d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13928&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13928&range=00-01

  Stats: 7 lines in 2 files changed: 1 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13928.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13928/head:pull/13928

PR: https://git.openjdk.org/jdk/pull/13928

From kevinw at openjdk.org  Fri May 12 09:15:49 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 12 May 2023 09:15:49 GMT
Subject: jmx-dev RFR: 8306806: JMX agent with JDP enabled won't start
 when PerfData is disabled [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 12 May 2023 04:55:30 GMT, David Holmes  wrote:

> Is this the only possible reason?

Yes I think it is - although IOException is already declared by importRemoteFrom, and that calls perf.attach(id) which declares IOException, the native Perf_Attach doesn't look like it throws it (OOM and IllegalArgument can be thrown).

BUT maybe a better alternative is to catch the BufferUnderflowException, this is the unchecked Exception which currently terminates us.  This is more specific and safer in case we ever do make more use of IOException in the attach - I wil update...

(Use of ConnectorAddressLink is all about communication within the same process so it doesn't expect any problems...)


> Will the user understand what this message means?

If I use the BufferUnderflowException, there's no detail message so it will say:

Warning: Exception thrown by the agent : JDP not starting, PerfData not available

If you have added -UsePerfData you should see the connection, it's not too chatty, and isn't saying too much in case it's wrong and the perfdata failed to allocate for some other reason.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13928#discussion_r1192113851

From phh at openjdk.org  Fri May 12 14:50:51 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 12 May 2023 14:50:51 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v13]
In-Reply-To: <6F9zxoLzGalf8OfpzEiICx-gOwufx2PCgMlLQIQ6PVM=.8cefee49-1ba7-4163-83f7-7dfb214796d2@github.com>
References: 
 
 
 <6F9zxoLzGalf8OfpzEiICx-gOwufx2PCgMlLQIQ6PVM=.8cefee49-1ba7-4163-83f7-7dfb214796d2@github.com>
Message-ID: 

On Thu, 11 May 2023 03:41:46 GMT, David Holmes  wrote:

>> src/hotspot/share/services/management.cpp line 2107:
>> 
>>> 2105:     // twice, once in the loop and agsin in exited_allocated_bytes if it's
>>> 2106:     // removed from the list after it's encountered in the loop but before
>>> 2107:     // adding exited_allocated_bytes.
>> 
>> This is not an accurate description.
>> 
>> Once we have the TLH we have a fixed set of threads and none of them can update exited_allocated_bytes. If we read exited_allocated_bytes while the TLH is held then the count can be short for two reasons:
>> 1. Newly started threads
>> 2. Terminating threads that already escaped the TLH but which hadn't updated exited_allocated_bytes by the time we read it.
>> AFAICS with the current logic there is no possibility of double-accounting.
>
> Sorry I thought you had made the change to only update exited_allocated_bytes after the thread removed itself from the threads-list. It really makes things so much simpler.

I made that change. The comment now reads:
    // A thread increments exited_allocated_bytes in ThreadService::remove_thread                                                                                                                                                                                                                                                                                           
    // only after it removes itself from the threads list, and once a TLH is                                                                                                                                                                                                                                                                                                
    // created, no thread it references can remove itself from the threads                                                                                                                                                                                                                                                                                                  
    // list, so none can update exited_allocated_bytes. We therefore initialize                                                                                                                                                                                                                                                                                             
    // result with exited_allocated_bytes after after we create the TLH so that                                                                                                                                                                                                                                                                                             
    // the final result can only be short due to (1) threads that start after                                                                                                                                                                                                                                                                                               
    // the TLH is created, or (2) terminating threads that escape TLH creation                                                                                                                                                                                                                                                                                              
    // and don't update exited_allocated_bytes before we initialize result.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1192473858

From phh at openjdk.org  Fri May 12 15:12:54 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 12 May 2023 15:12:54 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v15]
In-Reply-To: 
References: 
Message-ID: 

> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
> 
> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.

Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:

  8304074: Define FULL_MEM_BARRIER for linux_arm

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13814/files
  - new: https://git.openjdk.org/jdk/pull/13814/files/5515fc59..4ce0ede7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=13-14

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814

PR: https://git.openjdk.org/jdk/pull/13814

From phh at openjdk.org  Fri May 12 15:12:59 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 12 May 2023 15:12:59 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v11]
In-Reply-To: 
References: 
 
 
Message-ID: <5yCKYh4Oo3wqW8ugeGQUn4IYErSIbOhPK1zFic8_p7o=.290c8fbe-6f5f-4907-bda2-9ce0c74f0586@github.com>

On Tue, 9 May 2023 01:12:06 GMT, David Holmes  wrote:

>> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implement 32-bit linux Atomic::add()
>
> src/hotspot/share/services/management.cpp line 2107:
> 
>> 2105:     // when result is initialized. The iterator is created and initialized
>> 2106:     // before the call to exited_allocated_bytes to ensure we don't miss
>> 2107:     // accounting for threads that are just about to terminate.
> 
> Sorry this is only accurate if a thread updates `exited_allocated_bytes` after it removes itself from the Threads-list.

Fixed, see below.

> src/jdk.management/share/classes/com/sun/management/ThreadMXBean.java line 119:
> 
>> 117:      * @implSpec The default implementation throws UnsupportedOperationException
>> 118:      * if the Java virtual machine implementation does not support thread
>> 119:      * memory allocation measuremust, and otherwise acts as though thread
> 
> Typo: measuremust

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1192494127
PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1192494309

From phh at openjdk.org  Fri May 12 15:12:56 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 12 May 2023 15:12:56 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v15]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: <-eGYyEEAmjJDy0O8-m8FiMshcLaoRAKgY-a5qSUp3hQ=.9667188b-1eb1-45f9-aaf2-554dbacb3645@github.com>

On Mon, 8 May 2023 02:07:25 GMT, David Holmes  wrote:

>> Afaiu, SMR/TLH keeps a terminated thread's TLS accessible, but doesn't stop the termination process.
>> 
>> If we initialize result with exited_allocated_bytes, the "too small" possibility is still there. We still have a window between that initialization and the creation of the threads iterator where threads may terminate and thus not be included in the iteration. And new threads may become active during the iteration and not be included. As Aleksey observes, an advantage is that threads that terminate during the iteration will be counted only once and we don't have to check for terminated threads.
>> 
>> If we stick with adding exited_allocated_bytes to result after the iteration, Volker is correct that we shouldn't include terminated threads in the sum because their allocated bytes values will have been added to exited_allocated_bytes. We have the same undercount possibility that initializing result with exited_allocated_bytes has, so this (fixed) approach can result in "too small" also, but "too large" goes away.
>> 
>> Looks like both approaches are equivalent, so let's go with initializing result with exited_allocated_bytes because it avoids a comparison in the loop.
>
>> Afaiu, SMR/TLH keeps a terminated thread's TLS accessible, but doesn't stop the termination process.
> 
> Incorrect. A thread cannot complete the termination process if it is contained by a TLH - see ` ThreadsSMRSupport::smr_delete` and the call to `wait_until_not_protected`.
> 
> But not sure that helps with the zero-else-double accounting problem. Any read of the "total accumulated bytes written to date" value is racing with terminating threads.

Resolved, see below.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1192494925

From phh at openjdk.org  Fri May 12 15:13:00 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 12 May 2023 15:13:00 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v5]
In-Reply-To: 
References: 
 
 <1-dU7miE3DgmLHf1LWgwDrqppK2l2Y5OwYkms3QMCIs=.398dcfe2-12b6-42e7-ac44-1cec2f729432@github.com>
 
 
Message-ID: <0V19VrgjOtIha8ysKYm1W51FSCBMT4AkDAjjSOEw2kk=.f8e29f51-a3f6-4726-b7af-af3031ff3953@github.com>

On Tue, 9 May 2023 01:04:02 GMT, David Holmes  wrote:

>> Do you mean something like:
>> 
>>     JavaThreadIteratorWithHandle jtiwh;
>>     jlong result = ThreadService::exited_allocated_bytes();
>>     while (JavaThread *thread = jtiwh.next()) {
>>       ...
>> 
>> That would be fine for me. Otherwise I agree with the current compromise between accuracy and speed.
>
> Yes. Though I realize my comment needed to make clear that you need a thread to update the count after it has removed itself from the thread-list, for this to be an improvement.

Done as Volker suggests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1192495715

From phh at openjdk.org  Fri May 12 15:13:00 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 12 May 2023 15:13:00 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v5]
In-Reply-To: 
References: 
 
 <1-dU7miE3DgmLHf1LWgwDrqppK2l2Y5OwYkms3QMCIs=.398dcfe2-12b6-42e7-ac44-1cec2f729432@github.com>
 
 
 
Message-ID: 

On Tue, 9 May 2023 14:21:05 GMT, Volker Simonis  wrote:

>> @dcubed-ojdk This is the current thread acting on itself
>
> This method (i.e. `ThreadService::remove_thread()`) is called from `Threads::remove()` *after* the thread was removed from the thread list:
> 
> void Threads::remove(JavaThread* p, bool is_daemon) {
>   ...
>     // Maintain fast thread list
>     ThreadsSMRSupport::remove_thread(p);
>     ...
>     ThreadService::remove_thread(p, is_daemon);
> 
> 
> But if we reach here from `JavaThread::cleanup_failed_attach_current_thread()` as the comment implies (`JavaThread::cleanup_failed_attach_current_thread()` calls `Threads::remove()` in the case of an attach failure), calling `ThreadService::incr_exited_allocated_bytes()` is probably irrelevant, because a thread which failed to attach can't allocate anyway.
> 
> So instead of doing the call to `ThreadService::incr_exited_allocated_bytes()` here you can do it unconditionally and move it up before the check for `is_hidden_thread()`. This would then also account for regular thread exits where you arrive here from `JavaThread::exit()` and make the call to `ThreadService::incr_exited_allocated_bytes()` in `ThreadService::current_thread_exiting()` obsolete (also see my comment there).

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1192495985

From phh at openjdk.org  Fri May 12 15:13:02 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 12 May 2023 15:13:02 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v12]
In-Reply-To: 
References: 
 
 
 
Message-ID: <6M3zMGxkBzOFBzBprMF7hbjwmkn4aWOcucBeKeab2qA=.5d2b169c-40c8-42ed-abe0-3143fcc864fc@github.com>

On Tue, 9 May 2023 14:30:06 GMT, Volker Simonis  wrote:

>> src/hotspot/share/services/threadService.cpp line 224:
>> 
>>> 222: 
>>> 223:   decrement_thread_counts(jt, daemon);
>>> 224:   ThreadService::incr_exited_allocated_bytes(jt->cooked_allocated_bytes());
>> 
>> Again this is too soon. This should be deferred until after the thread has removed itself from the threads-list.
>
> Here I agree. This method (i.e. `ThreadService::current_thread_exiting()`)  is called from `JavaThread::exit()` *before* the call to `Threads::remove()`. I think this call here to `ThreadService::incr_exited_allocated_bytes()` could be removed completely in favor of an unconditional call to `ThreadService::incr_exited_allocated_bytes()` in `ThreadService::remove_thread()` (which will be called by `Threads::remove()` *after* it removed the thread from the thread list). See my comment there.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1192493634

From phh at openjdk.org  Fri May 12 17:38:15 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 12 May 2023 17:38:15 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v16]
In-Reply-To: 
References: 
Message-ID: 

> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
> 
> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.

Paul Hohensee 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 20 additional commits since the last revision:

 - 8304074: Assign to _add_long_func in add_long_bootstrap
 - Merge branch 'master' into 8304074
 - 8304074: Define FULL_MEM_BARRIER for linux_arm
 - 8304074: set _atomic_add_long_entry = ShouldNotCallThisStub()
 - 8304074: update jmm_GetTotalAllocatedBytes comment
 - 8304074: Use __atomic_add_fetch rather than TBD assembler stub
 - 8304074: getTotalThreadAllocatedBytes name change, increment exited_allocated_bytes in ThreadService::remove_thread, add 64-bit atomic add for linux/bsd_x86, stub out for other platforms
 - Implement 32-bit linux Atomic::add()
 - Implement 32-bit linux Atomic::add()
 - Implement 32-bit linux Atomic::add()
 - ... and 10 more: https://git.openjdk.org/jdk/compare/e38628f9...ab3b9080

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13814/files
  - new: https://git.openjdk.org/jdk/pull/13814/files/4ce0ede7..ab3b9080

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=14-15

  Stats: 108483 lines in 1798 files changed: 86806 ins; 8865 del; 12812 mod
  Patch: https://git.openjdk.org/jdk/pull/13814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814

PR: https://git.openjdk.org/jdk/pull/13814

From phh at openjdk.org  Fri May 12 19:57:24 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 12 May 2023 19:57:24 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v17]
In-Reply-To: 
References: 
Message-ID: 

> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
> 
> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.

Paul Hohensee has updated the pull request incrementally with two additional commits since the last revision:

 - 8304704: Typos
 - 8304074: fetch_then_add, not fetch_and_add

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13814/files
  - new: https://git.openjdk.org/jdk/pull/13814/files/ab3b9080..5e5ec87a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=15-16

  Stats: 94 lines in 4 files changed: 0 ins; 88 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814

PR: https://git.openjdk.org/jdk/pull/13814

From phh at openjdk.org  Sun May 14 22:50:03 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Sun, 14 May 2023 22:50:03 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v18]
In-Reply-To: 
References: 
Message-ID: 

> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
> 
> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.

Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:

  8304704: In getTotalThreadAllocatedBytes javadoc, 'launched' -> 'started'

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13814/files
  - new: https://git.openjdk.org/jdk/pull/13814/files/5e5ec87a..998a72ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=16-17

  Stats: 3 lines in 3 files changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814

PR: https://git.openjdk.org/jdk/pull/13814

From dholmes at openjdk.org  Mon May 15 08:47:55 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 15 May 2023 08:47:55 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v18]
In-Reply-To: 
References: 
 
Message-ID: 

On Sun, 14 May 2023 22:50:03 GMT, Paul Hohensee  wrote:

>> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
>> 
>> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.
>
> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8304704: In getTotalThreadAllocatedBytes javadoc, 'launched' -> 'started'

Sorry to be a pain but can you split the Atomic changes out of this PR into their own issue please.

Though having said that, now that you call incr_exited_allocayed_bytes() where you do, it is protected by the Threads_lock so no atomic add is needed now.

src/hotspot/share/services/#allocationSite.hpp# line 1:

> (failed to retrieve contents of file, check the PR for context)
Shouldn't be here.

src/hotspot/share/services/.#allocationSite.hpp line 1:

> (failed to retrieve contents of file, check the PR for context)
Shouldn't be here.

src/hotspot/share/services/threadService.hpp line 65:

> 63: 
> 64:   // As could this...
> 65:   // Number of heap bytes allocated by termianted threads.

typo: termianted

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13814#pullrequestreview-1426048798
PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1193513616
PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1193513762
PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1193518539

From dholmes at openjdk.org  Mon May 15 09:04:46 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 15 May 2023 09:04:46 GMT
Subject: jmx-dev RFR: 8306806: JMX agent with JDP enabled won't start
 when PerfData is disabled [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 12 May 2023 09:15:47 GMT, Kevin Walls  wrote:

>> Java Discovery Protocol (perhaps a hidden feature, but maybe should be more widely known!) and -XX:-UsePerfData together cause a failure to startup.
>> 
>> PerfData is the mechanism for communicating the URL and other properties for remote management, so disabling PerfData clearly breaks this.  But there should be a clearer message, and not a fatal error.
>> 
>> e.g.
>> $ java -XX:-UsePerfData  -Dcom.sun.management.jmxremote.autodiscovery=true -Dcom.sun.management.jmxremote.port=0 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false --version
>> Warning: Exception thrown by the agent : JDP not starting, PerfData not available: Empty PerfData buffer
>> java 21-internal 2023-09-19 LTS
>> ...etc...
>> 
>> The use of PerfData is superior to the previous hard-coding of knowledge of the URL protocol and structure, and is required to communicate a dynamically assigned port (JDK-8167337).
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - undo (C)
>  - Handle BufferUndeflowException to leave IOException free for other failures

Okay - seems reasonable.

Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13928#pullrequestreview-1426098612

From simonis at openjdk.org  Mon May 15 13:26:58 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 15 May 2023 13:26:58 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v11]
In-Reply-To: <5H2URzZb5RyC9iJVBHjMjddju_av39gTMtw-d_BQPAM=.9add750e-e988-4e25-8351-63b53230f856@github.com>
References: 
 
 <5H2URzZb5RyC9iJVBHjMjddju_av39gTMtw-d_BQPAM=.9add750e-e988-4e25-8351-63b53230f856@github.com>
Message-ID: <4imb6CRk1kOj5MT1OLCUmxPJksXrubz2vf5hIzLrwy8=.d9b99b1f-f4b4-49ba-b6b2-18571d7b8e2f@github.com>

On Tue, 9 May 2023 01:23:23 GMT, David Holmes  wrote:

>> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implement 32-bit linux Atomic::add()
>
> Also note that the current placement of the `incr_exited_allocated_bytes` skips accounting for hidden threads because those ThreadService methods skip hidden threads. You need to do this update as one of the last actions of a terminating/detaching thread.

Looks good now except for the points already mentioned by @dholmes-ora .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13814#issuecomment-1547855460

From phh at openjdk.org  Mon May 15 23:12:52 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Mon, 15 May 2023 23:12:52 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v19]
In-Reply-To: 
References: 
Message-ID: <0-pS2sIemk1XBwGFmEPOuw2IE7DCNhpRX4KK08DB3jY=.b8affc55-8666-4ff2-836c-d041ce03d95a@github.com>

> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
> 
> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.

Paul Hohensee 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 26 additional commits since the last revision:

 - 8304704: _exited_allocated_bytes increment does not have to be atomic
 - Merge branch 'master' into 8304074
 - 8304704: _exited_allocated_bytes increment does not have to be atomic
 - 8304704: In getTotalThreadAllocatedBytes javadoc, 'launched' -> 'started'
 - 8304704: Typos
 - 8304074: fetch_then_add, not fetch_and_add
 - 8304074: Assign to _add_long_func in add_long_bootstrap
 - Merge branch 'master' into 8304074
 - 8304074: Define FULL_MEM_BARRIER for linux_arm
 - 8304074: set _atomic_add_long_entry = ShouldNotCallThisStub()
 - ... and 16 more: https://git.openjdk.org/jdk/compare/7f45a6df...effdefc6

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13814/files
  - new: https://git.openjdk.org/jdk/pull/13814/files/998a72ad..effdefc6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=17-18

  Stats: 4747 lines in 164 files changed: 2973 ins; 690 del; 1084 mod
  Patch: https://git.openjdk.org/jdk/pull/13814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814

PR: https://git.openjdk.org/jdk/pull/13814

From phh at openjdk.org  Mon May 15 23:23:52 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Mon, 15 May 2023 23:23:52 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v19]
In-Reply-To: <0-pS2sIemk1XBwGFmEPOuw2IE7DCNhpRX4KK08DB3jY=.b8affc55-8666-4ff2-836c-d041ce03d95a@github.com>
References: 
 <0-pS2sIemk1XBwGFmEPOuw2IE7DCNhpRX4KK08DB3jY=.b8affc55-8666-4ff2-836c-d041ce03d95a@github.com>
Message-ID: 

On Mon, 15 May 2023 23:12:52 GMT, Paul Hohensee  wrote:

>> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
>> 
>> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.
>
> Paul Hohensee 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 26 additional commits since the last revision:
> 
>  - 8304704: _exited_allocated_bytes increment does not have to be atomic
>  - Merge branch 'master' into 8304074
>  - 8304704: _exited_allocated_bytes increment does not have to be atomic
>  - 8304704: In getTotalThreadAllocatedBytes javadoc, 'launched' -> 'started'
>  - 8304704: Typos
>  - 8304074: fetch_then_add, not fetch_and_add
>  - 8304074: Assign to _add_long_func in add_long_bootstrap
>  - Merge branch 'master' into 8304074
>  - 8304074: Define FULL_MEM_BARRIER for linux_arm
>  - 8304074: set _atomic_add_long_entry = ShouldNotCallThisStub()
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/6d9db9f6...effdefc6

Makes things very much simpler without needing 64-bit atomic add. Hopefully all cleaned up.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13814#issuecomment-1548745902

From phh at openjdk.org  Tue May 16 04:35:50 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 16 May 2023 04:35:50 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v11]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Tue, 9 May 2023 01:40:20 GMT, Paul Hohensee  wrote:

>> src/hotspot/share/runtime/atomic.hpp line 310:
>> 
>>> 308: 
>>> 309:   // Platform-specific implementation of add.  Support for sizes of 4
>>> 310:   // and 8 bytes are required.  The class must be default constructable,
>> 
>> Comment change seems unnecessary.
>
> I found that I had to add 64-bit atomic add support on 32-bit platforms (working on it), so I changed the comment to match the similar cmpxchg one.

Reverted, since 64-bit atomic add is no longer needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1194447125

From phh at openjdk.org  Tue May 16 04:35:53 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 16 May 2023 04:35:53 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v18]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 15 May 2023 08:34:53 GMT, David Holmes  wrote:

>> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8304704: In getTotalThreadAllocatedBytes javadoc, 'launched' -> 'started'
>
> src/hotspot/share/services/#allocationSite.hpp# line 1:
> 
>> (failed to retrieve contents of file, check the PR for context)
> Shouldn't be here.

Removed.

> src/hotspot/share/services/.#allocationSite.hpp line 1:
> 
>> (failed to retrieve contents of file, check the PR for context)
> Shouldn't be here.

Removed.

> src/hotspot/share/services/threadService.hpp line 65:
> 
>> 63: 
>> 64:   // As could this...
>> 65:   // Number of heap bytes allocated by termianted threads.
> 
> typo: termianted

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1194447382
PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1194447452
PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1194447500

From phh at openjdk.org  Tue May 16 04:35:56 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 16 May 2023 04:35:56 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v5]
In-Reply-To: <1-dU7miE3DgmLHf1LWgwDrqppK2l2Y5OwYkms3QMCIs=.398dcfe2-12b6-42e7-ac44-1cec2f729432@github.com>
References: 
 
 <1-dU7miE3DgmLHf1LWgwDrqppK2l2Y5OwYkms3QMCIs=.398dcfe2-12b6-42e7-ac44-1cec2f729432@github.com>
Message-ID: 

On Mon, 8 May 2023 02:15:03 GMT, David Holmes  wrote:

>> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM
>
> src/jdk.management/share/classes/com/sun/management/ThreadMXBean.java line 111:
> 
>> 109:      * Returns an approximation of the total amount of memory, in bytes,
>> 110:      * allocated in heap memory since the Java virtual machine was launched,
>> 111:      * including the amount allocated by terminated threads.
> 
> This "including ..." part seems redundant - it is the value allocated since JVM launch.

Removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1194446883

From dholmes at openjdk.org  Tue May 16 04:41:55 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 May 2023 04:41:55 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v19]
In-Reply-To: <0-pS2sIemk1XBwGFmEPOuw2IE7DCNhpRX4KK08DB3jY=.b8affc55-8666-4ff2-836c-d041ce03d95a@github.com>
References: 
 <0-pS2sIemk1XBwGFmEPOuw2IE7DCNhpRX4KK08DB3jY=.b8affc55-8666-4ff2-836c-d041ce03d95a@github.com>
Message-ID: <5aCwLaLKijz0hnfzEeRW1BSNhtv6bN_hIOGb0FcNX-g=.3c69db74-5838-486e-bfd6-7a2bd62c8ded@github.com>

On Mon, 15 May 2023 23:12:52 GMT, Paul Hohensee  wrote:

>> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
>> 
>> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.
>
> Paul Hohensee 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 26 additional commits since the last revision:
> 
>  - 8304704: _exited_allocated_bytes increment does not have to be atomic
>  - Merge branch 'master' into 8304074
>  - 8304704: _exited_allocated_bytes increment does not have to be atomic
>  - 8304704: In getTotalThreadAllocatedBytes javadoc, 'launched' -> 'started'
>  - 8304704: Typos
>  - 8304074: fetch_then_add, not fetch_and_add
>  - 8304074: Assign to _add_long_func in add_long_bootstrap
>  - Merge branch 'master' into 8304074
>  - 8304074: Define FULL_MEM_BARRIER for linux_arm
>  - 8304074: set _atomic_add_long_entry = ShouldNotCallThisStub()
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/f5da892e...effdefc6

Changes requested by dholmes (Reviewer).

src/hotspot/share/services/threadService.hpp line 113:

> 111:     // No need for atomicity, method is called under the Threads_lock
> 112:     _exited_allocated_bytes += size;
> 113:   }

As there is a lock-free read however you need to use Atomic::load and Atomic::store - especially for 32-bit systems.

test/jdk/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java line 228:

> 226: 
> 227:         // start threads
> 228:         done = false; done1 = false;

Nit: separate lines please

-------------

PR Review: https://git.openjdk.org/jdk/pull/13814#pullrequestreview-1427697736
PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1194595159
PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1194595657

From cjplummer at openjdk.org  Tue May 16 05:53:46 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 16 May 2023 05:53:46 GMT
Subject: jmx-dev RFR: 8306806: JMX agent with JDP enabled won't start
 when PerfData is disabled [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 12 May 2023 09:15:47 GMT, Kevin Walls  wrote:

>> Java Discovery Protocol (perhaps a hidden feature, but maybe should be more widely known!) and -XX:-UsePerfData together cause a failure to startup.
>> 
>> PerfData is the mechanism for communicating the URL and other properties for remote management, so disabling PerfData clearly breaks this.  But there should be a clearer message, and not a fatal error.
>> 
>> e.g.
>> $ java -XX:-UsePerfData  -Dcom.sun.management.jmxremote.autodiscovery=true -Dcom.sun.management.jmxremote.port=0 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false --version
>> Warning: Exception thrown by the agent : JDP not starting, PerfData not available: Empty PerfData buffer
>> java 21-internal 2023-09-19 LTS
>> ...etc...
>> 
>> The use of PerfData is superior to the previous hard-coding of knowledge of the URL protocol and structure, and is required to communicate a dynamically assigned port (JDK-8167337).
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - undo (C)
>  - Handle BufferUndeflowException to leave IOException free for other failures

Looks good.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13928#pullrequestreview-1427767358

From kevinw at openjdk.org  Tue May 16 08:31:54 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 16 May 2023 08:31:54 GMT
Subject: jmx-dev RFR: 8306806: JMX agent with JDP enabled won't start
 when PerfData is disabled [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 12 May 2023 09:15:47 GMT, Kevin Walls  wrote:

>> Java Discovery Protocol (perhaps a hidden feature, but maybe should be more widely known!) and -XX:-UsePerfData together cause a failure to startup.
>> 
>> PerfData is the mechanism for communicating the URL and other properties for remote management, so disabling PerfData clearly breaks this.  But there should be a clearer message, and not a fatal error.
>> 
>> e.g.
>> $ java -XX:-UsePerfData  -Dcom.sun.management.jmxremote.autodiscovery=true -Dcom.sun.management.jmxremote.port=0 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false --version
>> Warning: Exception thrown by the agent : JDP not starting, PerfData not available: Empty PerfData buffer
>> java 21-internal 2023-09-19 LTS
>> ...etc...
>> 
>> The use of PerfData is superior to the previous hard-coding of knowledge of the URL protocol and structure, and is required to communicate a dynamically assigned port (JDK-8167337).
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - undo (C)
>  - Handle BufferUndeflowException to leave IOException free for other failures

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13928#issuecomment-1549224019

From kevinw at openjdk.org  Tue May 16 08:31:56 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 16 May 2023 08:31:56 GMT
Subject: jmx-dev Integrated: 8306806: JMX agent with JDP enabled won't start
 when PerfData is disabled
In-Reply-To: 
References: 
Message-ID: 

On Thu, 11 May 2023 11:42:38 GMT, Kevin Walls  wrote:

> Java Discovery Protocol (perhaps a hidden feature, but maybe should be more widely known!) and -XX:-UsePerfData together cause a failure to startup.
> 
> PerfData is the mechanism for communicating the URL and other properties for remote management, so disabling PerfData clearly breaks this.  But there should be a clearer message, and not a fatal error.
> 
> e.g.
> $ java -XX:-UsePerfData  -Dcom.sun.management.jmxremote.autodiscovery=true -Dcom.sun.management.jmxremote.port=0 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false --version
> Warning: Exception thrown by the agent : JDP not starting, PerfData not available: Empty PerfData buffer
> java 21-internal 2023-09-19 LTS
> ...etc...
> 
> The use of PerfData is superior to the previous hard-coding of knowledge of the URL protocol and structure, and is required to communicate a dynamically assigned port (JDK-8167337).

This pull request has now been integrated.

Changeset: 0790f704
Author:    Kevin Walls 
URL:       https://git.openjdk.org/jdk/commit/0790f704fdc82d8152219b280a51c8c1aad7a358
Stats:     13 lines in 1 file changed: 6 ins; 0 del; 7 mod

8306806: JMX agent with JDP enabled won't start when PerfData is disabled

Reviewed-by: dholmes, cjplummer

-------------

PR: https://git.openjdk.org/jdk/pull/13928

From asemenov at openjdk.org  Wed May 17 12:35:47 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Wed, 17 May 2023 12:35:47 GMT
Subject: jmx-dev RFR: 8308286 Fix clang warnings in linux code
Message-ID: 

When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
They can be fixed with small changes.

-------------

Commit messages:
 - 8308286 Fix clang warnings in linux code

Changes: https://git.openjdk.org/jdk/pull/14033/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308286
  Stats: 134 lines in 12 files changed: 126 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/14033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033

PR: https://git.openjdk.org/jdk/pull/14033

From phh at openjdk.org  Wed May 17 23:10:20 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 17 May 2023 23:10:20 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v20]
In-Reply-To: 
References: 
Message-ID: 

> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
> 
> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.

Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:

  8304074: incr_exited_allocated_bytes needs atomic load/store

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13814/files
  - new: https://git.openjdk.org/jdk/pull/13814/files/effdefc6..3c543e60

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=18-19

  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814

PR: https://git.openjdk.org/jdk/pull/13814

From phh at openjdk.org  Wed May 17 23:26:14 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 17 May 2023 23:26:14 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v21]
In-Reply-To: 
References: 
Message-ID: <1476hVhuUyOupiOIFpYwTsI7aoNxFdXSa1CblWjPGUc=.1b726e8c-ae78-49b2-bd60-7053022d145d@github.com>

> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
> 
> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.

Paul Hohensee 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 29 additional commits since the last revision:

 - 8304074: initialize done and done1 on separate lines
 - Merge branch 'master' into 8304074
 - 8304074: incr_exited_allocated_bytes needs atomic load/store
 - 8304704: _exited_allocated_bytes increment does not have to be atomic
 - Merge branch 'master' into 8304074
 - 8304704: _exited_allocated_bytes increment does not have to be atomic
 - 8304704: In getTotalThreadAllocatedBytes javadoc, 'launched' -> 'started'
 - 8304704: Typos
 - 8304074: fetch_then_add, not fetch_and_add
 - 8304074: Assign to _add_long_func in add_long_bootstrap
 - ... and 19 more: https://git.openjdk.org/jdk/compare/95e39e85...86be9237

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13814/files
  - new: https://git.openjdk.org/jdk/pull/13814/files/3c543e60..86be9237

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=19-20

  Stats: 7860 lines in 341 files changed: 4624 ins; 989 del; 2247 mod
  Patch: https://git.openjdk.org/jdk/pull/13814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814

PR: https://git.openjdk.org/jdk/pull/13814

From phh at openjdk.org  Thu May 18 12:45:03 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Thu, 18 May 2023 12:45:03 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v19]
In-Reply-To: <5aCwLaLKijz0hnfzEeRW1BSNhtv6bN_hIOGb0FcNX-g=.3c69db74-5838-486e-bfd6-7a2bd62c8ded@github.com>
References: 
 <0-pS2sIemk1XBwGFmEPOuw2IE7DCNhpRX4KK08DB3jY=.b8affc55-8666-4ff2-836c-d041ce03d95a@github.com>
 <5aCwLaLKijz0hnfzEeRW1BSNhtv6bN_hIOGb0FcNX-g=.3c69db74-5838-486e-bfd6-7a2bd62c8ded@github.com>
Message-ID: <3fWfpEV2MU5OcByjasEq3L0pC8Z5kS1_r0hO8jOWc04=.a2e500d9-ee66-4eab-99a0-b4a1d0ad622c@github.com>

On Tue, 16 May 2023 04:34:29 GMT, David Holmes  wrote:

>> Paul Hohensee 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 26 additional commits since the last revision:
>> 
>>  - 8304704: _exited_allocated_bytes increment does not have to be atomic
>>  - Merge branch 'master' into 8304074
>>  - 8304704: _exited_allocated_bytes increment does not have to be atomic
>>  - 8304704: In getTotalThreadAllocatedBytes javadoc, 'launched' -> 'started'
>>  - 8304704: Typos
>>  - 8304074: fetch_then_add, not fetch_and_add
>>  - 8304074: Assign to _add_long_func in add_long_bootstrap
>>  - Merge branch 'master' into 8304074
>>  - 8304074: Define FULL_MEM_BARRIER for linux_arm
>>  - 8304074: set _atomic_add_long_entry = ShouldNotCallThisStub()
>>  - ... and 16 more: https://git.openjdk.org/jdk/compare/1517b64a...effdefc6
>
> src/hotspot/share/services/threadService.hpp line 113:
> 
>> 111:     // No need for atomicity, method is called under the Threads_lock
>> 112:     _exited_allocated_bytes += size;
>> 113:   }
> 
> As there is a lock-free read however you need to use Atomic::load and Atomic::store - especially for 32-bit systems.

Changed. Not sure atomic load is needed.

> test/jdk/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java line 228:
> 
>> 226: 
>> 227:         // start threads
>> 228:         done = false; done1 = false;
> 
> Nit: separate lines please

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1197767814
PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1197767956

From phh at openjdk.org  Thu May 18 13:55:59 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Thu, 18 May 2023 13:55:59 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v22]
In-Reply-To: 
References: 
Message-ID: <415P54nMKZrJHjqEK2SheIjnOZqjO2JmgwnX_hwABgs=.4618d65a-a617-4bdf-b285-a955b8a96218@github.com>

> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
> 
> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.

Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:

  8304074: Need acquire/release in incr_exited_allocated_bytes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13814/files
  - new: https://git.openjdk.org/jdk/pull/13814/files/86be9237..7d8252ff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=20-21

  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814

PR: https://git.openjdk.org/jdk/pull/13814

From phh at openjdk.org  Thu May 18 13:58:58 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Thu, 18 May 2023 13:58:58 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v19]
In-Reply-To: <3fWfpEV2MU5OcByjasEq3L0pC8Z5kS1_r0hO8jOWc04=.a2e500d9-ee66-4eab-99a0-b4a1d0ad622c@github.com>
References: 
 <0-pS2sIemk1XBwGFmEPOuw2IE7DCNhpRX4KK08DB3jY=.b8affc55-8666-4ff2-836c-d041ce03d95a@github.com>
 <5aCwLaLKijz0hnfzEeRW1BSNhtv6bN_hIOGb0FcNX-g=.3c69db74-5838-486e-bfd6-7a2bd62c8ded@github.com>
 <3fWfpEV2MU5OcByjasEq3L0pC8Z5kS1_r0hO8jOWc04=.a2e500d9-ee66-4eab-99a0-b4a1d0ad622c@github.com>
Message-ID: 

On Thu, 18 May 2023 12:41:49 GMT, Paul Hohensee  wrote:

>> src/hotspot/share/services/threadService.hpp line 113:
>> 
>>> 111:     // No need for atomicity, method is called under the Threads_lock
>>> 112:     _exited_allocated_bytes += size;
>>> 113:   }
>> 
>> As there is a lock-free read however you need to use Atomic::load and Atomic::store - especially for 32-bit systems.
>
> Changed. Not sure atomic load is needed.

Even though this version passed the pre-submit tests, which include the new versions of ThreadAllocatedBytes.java, running it more often on a host with many hardware threads resulted in failures where getTotalAllocatedBytes did not monotonically increase. I believe what happened was that without an acquire/release, the hardware can float earlier stores to _exited_allocated_bytes above later ones. Adding acquire/release fixed the issue.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1197862479

From dholmes at openjdk.org  Fri May 19 02:51:56 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 May 2023 02:51:56 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v19]
In-Reply-To: 
References: 
 <0-pS2sIemk1XBwGFmEPOuw2IE7DCNhpRX4KK08DB3jY=.b8affc55-8666-4ff2-836c-d041ce03d95a@github.com>
 <5aCwLaLKijz0hnfzEeRW1BSNhtv6bN_hIOGb0FcNX-g=.3c69db74-5838-486e-bfd6-7a2bd62c8ded@github.com>
 <3fWfpEV2MU5OcByjasEq3L0pC8Z5kS1_r0hO8jOWc04=.a2e500d9-ee66-4eab-99a0-b4a1d0ad622c@github.com>
 
Message-ID: 

On Thu, 18 May 2023 13:56:06 GMT, Paul Hohensee  wrote:

>> Changed. Not sure atomic load is needed.
>
> Even though this version passed the pre-submit tests, which include the new versions of ThreadAllocatedBytes.java, running it more often on a host with many hardware threads resulted in failures where getTotalAllocatedBytes did not monotonically increase. I believe what happened was that without an acquire/release, the hardware can float earlier stores to _exited_allocated_bytes above later ones. Adding acquire/release fixed the issue.

That should not be possible if the update is always under the lock. acquire/release control what other memory updates you see when you see "this" update - they have no affect on the update itself.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1198492860

From dholmes at openjdk.org  Fri May 19 03:12:00 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 May 2023 03:12:00 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v22]
In-Reply-To: <415P54nMKZrJHjqEK2SheIjnOZqjO2JmgwnX_hwABgs=.4618d65a-a617-4bdf-b285-a955b8a96218@github.com>
References: 
 <415P54nMKZrJHjqEK2SheIjnOZqjO2JmgwnX_hwABgs=.4618d65a-a617-4bdf-b285-a955b8a96218@github.com>
Message-ID: 

On Thu, 18 May 2023 13:55:59 GMT, Paul Hohensee  wrote:

>> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
>> 
>> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.
>
> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8304074: Need acquire/release in incr_exited_allocated_bytes

Changes requested by dholmes (Reviewer).

src/hotspot/share/services/threadService.hpp line 109:

> 107:   static jlong get_daemon_thread_count()      { return _atomic_daemon_threads_count; }
> 108: 
> 109:   static jlong exited_allocated_bytes()       { return _exited_allocated_bytes; }

This needs to be an atomic::load too .

src/hotspot/share/services/threadService.hpp line 117:

> 115:     // store to _exited_allocated_bytes above this one.
> 116:     jlong old = Atomic::load_acquire(&_exited_allocated_bytes);
> 117:     Atomic::release_store(&_exited_allocated_bytes, old + size);

First yes Atomic::load is not needed here due to the lock, it is needed in the accessor above - sorry that wasn't clear. The Atomic store is needed of course.

But the load_acquire is definitely not needed as there is an implicit acquire when the lock is acquired, so any load of the field here must see the last value written under the lock. The release_store is also not needed because a release is for ensuring visibility of previous stores of which there are none, and has no affect on the visibility of the store done by the `release_store`.

So lets imagine a really weakly-ordered piece of hardware where all of the writing threads are completely properly synchronized by the use of the lock (else the hw is broken), but a lock-free reader can potentially see any of those writes out-of-order.  I think the only way to guarantee seeing the most recent write would be to issue a full fence() before the load. But I would be very surprised if any of our hardware actually operates in such a fashion.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13814#pullrequestreview-1433711869
PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1198498123
PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1198500354

From phh at openjdk.org  Fri May 19 13:54:13 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 19 May 2023 13:54:13 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v23]
In-Reply-To: 
References: 
Message-ID: 

> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
> 
> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.

Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:

  8304074: atomic load needed in exited_allocated_bytes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13814/files
  - new: https://git.openjdk.org/jdk/pull/13814/files/7d8252ff..7ee35da0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=21-22

  Stats: 6 lines in 1 file changed: 0 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814

PR: https://git.openjdk.org/jdk/pull/13814

From phh at openjdk.org  Fri May 19 13:56:57 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 19 May 2023 13:56:57 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v22]
In-Reply-To: 
References: 
 <415P54nMKZrJHjqEK2SheIjnOZqjO2JmgwnX_hwABgs=.4618d65a-a617-4bdf-b285-a955b8a96218@github.com>
 
Message-ID: 

On Fri, 19 May 2023 03:08:40 GMT, David Holmes  wrote:

>> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8304074: Need acquire/release in incr_exited_allocated_bytes
>
> src/hotspot/share/services/threadService.hpp line 117:
> 
>> 115:     // store to _exited_allocated_bytes above this one.
>> 116:     jlong old = Atomic::load_acquire(&_exited_allocated_bytes);
>> 117:     Atomic::release_store(&_exited_allocated_bytes, old + size);
> 
> First yes Atomic::load is not needed here due to the lock, it is needed in the accessor above - sorry that wasn't clear. The Atomic store is needed of course.
> 
> But the load_acquire is definitely not needed as there is an implicit acquire when the lock is acquired, so any load of the field here must see the last value written under the lock. The release_store is also not needed because a release is for ensuring visibility of previous stores of which there are none, and has no affect on the visibility of the store done by the `release_store`.
> 
> So lets imagine a really weakly-ordered piece of hardware where all of the writing threads are completely properly synchronized by the use of the lock (else the hw is broken), but a lock-free reader can potentially see any of those writes out-of-order.  I think the only way to guarantee seeing the most recent write would be to issue a full fence() before the load. But I would be very surprised if any of our hardware actually operates in such a fashion.

Thanks for the explanation. I reverted the acquire/release and the atomic load in incr_exited_allocated_bytes and added an atomic load in exited_allocated_bytes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1198986781

From phh at openjdk.org  Sat May 20 19:37:56 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Sat, 20 May 2023 19:37:56 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v22]
In-Reply-To: 
References: 
 <415P54nMKZrJHjqEK2SheIjnOZqjO2JmgwnX_hwABgs=.4618d65a-a617-4bdf-b285-a955b8a96218@github.com>
 
Message-ID: 

On Fri, 19 May 2023 03:02:33 GMT, David Holmes  wrote:

>> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8304074: Need acquire/release in incr_exited_allocated_bytes
>
> src/hotspot/share/services/threadService.hpp line 109:
> 
>> 107:   static jlong get_daemon_thread_count()      { return _atomic_daemon_threads_count; }
>> 108: 
>> 109:   static jlong exited_allocated_bytes()       { return _exited_allocated_bytes; }
> 
> This needs to be an atomic::load too .

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1199651489

From dholmes at openjdk.org  Mon May 22 05:17:56 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 22 May 2023 05:17:56 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v23]
In-Reply-To: 
References: 
 
Message-ID: <5WdmpwEo2rFAWWbUZI10bSkPlV-RKbUko6EZXfSnmEE=.d85febe5-cd9a-4c30-8b7d-7a8963611859@github.com>

On Fri, 19 May 2023 13:54:13 GMT, Paul Hohensee  wrote:

>> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
>> 
>> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.
>
> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8304074: atomic load needed in exited_allocated_bytes

Updates look good - thanks.

But presumably you still have those test failures now the acquire/release has been removed again?

-------------

PR Review: https://git.openjdk.org/jdk/pull/13814#pullrequestreview-1435783906

From avu at openjdk.org  Mon May 22 14:21:56 2023
From: avu at openjdk.org (Alexey Ushakov)
Date: Mon, 22 May 2023 14:21:56 GMT
Subject: jmx-dev RFR: 8308286 Fix clang warnings in linux code
In-Reply-To: 
References: 
Message-ID: 

On Wed, 17 May 2023 12:28:47 GMT, Artem Semenov  wrote:

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

I would suggest either disable warnings on per file basis or rewrite problematic code.  Disabling warnings per fragment of code makes it less readable.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14033#issuecomment-1557306893

From phh at openjdk.org  Mon May 22 15:52:00 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Mon, 22 May 2023 15:52:00 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v23]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 19 May 2023 13:54:13 GMT, Paul Hohensee  wrote:

>> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
>> 
>> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.
>
> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8304074: atomic load needed in exited_allocated_bytes

Nope, test failures went away with the latest revision. I'm at a loss on that one. Perhaps it was the atomic load.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13814#issuecomment-1557466320

From prr at openjdk.org  Mon May 22 18:04:51 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 22 May 2023 18:04:51 GMT
Subject: jmx-dev RFR: 8308286 Fix clang warnings in linux code
In-Reply-To: 
References: 
Message-ID: 

On Wed, 17 May 2023 12:28:47 GMT, Artem Semenov  wrote:

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

I don't like this approach at all. if github had a "reject" button I'd be pushing it now.
updating the makefiles is the normal way to do this but I don't know if we even want that.
Until clang is the supported compiler for Linux then I see no reason for this to be in JDK at all.

Code changes which make it so there's no warning would be the preferred way but I'd expect that to be tested properly. Also if the warning is spurious - sometimes they are - then that would NOT be appropriate.

-------------

Changes requested by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14033#pullrequestreview-1437172390

From dholmes at openjdk.org  Mon May 22 22:27:05 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 22 May 2023 22:27:05 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v23]
In-Reply-To: 
References: 
 
Message-ID: <1Snade6Vek_2dKtIp8SJy6A_tldjD3FJQeDydVHZtyI=.5b272f25-038f-48e4-b04c-c122416aa737@github.com>

On Fri, 19 May 2023 13:54:13 GMT, Paul Hohensee  wrote:

>> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
>> 
>> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.
>
> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8304074: atomic load needed in exited_allocated_bytes

I'm happy with the basic implementation of this now - thanks. I'll leave any issues about spec and JMM version for serviceability folk to approve.

I will click Approve to get rid of the "requested changes" indicator but please wait for serviceability reviews.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13814#pullrequestreview-1437782921
Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13814#pullrequestreview-1437784313

From dholmes at openjdk.org  Tue May 23 02:24:04 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 23 May 2023 02:24:04 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v23]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 19 May 2023 13:54:13 GMT, Paul Hohensee  wrote:

>> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
>> 
>> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.
>
> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8304074: atomic load needed in exited_allocated_bytes

Sorry I ran this through our CI and I see the test fail on macos-x64:

Done sleeping
AgentVMThread Previous allocated bytes = 66897992 Current allocated bytes = 81305216
AgentVMThread Previous allocated bytes = 81305216 Current allocated bytes = 78425048
----------System.err:(12/778)----------
java.lang.RuntimeException: TEST FAILED: AgentVMThread previous allocated bytes = 81305216 > current allocated bytes = 78425048
	at ThreadAllocatedMemory.checkResult(ThreadAllocatedMemory.java:296)
	at ThreadAllocatedMemory.testGetTotalThreadAllocatedBytes(ThreadAllocatedMemory.java:276)
	at ThreadAllocatedMemory.main(ThreadAllocatedMemory.java:59)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1583)

Not sure if the issue is the test or the implementation.

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13814#pullrequestreview-1438159195

From dholmes at openjdk.org  Tue May 23 02:31:58 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 23 May 2023 02:31:58 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v23]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 19 May 2023 13:54:13 GMT, Paul Hohensee  wrote:

>> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
>> 
>> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.
>
> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8304074: atomic load needed in exited_allocated_bytes

src/hotspot/share/services/management.cpp line 2104:

> 2102:     // the final result can only be short due to (1) threads that start after
> 2103:     // the TLH is created, or (2) terminating threads that escape TLH creation
> 2104:     // and don't update exited_allocated_bytes before we initialize result.

Okay this is why you can't do monotonicity check in the tests. Imagine we have 10 threads all live and we call this function and so tally up all 10 threads. The next time we call this 5 of the threads are in the process of terminating - they have escaped the TLH but not yet updated the exited_allocated_bytes - so now we only tally up 5 threads and so the total appears to be far less than last time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1201428147

From mchung at openjdk.org  Tue May 23 18:29:05 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 23 May 2023 18:29:05 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v23]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 19 May 2023 13:54:13 GMT, Paul Hohensee  wrote:

>> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
>> 
>> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.
>
> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8304074: atomic load needed in exited_allocated_bytes

The specification looks good.   A minor comment in the test.

src/jdk.management/share/classes/com/sun/management/ThreadMXBean.java line 116:

> 114:      * recorded.
> 115:      *
> 116:      * @implSpec The default implementation throws UnsupportedOperationException

Suggestion:

     * @implSpec The default implementation throws {@code UnsupportedOperationException}

test/jdk/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java line 160:

> 158:         try {
> 159:             curThread.join();
> 160:         } catch (InterruptedException e) {

should it just let `InterruptedException` be thrown rather than swallowing it?  This pattern appears multiple places in this test and ThreadAllocatedMemoryArray.java test.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13814#pullrequestreview-1440326691
PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1202819575
PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1202824396

From kevinw at openjdk.org  Wed May 24 11:24:03 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 24 May 2023 11:24:03 GMT
Subject: jmx-dev RFR: 8299665: /proc/self/stat parsing in libmanagement
 broken by execname with spaces
Message-ID: 

Code that parses /proc/self/stat may be broken if the executable name contains spaces.

We have code that does this correctly, and code that does not.
UnixOperatingSystem.c is Linux-specific OS code, and has vread_statdata which correctly uses strrchr to find the last ) and parses from there.

OperatingSystemImpl.c the generic, not Linux-specific code, is not OK, as Java_com_sun_management_internal_OperatingSystemImpl_getCommittedVirtualMemorySize0 has a problematic fscanf call. 
But the problematic fscanf call is Linux-specific: we use ifdef to create OS-specific implementations.


Need to change the fscanf of /proc/self/stat to do the same buffered read as read_ticks in UnixOperatingSystem.c (the Linux-specific code), with strrchr to read past the ) of the execname.

Moving the actually-Linux-specific getCommittedVirtualMemorySize0 to be with the other Linux-specific code means it can just use the existing method for accessing /proc/self/stat.

It does however call throw_internal_error, which is then not accessible.  So that function can be shared in the libmanagement_ext.h/.c for both uses.

The call to throw_internal_error is working: if I change the code to fail, it reports a java.lang.InternalError as it would before.

Existing tests still pass: 
i.e. test/jdk/com/sun/management/OperatingSystemMXBean/GetCommittedVirtualMemorySize.java

-------------

Commit messages:
 - unnecessary include after moving funtion
 - whitespace
 - move 'throw_internal_error' plus whitespace comment fix
 - 8299665: /proc/self/stat parsing in libmanagement broken by execname with spaces

Changes: https://git.openjdk.org/jdk/pull/14107/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14107&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299665
  Stats: 61 lines in 4 files changed: 34 ins; 25 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14107.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14107/head:pull/14107

PR: https://git.openjdk.org/jdk/pull/14107

From phh at openjdk.org  Wed May 24 14:40:22 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 24 May 2023 14:40:22 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v23]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 23 May 2023 18:21:18 GMT, Mandy Chung  wrote:

>> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8304074: atomic load needed in exited_allocated_bytes
>
> src/jdk.management/share/classes/com/sun/management/ThreadMXBean.java line 116:
> 
>> 114:      * recorded.
>> 115:      *
>> 116:      * @implSpec The default implementation throws UnsupportedOperationException
> 
> Suggestion:
> 
>      * @implSpec The default implementation throws {@code UnsupportedOperationException}

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1204267595

From phh at openjdk.org  Wed May 24 14:40:21 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 24 May 2023 14:40:21 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v24]
In-Reply-To: 
References: 
Message-ID: 

> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
> 
> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.

Paul Hohensee has updated the pull request incrementally with 63 additional commits since the last revision:

 - 8304074: Change UnsupportedOperationException in javadoc comment to {@code UnsupportedOperationException}
 - 8306507: [linux] Print number of memory mappings in error reports
   
   Reviewed-by: adinn, sgehwolf
 - 8300086: Replace NULL with nullptr in share/c1/
   
   Reviewed-by: thartmann, chagedorn
 - 8308465: Reduce memory accesses in AArch64 MD5 intrinsic
   
   Reviewed-by: aph, phh
 - 8302218: CHeapBitMap::free frees with incorrect size
   
   Reviewed-by: aboldtch, iklam, tschatzl
 - 8308388: Update description of SourceVersion.RELEASE_21
   
   Reviewed-by: iris
 - 8307190: Refactor ref_at methods in Constant Pool
   
   Reviewed-by: coleenp, iklam
 - 8308458: Windows build failure with disassembler.cpp(792): warning C4267: '=': conversion from 'size_t' to 'int'
   
   Reviewed-by: jiefu
 - 8308034: Some CDS tests need to use @requires vm.flagless
   
   Reviewed-by: iklam
 - 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal
   
   Reviewed-by: erikj
 - ... and 53 more: https://git.openjdk.org/jdk/compare/7ee35da0...638756de

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13814/files
  - new: https://git.openjdk.org/jdk/pull/13814/files/7ee35da0..638756de

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=22-23

  Stats: 22538 lines in 726 files changed: 12148 ins; 6106 del; 4284 mod
  Patch: https://git.openjdk.org/jdk/pull/13814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814

PR: https://git.openjdk.org/jdk/pull/13814

From kevinw at openjdk.org  Wed May 24 15:49:11 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 24 May 2023 15:49:11 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v24]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 24 May 2023 14:40:21 GMT, Paul Hohensee  wrote:

>> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
>> 
>> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.
>
> Paul Hohensee has updated the pull request incrementally with 63 additional commits since the last revision:
> 
>  - 8304074: Change UnsupportedOperationException in javadoc comment to {@code UnsupportedOperationException}
>  - 8306507: [linux] Print number of memory mappings in error reports
>    
>    Reviewed-by: adinn, sgehwolf
>  - 8300086: Replace NULL with nullptr in share/c1/
>    
>    Reviewed-by: thartmann, chagedorn
>  - 8308465: Reduce memory accesses in AArch64 MD5 intrinsic
>    
>    Reviewed-by: aph, phh
>  - 8302218: CHeapBitMap::free frees with incorrect size
>    
>    Reviewed-by: aboldtch, iklam, tschatzl
>  - 8308388: Update description of SourceVersion.RELEASE_21
>    
>    Reviewed-by: iris
>  - 8307190: Refactor ref_at methods in Constant Pool
>    
>    Reviewed-by: coleenp, iklam
>  - 8308458: Windows build failure with disassembler.cpp(792): warning C4267: '=': conversion from 'size_t' to 'int'
>    
>    Reviewed-by: jiefu
>  - 8308034: Some CDS tests need to use @requires vm.flagless
>    
>    Reviewed-by: iklam
>  - 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal
>    
>    Reviewed-by: erikj
>  - ... and 53 more: https://git.openjdk.org/jdk/compare/7ee35da0...638756de

This review now contains a lot of other changes: Files changed 725 
Hopefully they all get squashed appropriately?  But other changes already integrated don't normally show up here as part of the review, or in the generated webrevs.  I looked at an earlier webrev and thought it looked good, but now it's hard to see the actual changes... 8-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13814#issuecomment-1561419991

From phh at openjdk.org  Wed May 24 16:39:07 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 24 May 2023 16:39:07 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v24]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 24 May 2023 14:40:21 GMT, Paul Hohensee  wrote:

>> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
>> 
>> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.
>
> Paul Hohensee has updated the pull request incrementally with 63 additional commits since the last revision:
> 
>  - 8304074: Change UnsupportedOperationException in javadoc comment to {@code UnsupportedOperationException}
>  - 8306507: [linux] Print number of memory mappings in error reports
>    
>    Reviewed-by: adinn, sgehwolf
>  - 8300086: Replace NULL with nullptr in share/c1/
>    
>    Reviewed-by: thartmann, chagedorn
>  - 8308465: Reduce memory accesses in AArch64 MD5 intrinsic
>    
>    Reviewed-by: aph, phh
>  - 8302218: CHeapBitMap::free frees with incorrect size
>    
>    Reviewed-by: aboldtch, iklam, tschatzl
>  - 8308388: Update description of SourceVersion.RELEASE_21
>    
>    Reviewed-by: iris
>  - 8307190: Refactor ref_at methods in Constant Pool
>    
>    Reviewed-by: coleenp, iklam
>  - 8308458: Windows build failure with disassembler.cpp(792): warning C4267: '=': conversion from 'size_t' to 'int'
>    
>    Reviewed-by: jiefu
>  - 8308034: Some CDS tests need to use @requires vm.flagless
>    
>    Reviewed-by: iklam
>  - 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal
>    
>    Reviewed-by: erikj
>  - ... and 53 more: https://git.openjdk.org/jdk/compare/7ee35da0...638756de

Yes, it seems to have happened when I did a merge of this branch with jdk master, which latter must have been in a strange state. Unfortunately, git merge didn't complain at all, so I didn't check before pushing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13814#issuecomment-1561553206

From phh at openjdk.org  Wed May 24 16:47:51 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 24 May 2023 16:47:51 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v25]
In-Reply-To: 
References: 
Message-ID: 

> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
> 
> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.

Paul Hohensee 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 95 additional commits since the last revision:

 - Merge master
 - 8304074: Change UnsupportedOperationException in javadoc comment to {@code UnsupportedOperationException}
 - 8306507: [linux] Print number of memory mappings in error reports
   
   Reviewed-by: adinn, sgehwolf
 - 8300086: Replace NULL with nullptr in share/c1/
   
   Reviewed-by: thartmann, chagedorn
 - 8308465: Reduce memory accesses in AArch64 MD5 intrinsic
   
   Reviewed-by: aph, phh
 - 8302218: CHeapBitMap::free frees with incorrect size
   
   Reviewed-by: aboldtch, iklam, tschatzl
 - 8308388: Update description of SourceVersion.RELEASE_21
   
   Reviewed-by: iris
 - 8307190: Refactor ref_at methods in Constant Pool
   
   Reviewed-by: coleenp, iklam
 - 8308458: Windows build failure with disassembler.cpp(792): warning C4267: '=': conversion from 'size_t' to 'int'
   
   Reviewed-by: jiefu
 - 8308034: Some CDS tests need to use @requires vm.flagless
   
   Reviewed-by: iklam
 - ... and 85 more: https://git.openjdk.org/jdk/compare/20185d2c...7b90091b

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13814/files
  - new: https://git.openjdk.org/jdk/pull/13814/files/638756de..7b90091b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=23-24

  Stats: 10880 lines in 222 files changed: 7954 ins; 1723 del; 1203 mod
  Patch: https://git.openjdk.org/jdk/pull/13814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814

PR: https://git.openjdk.org/jdk/pull/13814

From phh at openjdk.org  Wed May 24 16:50:55 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 24 May 2023 16:50:55 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v26]
In-Reply-To: 
References: 
Message-ID: 

> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
> 
> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.

Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:

  Merge master

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13814/files
  - new: https://git.openjdk.org/jdk/pull/13814/files/7b90091b..96cb0e5b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=24-25

  Stats: 17 lines in 1 file changed: 0 ins; 16 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814

PR: https://git.openjdk.org/jdk/pull/13814

From phh at openjdk.org  Wed May 24 16:54:11 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 24 May 2023 16:54:11 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v23]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 23 May 2023 18:25:26 GMT, Mandy Chung  wrote:

>> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8304074: atomic load needed in exited_allocated_bytes
>
> test/jdk/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java line 160:
> 
>> 158:         try {
>> 159:             curThread.join();
>> 160:         } catch (InterruptedException e) {
> 
> should it just let `InterruptedException` be thrown rather than swallowing it?  This pattern appears multiple places in this test and ThreadAllocatedMemoryArray.java test.

The original implementation grabbed this code from, e.g., test/jdk/java/lang/management/ThreadMXBean/ThreadUserTime.java. In the latter, InterruptedException causes the test to fail, but for some reason now lost, ThreadAllocatedMemory.java doesn't do that, but ThreadAllocatedMemoryArray.java does.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1204504529

From sspitsyn at openjdk.org  Wed May 24 20:06:59 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 24 May 2023 20:06:59 GMT
Subject: jmx-dev RFR: 8299665: /proc/self/stat parsing in libmanagement
 broken by execname with spaces
In-Reply-To: 
References: 
Message-ID: 

On Tue, 23 May 2023 20:54:42 GMT, Kevin Walls  wrote:

> Code that parses /proc/self/stat may be broken if the executable name contains spaces.
> 
> We have code that does this correctly, and code that does not.
> UnixOperatingSystem.c is Linux-specific OS code, and has vread_statdata which correctly uses strrchr to find the last ) and parses from there.
> 
> OperatingSystemImpl.c the generic, not Linux-specific code, is not OK, as Java_com_sun_management_internal_OperatingSystemImpl_getCommittedVirtualMemorySize0 has a problematic fscanf call. 
> But the problematic fscanf call is Linux-specific: we use ifdef to create OS-specific implementations.
> 
> 
> Need to change the fscanf of /proc/self/stat to do the same buffered read as read_ticks in UnixOperatingSystem.c (the Linux-specific code), with strrchr to read past the ) of the execname.
> 
> Moving the actually-Linux-specific getCommittedVirtualMemorySize0 to be with the other Linux-specific code means it can just use the existing method for accessing /proc/self/stat.
> 
> It does however call throw_internal_error, which is then not accessible.  So that function can be shared in the libmanagement_ext.h/.c for both uses.
> 
> The call to throw_internal_error is working: if I change the code to fail, it reports a java.lang.InternalError as it would before.
> 
> Existing tests still pass: 
> i.e. test/jdk/com/sun/management/OperatingSystemMXBean/GetCommittedVirtualMemorySize.java

How do you test the issue is fixed now?
Is there any test case which fails without your fix and passes with it?

-------------

PR Review: https://git.openjdk.org/jdk/pull/14107#pullrequestreview-1442667424

From kevinw at openjdk.org  Wed May 24 20:39:54 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 24 May 2023 20:39:54 GMT
Subject: jmx-dev RFR: 8299665: /proc/self/stat parsing in libmanagement
 broken by execname with spaces
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 24 May 2023 20:03:47 GMT, Serguei Spitsyn  wrote:

> How do you test the issue is fixed now? Is there any test case which fails without your fix and passes with it?

Hi - I tested manually, renaming the java executable to something with a space, then query the OperatingSystem MBean, and see something like: CommittedVirtualMemorySize = (java.lang.Long) 36202319872 (which is the same/similar to another run 
when not renamed).  The problem is seeing a completely wrong value, like: CommittedVirtualMemorySize = (java.lang.Long) 0 

These are lines like:

$ cat /proc/9496/stat                                                                 
9496 (java) S 625 9495 607 34823 9635 1077936192 12024 0 0 0 156 22 0 0 20 0 28 0 2172294643 36260237312 30463 18446744073709551615 93928094162944 93928094166632 140724289571696 0 0 0 4 0 16800975 0 0 0 -1 11 0 0 0 0 0 93928094174456 93928094175248 93928124657664 140724289577708 140724289577894 140724289577894 140724289581032 0

That's a different run, where 36260237312 was the value we wanted.  If "java" becomes "this is java"  (with 2 spaces), then we read field 21, not field 23 from the line of data and show zero.  

It's quite a niche thing to do so I didn't add a test that copied the java binary under test to a new name with a space in it...
The code that does the strrchr to scan from the last ) and then parses the remainder has been with us for some time. 8-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14107#issuecomment-1561893976

From sspitsyn at openjdk.org  Wed May 24 23:51:57 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 24 May 2023 23:51:57 GMT
Subject: jmx-dev RFR: 8299665: /proc/self/stat parsing in libmanagement
 broken by execname with spaces
In-Reply-To: 
References: 
Message-ID: 

On Tue, 23 May 2023 20:54:42 GMT, Kevin Walls  wrote:

> Code that parses /proc/self/stat may be broken if the executable name contains spaces.
> 
> We have code that does this correctly, and code that does not.
> UnixOperatingSystem.c is Linux-specific OS code, and has vread_statdata which correctly uses strrchr to find the last ) and parses from there.
> 
> OperatingSystemImpl.c the generic, not Linux-specific code, is not OK, as Java_com_sun_management_internal_OperatingSystemImpl_getCommittedVirtualMemorySize0 has a problematic fscanf call. 
> But the problematic fscanf call is Linux-specific: we use ifdef to create OS-specific implementations.
> 
> 
> Need to change the fscanf of /proc/self/stat to do the same buffered read as read_ticks in UnixOperatingSystem.c (the Linux-specific code), with strrchr to read past the ) of the execname.
> 
> Moving the actually-Linux-specific getCommittedVirtualMemorySize0 to be with the other Linux-specific code means it can just use the existing method for accessing /proc/self/stat.
> 
> It does however call throw_internal_error, which is then not accessible.  So that function can be shared in the libmanagement_ext.h/.c for both uses.
> 
> The call to throw_internal_error is working: if I change the code to fail, it reports a java.lang.InternalError as it would before.
> 
> Existing tests still pass: 
> i.e. test/jdk/com/sun/management/OperatingSystemMXBean/GetCommittedVirtualMemorySize.java

Marked as reviewed by sspitsyn (Reviewer).

Thank you for explanation! Looks good.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14107#pullrequestreview-1442894643
PR Comment: https://git.openjdk.org/jdk/pull/14107#issuecomment-1562068308

From amenkov at openjdk.org  Thu May 25 01:06:07 2023
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 25 May 2023 01:06:07 GMT
Subject: jmx-dev RFR: 8299665: /proc/self/stat parsing in libmanagement
 broken by execname with spaces
In-Reply-To: 
References: 
Message-ID: 

On Tue, 23 May 2023 20:54:42 GMT, Kevin Walls  wrote:

> Code that parses /proc/self/stat may be broken if the executable name contains spaces.
> 
> We have code that does this correctly, and code that does not.
> UnixOperatingSystem.c is Linux-specific OS code, and has vread_statdata which correctly uses strrchr to find the last ) and parses from there.
> 
> OperatingSystemImpl.c the generic, not Linux-specific code, is not OK, as Java_com_sun_management_internal_OperatingSystemImpl_getCommittedVirtualMemorySize0 has a problematic fscanf call. 
> But the problematic fscanf call is Linux-specific: we use ifdef to create OS-specific implementations.
> 
> 
> Need to change the fscanf of /proc/self/stat to do the same buffered read as read_ticks in UnixOperatingSystem.c (the Linux-specific code), with strrchr to read past the ) of the execname.
> 
> Moving the actually-Linux-specific getCommittedVirtualMemorySize0 to be with the other Linux-specific code means it can just use the existing method for accessing /proc/self/stat.
> 
> It does however call throw_internal_error, which is then not accessible.  So that function can be shared in the libmanagement_ext.h/.c for both uses.
> 
> The call to throw_internal_error is working: if I change the code to fail, it reports a java.lang.InternalError as it would before.
> 
> Existing tests still pass: 
> i.e. test/jdk/com/sun/management/OperatingSystemMXBean/GetCommittedVirtualMemorySize.java

Marked as reviewed by amenkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14107#pullrequestreview-1442935250

From dholmes at openjdk.org  Thu May 25 07:11:06 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 25 May 2023 07:11:06 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v24]
In-Reply-To: 
References: 
 
 
Message-ID: <4esLZpXX8n4LjjJZR136noVLgcPZOhRGJNU5tkhVcrs=.158f3918-3160-4905-ae21-40c2f198d4ee@github.com>

On Wed, 24 May 2023 16:36:05 GMT, Paul Hohensee  wrote:

>> Paul Hohensee has updated the pull request incrementally with 63 additional commits since the last revision:
>> 
>>  - 8304074: Change UnsupportedOperationException in javadoc comment to {@code UnsupportedOperationException}
>>  - 8306507: [linux] Print number of memory mappings in error reports
>>    
>>    Reviewed-by: adinn, sgehwolf
>>  - 8300086: Replace NULL with nullptr in share/c1/
>>    
>>    Reviewed-by: thartmann, chagedorn
>>  - 8308465: Reduce memory accesses in AArch64 MD5 intrinsic
>>    
>>    Reviewed-by: aph, phh
>>  - 8302218: CHeapBitMap::free frees with incorrect size
>>    
>>    Reviewed-by: aboldtch, iklam, tschatzl
>>  - 8308388: Update description of SourceVersion.RELEASE_21
>>    
>>    Reviewed-by: iris
>>  - 8307190: Refactor ref_at methods in Constant Pool
>>    
>>    Reviewed-by: coleenp, iklam
>>  - 8308458: Windows build failure with disassembler.cpp(792): warning C4267: '=': conversion from 'size_t' to 'int'
>>    
>>    Reviewed-by: jiefu
>>  - 8308034: Some CDS tests need to use @requires vm.flagless
>>    
>>    Reviewed-by: iklam
>>  - 8307573: Implementation of JEP 449: Deprecate the Windows 32-bit x86 Port for Removal
>>    
>>    Reviewed-by: erikj
>>  - ... and 53 more: https://git.openjdk.org/jdk/compare/7ee35da0...638756de
>
> Yes, it seems to have happened when I did a merge of this branch with jdk master, which latter must have been in a strange state. Unfortunately, git merge didn't complain at all, so I didn't check before pushing.

@phohensee not clear if you saw my comment a couple of days ago about why the monotonic increasing check in the test can't work.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13814#issuecomment-1562390740

From kevinw at openjdk.org  Thu May 25 09:04:13 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 25 May 2023 09:04:13 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v23]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 23 May 2023 02:29:19 GMT, David Holmes  wrote:

>> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8304074: atomic load needed in exited_allocated_bytes
>
> src/hotspot/share/services/management.cpp line 2104:
> 
>> 2102:     // the final result can only be short due to (1) threads that start after
>> 2103:     // the TLH is created, or (2) terminating threads that escape TLH creation
>> 2104:     // and don't update exited_allocated_bytes before we initialize result.
> 
> Okay this is why you can't do monotonicity check in the tests. Imagine we have 10 threads all live and we call this function and so tally up all 10 threads. The next time we call this 5 of the threads are in the process of terminating - they have escaped the TLH but not yet updated the exited_allocated_bytes - so now we only tally up 5 threads and so the total appears to be far less than last time.

The tests and all apps might thank us for keeping last known value, and not returning anything lower, ensuring montonicity.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1205215878

From phh at openjdk.org  Thu May 25 14:15:12 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Thu, 25 May 2023 14:15:12 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v26]
In-Reply-To: 
References: 
 
Message-ID: <5m0O7Ph618tXmtdvInAIXSTs3XfzD7Yj1YcfPIoeX_M=.297d5318-6235-4201-a7f3-35e5a7b5cd70@github.com>

On Wed, 24 May 2023 16:50:55 GMT, Paul Hohensee  wrote:

>> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
>> 
>> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.
>
> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge master

Yes, I saw your comment and have been thinking about how to fix it, but haven't come up with anything. Ramki (ysr) pointed out that walking the thread list using SMR is very expensive when there are 1000s of threads, and that there isn't much overhead to collecting per-thread statistics: a thread local counter is incremented when TLABs are retired or there are direct allocations of large objects in eden or the old gen. So, he suggested adding an atomic increment of a global counter whenever a thread local counter is incremented. Atomic operations have been completing in the LLC (i.e., on-chip) for some time now, so the overhead is pretty small. What do you think, shall I reimplement that way?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13814#issuecomment-1562983030

From mchung at openjdk.org  Thu May 25 16:42:06 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 25 May 2023 16:42:06 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v23]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 24 May 2023 16:50:59 GMT, Paul Hohensee  wrote:

>> test/jdk/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java line 160:
>> 
>>> 158:         try {
>>> 159:             curThread.join();
>>> 160:         } catch (InterruptedException e) {
>> 
>> should it just let `InterruptedException` be thrown rather than swallowing it?  This pattern appears multiple places in this test and ThreadAllocatedMemoryArray.java test.
>
> The original implementation grabbed this code from, e.g., test/jdk/java/lang/management/ThreadMXBean/ThreadUserTime.java. In the latter, InterruptedException causes the test to fail, but for some reason now lost, ThreadAllocatedMemory.java doesn't do that, but ThreadAllocatedMemoryArray.java does.

Since you are on this file, it may be good to clean them up.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1205773318

From dholmes at openjdk.org  Fri May 26 00:10:07 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 26 May 2023 00:10:07 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v26]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 24 May 2023 16:50:55 GMT, Paul Hohensee  wrote:

>> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
>> 
>> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.
>
> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge master

A global allocation counter sounds like a potential bottleneck to me and everyone has to pay for it. I'd want to see broad performance measurements for that and hear what the GC folk have to say.

A global counter would also need to resurrect Atomic::add(jlong) for all platforms.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13814#issuecomment-1563649176
PR Comment: https://git.openjdk.org/jdk/pull/13814#issuecomment-1563649816

From dholmes at openjdk.org  Fri May 26 02:33:08 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 26 May 2023 02:33:08 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v26]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 24 May 2023 16:50:55 GMT, Paul Hohensee  wrote:

>> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
>> 
>> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.
>
> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge master

The monotonicity issue can be addressed by tracking the last total and never reporting a smaller value. (Much as we used to cache the current time to avoid it going backwards.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13814#issuecomment-1563731819

From djelinski at openjdk.org  Fri May 26 07:50:56 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 26 May 2023 07:50:56 GMT
Subject: jmx-dev RFR: 8308286 Fix clang warnings in linux code
In-Reply-To: 
References: 
Message-ID: 

On Wed, 17 May 2023 12:28:47 GMT, Artem Semenov  wrote:

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

According to our docs, [clang is a supported compiler for Linux](https://github.com/openjdk/jdk/blob/master/doc/building.md#native-compiler-toolchain-requirements).

Here's an example how warning exclusion is implemented today:
https://github.com/openjdk/jdk/blob/master/make/modules/java.desktop/lib/Awt2dLibraries.gmk#L827

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14033#issuecomment-1563956337

From kevinw at openjdk.org  Fri May 26 10:51:57 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 26 May 2023 10:51:57 GMT
Subject: jmx-dev RFR: 8299665: /proc/self/stat parsing in libmanagement
 broken by execname with spaces
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 24 May 2023 23:48:52 GMT, Serguei Spitsyn  wrote:

>> Code that parses /proc/self/stat may be broken if the executable name contains spaces.
>> 
>> We have code that does this correctly, and code that does not.
>> UnixOperatingSystem.c is Linux-specific OS code, and has vread_statdata which correctly uses strrchr to find the last ) and parses from there.
>> 
>> OperatingSystemImpl.c the generic, not Linux-specific code, is not OK, as Java_com_sun_management_internal_OperatingSystemImpl_getCommittedVirtualMemorySize0 has a problematic fscanf call. 
>> But the problematic fscanf call is Linux-specific: we use ifdef to create OS-specific implementations.
>> 
>> 
>> Need to change the fscanf of /proc/self/stat to do the same buffered read as read_ticks in UnixOperatingSystem.c (the Linux-specific code), with strrchr to read past the ) of the execname.
>> 
>> Moving the actually-Linux-specific getCommittedVirtualMemorySize0 to be with the other Linux-specific code means it can just use the existing method for accessing /proc/self/stat.
>> 
>> It does however call throw_internal_error, which is then not accessible.  So that function can be shared in the libmanagement_ext.h/.c for both uses.
>> 
>> The call to throw_internal_error is working: if I change the code to fail, it reports a java.lang.InternalError as it would before.
>> 
>> Existing tests still pass: 
>> i.e. test/jdk/com/sun/management/OperatingSystemMXBean/GetCommittedVirtualMemorySize.java
>
> Thank you for explanation! Looks good.

Thanks @sspitsyn and @alexmenkov for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14107#issuecomment-1564203867

From kevinw at openjdk.org  Fri May 26 10:55:05 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 26 May 2023 10:55:05 GMT
Subject: jmx-dev Integrated: 8299665: /proc/self/stat parsing in
 libmanagement broken by execname with spaces
In-Reply-To: 
References: 
Message-ID: 

On Tue, 23 May 2023 20:54:42 GMT, Kevin Walls  wrote:

> Code that parses /proc/self/stat may be broken if the executable name contains spaces.
> 
> We have code that does this correctly, and code that does not.
> UnixOperatingSystem.c is Linux-specific OS code, and has vread_statdata which correctly uses strrchr to find the last ) and parses from there.
> 
> OperatingSystemImpl.c the generic, not Linux-specific code, is not OK, as Java_com_sun_management_internal_OperatingSystemImpl_getCommittedVirtualMemorySize0 has a problematic fscanf call. 
> But the problematic fscanf call is Linux-specific: we use ifdef to create OS-specific implementations.
> 
> 
> Need to change the fscanf of /proc/self/stat to do the same buffered read as read_ticks in UnixOperatingSystem.c (the Linux-specific code), with strrchr to read past the ) of the execname.
> 
> Moving the actually-Linux-specific getCommittedVirtualMemorySize0 to be with the other Linux-specific code means it can just use the existing method for accessing /proc/self/stat.
> 
> It does however call throw_internal_error, which is then not accessible.  So that function can be shared in the libmanagement_ext.h/.c for both uses.
> 
> The call to throw_internal_error is working: if I change the code to fail, it reports a java.lang.InternalError as it would before.
> 
> Existing tests still pass: 
> i.e. test/jdk/com/sun/management/OperatingSystemMXBean/GetCommittedVirtualMemorySize.java

This pull request has now been integrated.

Changeset: 17ef8a44
Author:    Kevin Walls 
URL:       https://git.openjdk.org/jdk/commit/17ef8a44a90a74724508a91abda3686e5123d1cd
Stats:     61 lines in 4 files changed: 34 ins; 25 del; 2 mod

8299665: /proc/self/stat parsing in libmanagement broken by execname with spaces

Reviewed-by: sspitsyn, amenkov

-------------

PR: https://git.openjdk.org/jdk/pull/14107

From phh at openjdk.org  Fri May 26 15:37:32 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 26 May 2023 15:37:32 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v27]
In-Reply-To: 
References: 
Message-ID: 

> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
> 
> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.

Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:

  8304074: Refactor test exception handling

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13814/files
  - new: https://git.openjdk.org/jdk/pull/13814/files/96cb0e5b..c2473337

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=25-26

  Stats: 38 lines in 2 files changed: 17 ins; 13 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/13814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814

PR: https://git.openjdk.org/jdk/pull/13814

From phh at openjdk.org  Fri May 26 16:41:32 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 26 May 2023 16:41:32 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v28]
In-Reply-To: 
References: 
Message-ID: <4ejYUU8Tud8k8znz94_oBUZxZi1WDt3b3SVPZosbXzQ=.ee4d6f16-3448-4247-9698-dd6fd9ca9633@github.com>

> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
> 
> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.

Paul Hohensee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 100 commits:

 - 8304074: Remove extra file
 - 8304074: Add getTotalAllocatedBytes high water mark
 - Merge branch 'master' into 8304074
 - 8304074: Refactor test exception handling
 - Merge master
 - Merge master
 - 8304074: Change UnsupportedOperationException in javadoc comment to {@code UnsupportedOperationException}
 - 8306507: [linux] Print number of memory mappings in error reports
   
   Reviewed-by: adinn, sgehwolf
 - 8300086: Replace NULL with nullptr in share/c1/
   
   Reviewed-by: thartmann, chagedorn
 - 8308465: Reduce memory accesses in AArch64 MD5 intrinsic
   
   Reviewed-by: aph, phh
 - ... and 90 more: https://git.openjdk.org/jdk/compare/77c5adb0...5f2f86bb

-------------

Changes: https://git.openjdk.org/jdk/pull/13814/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=27
  Stats: 297 lines in 10 files changed: 219 ins; 45 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/13814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814

PR: https://git.openjdk.org/jdk/pull/13814

From phh at openjdk.org  Fri May 26 16:41:32 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 26 May 2023 16:41:32 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v27]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 26 May 2023 15:37:32 GMT, Paul Hohensee  wrote:

>> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
>> 
>> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.
>
> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8304074: Refactor test exception handling

I added a high water mark to getTotalThreadAllocatedBytes (under a lock, lest we have a monotonicity issue on the high water mark), and updated the tests per Mandy's request.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13814#issuecomment-1564648234

From phh at openjdk.org  Fri May 26 16:41:32 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 26 May 2023 16:41:32 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v23]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Thu, 25 May 2023 09:01:14 GMT, Kevin Walls  wrote:

>> src/hotspot/share/services/management.cpp line 2104:
>> 
>>> 2102:     // the final result can only be short due to (1) threads that start after
>>> 2103:     // the TLH is created, or (2) terminating threads that escape TLH creation
>>> 2104:     // and don't update exited_allocated_bytes before we initialize result.
>> 
>> Okay this is why you can't do monotonicity check in the tests. Imagine we have 10 threads all live and we call this function and so tally up all 10 threads. The next time we call this 5 of the threads are in the process of terminating - they have escaped the TLH but not yet updated the exited_allocated_bytes - so now we only tally up 5 threads and so the total appears to be far less than last time.
>
> The tests and all apps might thank us for keeping last known value, and not returning anything lower, ensuring montonicity.

Fixed using a high water mark.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1207049618

From phh at openjdk.org  Fri May 26 17:23:09 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 26 May 2023 17:23:09 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v23]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Thu, 25 May 2023 16:38:43 GMT, Mandy Chung  wrote:

>> The original implementation grabbed this code from, e.g., test/jdk/java/lang/management/ThreadMXBean/ThreadUserTime.java. In the latter, InterruptedException causes the test to fail, but for some reason now lost, ThreadAllocatedMemory.java doesn't do that, but ThreadAllocatedMemoryArray.java does.
>
> Since you are on this file, it may be good to clean them up.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1207104630

From mchung at openjdk.org  Fri May 26 17:27:10 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 26 May 2023 17:27:10 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v28]
In-Reply-To: <4ejYUU8Tud8k8znz94_oBUZxZi1WDt3b3SVPZosbXzQ=.ee4d6f16-3448-4247-9698-dd6fd9ca9633@github.com>
References: 
 <4ejYUU8Tud8k8znz94_oBUZxZi1WDt3b3SVPZosbXzQ=.ee4d6f16-3448-4247-9698-dd6fd9ca9633@github.com>
Message-ID: 

On Fri, 26 May 2023 16:41:32 GMT, Paul Hohensee  wrote:

>> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
>> 
>> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.
>
> Paul Hohensee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 100 commits:
> 
>  - 8304074: Remove extra file
>  - 8304074: Add getTotalAllocatedBytes high water mark
>  - Merge branch 'master' into 8304074
>  - 8304074: Refactor test exception handling
>  - Merge master
>  - Merge master
>  - 8304074: Change UnsupportedOperationException in javadoc comment to {@code UnsupportedOperationException}
>  - 8306507: [linux] Print number of memory mappings in error reports
>    
>    Reviewed-by: adinn, sgehwolf
>  - 8300086: Replace NULL with nullptr in share/c1/
>    
>    Reviewed-by: thartmann, chagedorn
>  - 8308465: Reduce memory accesses in AArch64 MD5 intrinsic
>    
>    Reviewed-by: aph, phh
>  - ... and 90 more: https://git.openjdk.org/jdk/compare/77c5adb0...5f2f86bb

Marked as reviewed by mchung (Reviewer).

Thanks for updating the test.   The spec looks good.   I'll leave the hotspot implementation for David and others to approve.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13814#pullrequestreview-1446662964
PR Comment: https://git.openjdk.org/jdk/pull/13814#issuecomment-1564701378

From phh at openjdk.org  Fri May 26 18:59:12 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 26 May 2023 18:59:12 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v28]
In-Reply-To: <4ejYUU8Tud8k8znz94_oBUZxZi1WDt3b3SVPZosbXzQ=.ee4d6f16-3448-4247-9698-dd6fd9ca9633@github.com>
References: 
 <4ejYUU8Tud8k8znz94_oBUZxZi1WDt3b3SVPZosbXzQ=.ee4d6f16-3448-4247-9698-dd6fd9ca9633@github.com>
Message-ID: 

On Fri, 26 May 2023 16:41:32 GMT, Paul Hohensee  wrote:

>> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
>> 
>> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.
>
> Paul Hohensee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 100 commits:
> 
>  - 8304074: Remove extra file
>  - 8304074: Add getTotalAllocatedBytes high water mark
>  - Merge branch 'master' into 8304074
>  - 8304074: Refactor test exception handling
>  - Merge master
>  - Merge master
>  - 8304074: Change UnsupportedOperationException in javadoc comment to {@code UnsupportedOperationException}
>  - 8306507: [linux] Print number of memory mappings in error reports
>    
>    Reviewed-by: adinn, sgehwolf
>  - 8300086: Replace NULL with nullptr in share/c1/
>    
>    Reviewed-by: thartmann, chagedorn
>  - 8308465: Reduce memory accesses in AArch64 MD5 intrinsic
>    
>    Reviewed-by: aph, phh
>  - ... and 90 more: https://git.openjdk.org/jdk/compare/77c5adb0...5f2f86bb

Thanks for your review, Mandy.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13814#issuecomment-1564800041

From kbarrett at openjdk.org  Sun May 28 03:39:10 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 28 May 2023 03:39:10 GMT
Subject: jmx-dev RFR: 8308286 Fix clang warnings in linux code
In-Reply-To: 
References: 
 
Message-ID: <63Q15YTSJDgsIJb4fYQYdrtBYkSNebRm7Q8jVgzTiW8=.86a710d5-1930-4b3c-80a2-743a83653831@github.com>

On Fri, 26 May 2023 07:48:06 GMT, Daniel Jeli?ski  wrote:

> According to our docs, [clang is a supported compiler for Linux](https://github.com/openjdk/jdk/blob/master/doc/building.md#native-compiler-toolchain-requirements).

I think that's aspirational rather than actual.  Clang has been included in
that list for a long time (since at least JDK 9), but I think there's never
been anyone claiming to provide such support, be a maintainer, or even
build/test on some regular basis:
https://wiki.openjdk.org/display/Build/Supported+Build+Platforms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14033#issuecomment-1565842012

From kbarrett at openjdk.org  Sun May 28 04:14:04 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 28 May 2023 04:14:04 GMT
Subject: jmx-dev RFR: 8308286 Fix clang warnings in linux code
In-Reply-To: 
References: 
Message-ID: <_RQshJQSfZfWSXTPvIjEekBkNIJCGy6UPHo_94bE5IM=.afc7036a-4553-45f2-b5d2-76758e69dbb4@github.com>

On Wed, 17 May 2023 12:28:47 GMT, Artem Semenov  wrote:

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

All of the -Wformat-nonliteral changes make me wonder why we're seeing these
with clang but not with gcc.  Figuring that out will likely give a better
chance of acceptance.

src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c line 1163:

> 1161: #if defined(__clang__)
> 1162: #pragma clang diagnostic push
> 1163: #pragma clang diagnostic ignored "-Wparentheses"

I think this warning is because of the several `if (init_result = ...)`?  Better would be to just add the extra parens.

src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 575:

> 573: if (ps_pdread(ph, (char *)link_map_addr + LINK_MAP_LD_OFFSET,
> 574:                &lib_ld, sizeof(uintptr_t)) != PS_OK) {
> 575: #else

What problem is being "fixed" by these?  I'm dubious that this is the best solution to whatever the problem
is, but can't evaluate or suggest alternatives without knowing what it is.

-------------

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14033#pullrequestreview-1447852014
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1208298799
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1208302906

From dholmes at openjdk.org  Mon May 29 02:10:12 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 29 May 2023 02:10:12 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v28]
In-Reply-To: <4ejYUU8Tud8k8znz94_oBUZxZi1WDt3b3SVPZosbXzQ=.ee4d6f16-3448-4247-9698-dd6fd9ca9633@github.com>
References: 
 <4ejYUU8Tud8k8znz94_oBUZxZi1WDt3b3SVPZosbXzQ=.ee4d6f16-3448-4247-9698-dd6fd9ca9633@github.com>
Message-ID: <6a8iDpTUJ4vMUEb02xQ9ZqJu4zSGx_vH8N7mOzKmgW8=.adff5b94-203d-43eb-bfae-312963fd7779@github.com>

On Fri, 26 May 2023 16:41:32 GMT, Paul Hohensee  wrote:

>> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
>> 
>> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.
>
> Paul Hohensee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 100 commits:
> 
>  - 8304074: Remove extra file
>  - 8304074: Add getTotalAllocatedBytes high water mark
>  - Merge branch 'master' into 8304074
>  - 8304074: Refactor test exception handling
>  - Merge master
>  - Merge master
>  - 8304074: Change UnsupportedOperationException in javadoc comment to {@code UnsupportedOperationException}
>  - 8306507: [linux] Print number of memory mappings in error reports
>    
>    Reviewed-by: adinn, sgehwolf
>  - 8300086: Replace NULL with nullptr in share/c1/
>    
>    Reviewed-by: thartmann, chagedorn
>  - 8308465: Reduce memory accesses in AArch64 MD5 intrinsic
>    
>    Reviewed-by: aph, phh
>  - ... and 90 more: https://git.openjdk.org/jdk/compare/77c5adb0...5f2f86bb

High watermark changes seem fine in principle but not sure about borrowing the `MonitoringSupport_lock ` to do the locking. At a minimum this comment should be expanded:

./share/runtime/mutexLocker.hpp:extern Mutex*   MonitoringSupport_lock;          // Protects updates to the serviceability memory pools.

test/jdk/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java line 305:

> 303:     }
> 304: 
> 305:     private static void reportUnexpected(Exception e, String reason) {

nit: 'when' or 'where' seems a more appropriate name than 'reason'

-------------

PR Review: https://git.openjdk.org/jdk/pull/13814#pullrequestreview-1448631761
PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1208763752

From phh at openjdk.org  Mon May 29 17:51:17 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Mon, 29 May 2023 17:51:17 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v29]
In-Reply-To: 
References: 
Message-ID: 

> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
> 
> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.

Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:

  8304074: Change reportUnsupported argument name to when, add comment to MonitoringSupport_lock declaration

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13814/files
  - new: https://git.openjdk.org/jdk/pull/13814/files/5f2f86bb..48a5852e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13814&range=27-28

  Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13814.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13814/head:pull/13814

PR: https://git.openjdk.org/jdk/pull/13814

From phh at openjdk.org  Mon May 29 17:51:22 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Mon, 29 May 2023 17:51:22 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v28]
In-Reply-To: <4ejYUU8Tud8k8znz94_oBUZxZi1WDt3b3SVPZosbXzQ=.ee4d6f16-3448-4247-9698-dd6fd9ca9633@github.com>
References: 
 <4ejYUU8Tud8k8znz94_oBUZxZi1WDt3b3SVPZosbXzQ=.ee4d6f16-3448-4247-9698-dd6fd9ca9633@github.com>
Message-ID: 

On Fri, 26 May 2023 16:41:32 GMT, Paul Hohensee  wrote:

>> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
>> 
>> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.
>
> Paul Hohensee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 100 commits:
> 
>  - 8304074: Remove extra file
>  - 8304074: Add getTotalAllocatedBytes high water mark
>  - Merge branch 'master' into 8304074
>  - 8304074: Refactor test exception handling
>  - Merge master
>  - Merge master
>  - 8304074: Change UnsupportedOperationException in javadoc comment to {@code UnsupportedOperationException}
>  - 8306507: [linux] Print number of memory mappings in error reports
>    
>    Reviewed-by: adinn, sgehwolf
>  - 8300086: Replace NULL with nullptr in share/c1/
>    
>    Reviewed-by: thartmann, chagedorn
>  - 8308465: Reduce memory accesses in AArch64 MD5 intrinsic
>    
>    Reviewed-by: aph, phh
>  - ... and 90 more: https://git.openjdk.org/jdk/compare/77c5adb0...5f2f86bb

Changed the MonitoringSupport_lock comment to "Protects updates to the serviceability memory pools and allocated memory high water mark". The lock was introduced to serialize updates to the G1 memory pool stats, but given that doesn't happen very often, and the name, imo it's reasonable to use it in a more general fashion.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13814#issuecomment-1567380618

From phh at openjdk.org  Mon May 29 17:51:22 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Mon, 29 May 2023 17:51:22 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v28]
In-Reply-To: <6a8iDpTUJ4vMUEb02xQ9ZqJu4zSGx_vH8N7mOzKmgW8=.adff5b94-203d-43eb-bfae-312963fd7779@github.com>
References: 
 <4ejYUU8Tud8k8znz94_oBUZxZi1WDt3b3SVPZosbXzQ=.ee4d6f16-3448-4247-9698-dd6fd9ca9633@github.com>
 <6a8iDpTUJ4vMUEb02xQ9ZqJu4zSGx_vH8N7mOzKmgW8=.adff5b94-203d-43eb-bfae-312963fd7779@github.com>
Message-ID: 

On Mon, 29 May 2023 02:02:21 GMT, David Holmes  wrote:

>> Paul Hohensee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 100 commits:
>> 
>>  - 8304074: Remove extra file
>>  - 8304074: Add getTotalAllocatedBytes high water mark
>>  - Merge branch 'master' into 8304074
>>  - 8304074: Refactor test exception handling
>>  - Merge master
>>  - Merge master
>>  - 8304074: Change UnsupportedOperationException in javadoc comment to {@code UnsupportedOperationException}
>>  - 8306507: [linux] Print number of memory mappings in error reports
>>    
>>    Reviewed-by: adinn, sgehwolf
>>  - 8300086: Replace NULL with nullptr in share/c1/
>>    
>>    Reviewed-by: thartmann, chagedorn
>>  - 8308465: Reduce memory accesses in AArch64 MD5 intrinsic
>>    
>>    Reviewed-by: aph, phh
>>  - ... and 90 more: https://git.openjdk.org/jdk/compare/77c5adb0...5f2f86bb
>
> test/jdk/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java line 305:
> 
>> 303:     }
>> 304: 
>> 305:     private static void reportUnexpected(Exception e, String reason) {
> 
> nit: 'when' or 'where' seems a more appropriate name than 'reason'

Changed to "when".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1209483911

From asemenov at openjdk.org  Mon May 29 22:29:26 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Mon, 29 May 2023 22:29:26 GMT
Subject: jmx-dev RFR: 8308286 Fix clang warnings in linux code [v2]
In-Reply-To: 
References: 
Message-ID: 

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:

  update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14033/files
  - new: https://git.openjdk.org/jdk/pull/14033/files/86077cdf..3f343c26

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=00-01

  Stats: 134 lines in 15 files changed: 12 ins; 122 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033

PR: https://git.openjdk.org/jdk/pull/14033

From dholmes at openjdk.org  Tue May 30 00:21:09 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 30 May 2023 00:21:09 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v29]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 29 May 2023 17:51:17 GMT, Paul Hohensee  wrote:

>> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
>> 
>> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.
>
> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8304074: Change reportUnsupported argument name to when, add comment to MonitoringSupport_lock declaration

Nothing further from me. Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13814#pullrequestreview-1449920514

From avu at openjdk.org  Tue May 30 08:20:04 2023
From: avu at openjdk.org (Alexey Ushakov)
Date: Tue, 30 May 2023 08:20:04 GMT
Subject: jmx-dev RFR: 8308286 Fix clang warnings in linux code [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 29 May 2023 22:29:26 GMT, Artem Semenov  wrote:

>> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
>> They can be fixed with small changes.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

Changes requested by avu (Committer).

src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 655:

> 653:       // linker loaded it. We use "base diff" in read_lib_segments call below.
> 654: 
> 655:                     if (ps_pdread(ph, (psaddr_t) link_map_addr + LINK_MAP_ADDR_OFFSET,

Extra white spaces before 'if'

src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 662:

> 660: 
> 661:       // read address of the name
> 662:                       if (ps_pdread(ph, (psaddr_t) link_map_addr + LINK_MAP_NAME_OFFSET,

Extra white-spaces before 'if'

src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 717:

> 715: 
> 716:     // read next link_map address
> 717:                     if (ps_pdread(ph, (psaddr_t) link_map_addr + LINK_MAP_NEXT_OFFSET,

Extra white-spaces before 'if'

src/jdk.jpackage/share/native/common/tstrings.cpp line 60:

> 58: #endif
> 59:         // With g++ this compiles only with '-std=gnu++0x' option
> 60:                 ret = vsnprintf(&*fmtout.begin(), fmtout.size(), format, args);

Extra white-spaces before 'ret'

-------------

PR Review: https://git.openjdk.org/jdk/pull/14033#pullrequestreview-1450367357
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1209893589
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1209894667
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1209895275
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1209895801

From phh at openjdk.org  Tue May 30 13:47:20 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 30 May 2023 13:47:20 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v29]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 29 May 2023 17:51:17 GMT, Paul Hohensee  wrote:

>> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
>> 
>> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.
>
> Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8304074: Change reportUnsupported argument name to when, add comment to MonitoringSupport_lock declaration

Thanks for your in-depth review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13814#issuecomment-1568460763

From phh at openjdk.org  Tue May 30 13:47:21 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 30 May 2023 13:47:21 GMT
Subject: jmx-dev Integrated: 8304074: [JMX] Add an approximation of total
 bytes allocated on the Java heap by the JVM
In-Reply-To: 
References: 
Message-ID: <19oTqtEgLkKyCQxVRlkpKE69AAYjVG07jk-80OIUVpw=.c0e4661e-074c-4ca9-8608-7d8dcd55f3f5@github.com>

On Thu, 4 May 2023 19:54:57 GMT, Paul Hohensee  wrote:

> Please review this addition to com.sun.management.ThreadMXBean that returns the total number of bytes allocated on the Java heap since JVM launch by both terminated and live threads.
> 
> Because this PR adds a new interface method, I've updated the JMM_VERSION to 4, but would be happy to update it to 3_1 instead.

This pull request has now been integrated.

Changeset: 3eced01f
Author:    Paul Hohensee 
URL:       https://git.openjdk.org/jdk/commit/3eced01f9efe2567a07b63343f8559683a2d0517
Stats:     298 lines in 11 files changed: 219 ins; 45 del; 34 mod

8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM

Reviewed-by: dholmes, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/13814

From simonis at openjdk.org  Tue May 30 14:23:19 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 30 May 2023 14:23:19 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v23]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Fri, 26 May 2023 16:35:32 GMT, Paul Hohensee  wrote:

>> The tests and all apps might thank us for keeping last known value, and not returning anything lower, ensuring montonicity.
>
> Fixed using a high water mark.

A simple fix for guaranteeing monotonicity, would be to add another field (e.g. `max_allocated_bytes`) which keeps the last result returned by `getTotalThreadAllocatedBytes()` and the latter would then return the maximum of the current computation and `max_allocated_bytes`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1210355727

From phh at openjdk.org  Tue May 30 15:57:19 2023
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 30 May 2023 15:57:19 GMT
Subject: jmx-dev RFR: 8304074: [JMX] Add an approximation of total bytes
 allocated on the Java heap by the JVM [v23]
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: 

On Tue, 30 May 2023 14:20:12 GMT, Volker Simonis  wrote:

>> Fixed using a high water mark.
>
> A simple fix for guaranteeing monotonicity, would be to add another field (e.g. `max_allocated_bytes`) which keeps the last result returned by `getTotalThreadAllocatedBytes()` and the latter would then return the maximum of the current computation and `max_allocated_bytes`.

That's what I did. :) Thanks for your review!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1210491161

From asemenov at openjdk.org  Wed May 31 13:37:06 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Wed, 31 May 2023 13:37:06 GMT
Subject: jmx-dev RFR: 8308286 Fix clang warnings in linux code [v3]
In-Reply-To: 
References: 
Message-ID: 

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:

  update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14033/files
  - new: https://git.openjdk.org/jdk/pull/14033/files/3f343c26..d5b70cb2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=01-02

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033

PR: https://git.openjdk.org/jdk/pull/14033

From asemenov at openjdk.org  Wed May 31 13:40:57 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Wed, 31 May 2023 13:40:57 GMT
Subject: jmx-dev RFR: 8308286 Fix clang warnings in linux code [v3]
In-Reply-To: <_RQshJQSfZfWSXTPvIjEekBkNIJCGy6UPHo_94bE5IM=.afc7036a-4553-45f2-b5d2-76758e69dbb4@github.com>
References: 
 <_RQshJQSfZfWSXTPvIjEekBkNIJCGy6UPHo_94bE5IM=.afc7036a-4553-45f2-b5d2-76758e69dbb4@github.com>
Message-ID: 

On Sun, 28 May 2023 03:57:40 GMT, Kim Barrett  wrote:

>> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update
>
> src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c line 1163:
> 
>> 1161: #if defined(__clang__)
>> 1162: #pragma clang diagnostic push
>> 1163: #pragma clang diagnostic ignored "-Wparentheses"
> 
> I think this warning is because of the several `if (init_result = ...)`?  Better would be to just add the extra parens.

done

> src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 575:
> 
>> 573: if (ps_pdread(ph, (char *)link_map_addr + LINK_MAP_LD_OFFSET,
>> 574:                &lib_ld, sizeof(uintptr_t)) != PS_OK) {
>> 575: #else
> 
> What problem is being "fixed" by these?  I'm dubious that this is the best solution to whatever the problem
> is, but can't evaluate or suggest alternatives without knowing what it is.

done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211733228
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211732832

From asemenov at openjdk.org  Wed May 31 13:41:04 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Wed, 31 May 2023 13:41:04 GMT
Subject: jmx-dev RFR: 8308286 Fix clang warnings in linux code [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Tue, 30 May 2023 08:14:59 GMT, Alexey Ushakov  wrote:

>> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update
>
> src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 655:
> 
>> 653:       // linker loaded it. We use "base diff" in read_lib_segments call below.
>> 654: 
>> 655:                     if (ps_pdread(ph, (psaddr_t) link_map_addr + LINK_MAP_ADDR_OFFSET,
> 
> Extra white spaces before 'if'

done

> src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 662:
> 
>> 660: 
>> 661:       // read address of the name
>> 662:                       if (ps_pdread(ph, (psaddr_t) link_map_addr + LINK_MAP_NAME_OFFSET,
> 
> Extra white-spaces before 'if'

done

> src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 717:
> 
>> 715: 
>> 716:     // read next link_map address
>> 717:                     if (ps_pdread(ph, (psaddr_t) link_map_addr + LINK_MAP_NEXT_OFFSET,
> 
> Extra white-spaces before 'if'

done

> src/jdk.jpackage/share/native/common/tstrings.cpp line 60:
> 
>> 58: #endif
>> 59:         // With g++ this compiles only with '-std=gnu++0x' option
>> 60:                 ret = vsnprintf(&*fmtout.begin(), fmtout.size(), format, args);
> 
> Extra white-spaces before 'ret'

done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211732345
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211734132
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211734711
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211735111

From weijun at openjdk.org  Wed May 31 13:55:57 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 31 May 2023 13:55:57 GMT
Subject: jmx-dev RFR: 8308286 Fix clang warnings in linux code [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 31 May 2023 13:37:06 GMT, Artem Semenov  wrote:

>> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
>> They can be fixed with small changes.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

src/java.security.jgss/share/native/libj2gss/gssapi.h line 47:

> 45: 
> 46: // Condition was copied from
> 47: // Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/gssapi/gssapi.h

In the current version of the file above, it's written as

#if defined(__APPLE__) && (defined(__ppc__) ||...

Is it better?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211757380