RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong

[Thomas Stuefe]

On Thu, 26 May 2022 12:47:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> In any case, it's unreasonable for getNonHeapMemoryUsage to count a piece of memory repeatedly, right? In the extreme case, we might add all nested pools of metaspace, and we will get Metaspace x2 + CodeCache when using getNonHeapMemoryUsage, which should be far beyond what developers expect. In a real scenario, some monitor platforms draw a line chart by collecting getHeapMemoryUsage and getNonHeapMemoryUsage. It's confusing for end-users of the monitor platform to understand why getHeapMemoryUsage is desired while getNonHeapMemoryUsage is bigger than expectation.
>> 
>> From the developer's point of view, MemoryMXBean.getNonHeapMemoryUsage is expected to obtain the size of non-heap area. Given that MemoryMXBean.getHeapMemoryUsage is clearly stated which is heap area:
>> 
>>      * Returns the current memory usage of the heap that
>>      * is used for object allocation.  The heap consists
>>      * of one or more memory pools.
>> 
>> 
>> I propose to revise the Java doc to describe the definition of non-heap area more precisely:
>> 
>>     /**
>>      * Returns the current memory usage of non-heap memory that
>>      * contains code cache and metaspace.
>>      * The non-heap memory consists of one or more memory pools.
>
> No, things like code-cache and metaspace do not get baked into the specification. "non-heap" is deliberately vague and open-ended.
> 
> I can agree the calculation may be wrong but we need to determine exactly why it is wrong. To me the pool definitions seem wrong - they shouldn't be nested, so then you couldn't double-count. But we really need the experts on this code to chime in.

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

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

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