On Thu, 26 May 2022 07:34:59 GMT, David Holmes <[email protected]> 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
