RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong

David Holmes dholmes at openjdk.java.net
Fri May 27 05:04:28 UTC 2022


On Fri, 27 May 2022 02:12:32 GMT, Yi Yang <yyang at openjdk.org> wrote:

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

"non-heap" is any memory not part of the Java heap. But it is up to an implementation to decide what kinds of non-heap memory are represented by memory pools. The JavaDoc can only give possible examples not numerate an actual required set.

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

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


More information about the hotspot-runtime-dev mailing list