RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong

[David Holmes]

On Thu, 26 May 2022 11:32:46 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> I think the problem is the definition of the pools. We seem to have nested pools but it is far from clear that this API/mechanism was designed/intended to support nested pools.
>
> 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.

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

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