RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong

[David Holmes]

On Thu, 26 May 2022 13:47:55 GMT, Thomas Stuefe <stuefe 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.
>
> 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.

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

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