On Thu, 4 May 2023 19:54:57 GMT, Paul Hohensee <p...@openjdk.org> 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