RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong

[Yi Yang]

On Thu, 26 May 2022 22:17:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Beside my general points, I think this patch makes sense. I agree with @kelthuzadx that counting Classspace twice is wrong, whatever the intention of this API originally was.
>
> Yes counting it twice is wrong but this is the wrong fix. The pools are not defined correctly.

> Sorry for chiming in in a not very helpful way, but I am not sure what even the point is of this API.
> 
> I'm seriously interested in who uses it, and for what. Calculating real memory usage is notoriously difficult. This one seems to be just an arbitrary selection of stuff. It leaves out C-heap usage (VM, outer JDK, and third party libs), native mappings, sometimes massive system library overhead, text segments, thread stacks... that it counts class space twice is probably its smallest problem...

AFAIK, some DevOps platforms monitor JVM memory occupation by MemoryMXBean:

![image](https://user-images.githubusercontent.com/5010047/170614454-84e7fe3e-71bb-4277-8c03-db0f461d6ccf.png)

Users are confused about why `HeapMemory+NonHeapMemory` is not equal to resident memory(top->res). It's still not clear what NonHeap means from `Java Doc`, I tried to understand the definition of NonHeap in source code, then found this bug...

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

PR: https://git.openjdk.java.net/jdk/pull/8831