On Fri, 5 May 2023 06:45:10 GMT, David Holmes <dhol...@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? 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
