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

[Aleksey Shipilev]

On Fri, 5 May 2023 06:45:10 GMT, David Holmes <dholmes at 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