RFR: 8304074: [JMX] Add an approximation of JVM process allocated bytes

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

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

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 safepo

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

; 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://g

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

; 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://g

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

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 b

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

; 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://g

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

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

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

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)

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

; 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://g

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

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

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

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

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

; 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.ope

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

; 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.o

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

; 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.o

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

; 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://g

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

; 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://g

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

; 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://g

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

; 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://g

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

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.hp

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

; 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-bi

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

; 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:

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

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 >>>

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

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

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

; 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/138

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

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 betwe

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

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(JavaThrea

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

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. Other

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

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. T

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

; 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 las

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

; 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/138

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

; 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

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

; 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 las

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

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. >> >> Becaus

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

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' -> &#x

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

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 c

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

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

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

; 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/138

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

; 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 las

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

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 addi

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

; 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/138

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

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:

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

; 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/138

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

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/s

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

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/s

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

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. >> >> Becaus

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

; 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]

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

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/sh

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

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. >> >> Becaus

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

; 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 l

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

; 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/pu

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

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/c

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

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. >> >> Becaus

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

; 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: http

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

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. >> >> Becaus

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

; 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 branc

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

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 >>> creati

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

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, ThreadAllocatedM

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

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. >> >> Becaus

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

; 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 -

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

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 getTotal

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

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. >> >> Becaus

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

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. >> >> Becaus

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

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 i

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

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

Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v5]

On Sun, 4 Jun 2023 21:39:58 GMT, Kelvin Nilsen wrote: >> OpenJDK Colleagues: >> >> Please review this proposed integration of Generational mode for Shenandoah >> GC under https://bugs.openjdk.org/browse/JDK-8307314. >> >> Generational mode of Shenandoah is enabled by adding >> `-XX:+UnlockExp

Re: RFR: JDK-8307314: Implementation: Generational Shenandoah (Experimental) [v5]

On Sun, 4 Jun 2023 21:39:58 GMT, Kelvin Nilsen wrote: >> OpenJDK Colleagues: >> >> Please review this proposed integration of Generational mode for Shenandoah >> GC under https://bugs.openjdk.org/browse/JDK-8307314. >> >> Generational mode of Shenandoah is enabled by adding >> `-XX:+UnlockExp

Re: RFR: 8309271: A way to align already compiled methods with compiler directives

On Wed, 24 May 2023 00:38:27 GMT, Dmitry Chuyko wrote: > Compiler Control (https://openjdk.org/jeps/165) provides method-context > dependent control of the JVM compilers (C1 and C2). The active directive > stack is built from the directive files passed with the > `-XX:CompilerDirectivesFile` d

RFR: 8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074

MonitoringSupport_lock is initialized only when UseG1GC is true, but [JDK-8304074](https://bugs.openjdk.org/browse/JDK-8304074) uses it to implement getTotalThreadAllocatedBytes, which is available for all garbage collectors. While the current code sets UseG1GC regardless of which collector is s

Re: RFR: 8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074

On Tue, 25 Jul 2023 21:48:24 GMT, Paul Hohensee wrote: > MonitoringSupport_lock is initialized only when UseG1GC is true, but > [JDK-8304074](https://bugs.openjdk.org/browse/JDK-8304074) uses it to > implement getTotalThreadAllocatedBytes, which is available for all garbage >

Re: RFR: 8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074

On Tue, 25 Jul 2023 21:48:24 GMT, Paul Hohensee wrote: > MonitoringSupport_lock is initialized only when UseG1GC is true, but > [JDK-8304074](https://bugs.openjdk.org/browse/JDK-8304074) uses it to > implement getTotalThreadAllocatedBytes, which is available for all garbage >

Re: RFR: 8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074 [v2]

on should be unconditional. > > I updated ThreadAllocatedMemory.java to run the test using both G1 and Serial > collectors. Paul Hohensee has updated the pull request incrementally with one additional commit since the last revision: 8313081: MonitoringSupport_lock should be

Re: RFR: 8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074 [v2]

On Wed, 26 Jul 2023 15:19:02 GMT, Paul Hohensee wrote: >> MonitoringSupport_lock is initialized only when UseG1GC is true, but >> [JDK-8304074](https://bugs.openjdk.org/browse/JDK-8304074) uses it to >> implement getTotalThreadAllocatedBytes, which is available for all garb

Re: RFR: 8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074 [v2]

On Wed, 26 Jul 2023 15:19:02 GMT, Paul Hohensee wrote: >> MonitoringSupport_lock is initialized only when UseG1GC is true, but >> [JDK-8304074](https://bugs.openjdk.org/browse/JDK-8304074) uses it to >> implement getTotalThreadAllocatedBytes, which is available for all garb

Re: RFR: 8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074 [v2]

On Wed, 26 Jul 2023 15:19:02 GMT, Paul Hohensee wrote: >> MonitoringSupport_lock is initialized only when UseG1GC is true, but >> [JDK-8304074](https://bugs.openjdk.org/browse/JDK-8304074) uses it to >> implement getTotalThreadAllocatedBytes, which is available for all garb

Integrated: 8313081: MonitoringSupport_lock should be unconditionally initialized after 8304074

On Tue, 25 Jul 2023 21:48:24 GMT, Paul Hohensee wrote: > MonitoringSupport_lock is initialized only when UseG1GC is true, but > [JDK-8304074](https://bugs.openjdk.org/browse/JDK-8304074) uses it to > implement getTotalThreadAllocatedBytes, which is available for all garbage >

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

On Mon, 11 Dec 2023 22:41:56 GMT, Yi-Fan Tsai wrote: >> `jcmd Compiler.perfmap` uses the hard-coded file name for a perf map: >> `/tmp/perf-%d.map`. This change adds an optional argument for specifying a >> file name. >> >> `jcmd PID help Compiler.perfmap` shows the following usage. >> >> >>

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

On Mon, 11 Dec 2023 22:41:56 GMT, Yi-Fan Tsai wrote: >> `jcmd Compiler.perfmap` uses the hard-coded file name for a perf map: >> `/tmp/perf-%d.map`. This change adds an optional argument for specifying a >> file name. >> >> `jcmd PID help Compiler.perfmap` shows the following usage. >> >> >>

Re: RFR: 8324241: Always record evol_method deps to avoid excessive method flushing

On Sat, 20 Jan 2024 19:48:07 GMT, Volker Simonis wrote: > Currently we don't record dependencies on redefined methods (i.e. > `evol_method` dependencies) in JIT compiled methods if none of the > `can_redefine_classes`, `can_retransform_classes` or > `can_generate_breakpoint_events` JVMTI capab

Re: RFR: 8328592: hprof tests fail with -XX:-CompactStrings

On Wed, 20 Mar 2024 09:53:36 GMT, Aleksey Shipilev wrote: > See the bug for symptoms. The tests are failing because hprof test library is > confused about non-compact strings. > > Additional testing: > - [x] `serviceability/HeapDump lib-test:all` with `-XX:-CompactStrings` now > pass > - [x]

Re: RFR: 8328592: hprof tests fail with -XX:-CompactStrings [v2]

On Wed, 20 Mar 2024 17:19:34 GMT, Aleksey Shipilev wrote: >> See the bug for symptoms. The tests are failing because hprof test library >> is confused about non-compact strings. >> >> Additional testing: >> - [x] `serviceability/HeapDump lib-test:all` with `-XX:-CompactStrings` now >> pass >>

Re: RFR: 8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed with CPU time out of expected range

On Thu, 27 Jun 2024 08:54:16 GMT, Kevin Walls wrote: > This test has had occasional failures for years, possibly forever. > A previous update made the test "othervm" which removed some interruptions, > but a time accounting problem remains. > > This change adds a simple sleep after observing th

Re: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57]

On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) >> #20603 and #20605, plus the Tiny Class-Pointers parts that have been >> previ

Re: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v11]

On Tue, 26 Nov 2024 00:37:32 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage >> collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We >> would like to target JDK24 with this PR. > > William Kemper has updated the pull reques

Re: RFR: 8279005: sun/tools/jstat tests do not check for test case exit codes after JDK-8245129 [v2]

taspace, and compressed class space, > leading to an occupancy result represented by '-'. > > Modified tests pass. 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 b

Re: RFR: 8279005: sun/tools/jstat tests do not check for test case exit codes after JDK-8245129

On Tue, 24 Jun 2025 17:05:10 GMT, Aleksey Shipilev wrote: >> Windows GHA failures are infra-related and unrelated to this change. > >> Windows GHA failures are infra-related and unrelated to this change. > > You can pull in from current master to get them fixed. Done. Thanks, @shipilev. --

Re: RFR: 8279005: sun/tools/jstat tests do not check for test case exit codes after JDK-8245129

On Tue, 24 Jun 2025 13:48:02 GMT, Paul Hohensee wrote: > Please review a jstat test-only fix. > > 1. Ensure that jstat tests that run more than one sub-test per test file > check the result of each sub-test before continuing. > 2. Allow '-' as a valid jstat -gcutil hea

Re: RFR: 8279005: sun/tools/jstat tests do not check for test case exit codes after JDK-8245129 [v2]

On Tue, 24 Jun 2025 22:55:04 GMT, Chris Plummer 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 conta

Re: RFR: 8359180: Apply java.io.Serial annotations in java.instrument

On Tue, 10 Jun 2025 23:19:40 GMT, Sergey Bylokhov wrote: > Please review the application of `@Serial` annotation > ([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the > java.instrument module to enable stricter compile-time checking of > serialization-related declarati

Integrated: 8279005: sun/tools/jstat tests do not check for test case exit codes after JDK-8245129

On Tue, 24 Jun 2025 13:48:02 GMT, Paul Hohensee wrote: > Please review a jstat test-only fix. > > 1. Ensure that jstat tests that run more than one sub-test per test file > check the result of each sub-test before continuing. > 2. Allow '-' as a valid jstat -gcutil hea

Re: RFR: 8279005: sun/tools/jstat tests do not check for test case exit codes after JDK-8245129 [v2]

On Tue, 24 Jun 2025 17:48:56 GMT, Paul Hohensee wrote: >> Please review a jstat test-only fix. >> >> 1. Ensure that jstat tests that run more than one sub-test per test file >> check the result of each sub-test before continuing. >> 2. Allow '-' as

RFR: 8279005: sun/tools/jstat tests do not check for test case exit codes after JDK-8245129

jstat test-only fix. 1. Ensure that jstat tests that run more than one sub-test per test file check the result of each sub-test before continuing. 2. Allow '-' as a valid jstat -gcutil heap space percent occupancy field value, see lineCounts[1-4].awk. Occupancy is computed as ((capacity - used)