RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong

[Yi Yang]

On Thu, 26 May 2022 07:34:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is also acceptable, but if we add more memory pools, we might add more special pools to exclude their space from nonheap. Instead, we can specify exactly which pools we need to accumulate, which is what this change did.
>
> 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 repeatedly count a piece of memory, right? In the extreme case, we might add all nested pools of metaspace, and we will get Metaspace x2 + CodeCache when using getNonHeapMemoryUsage.

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

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

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