On Thu, 26 May 2022 11:32:46 GMT, Yi Yang <yy...@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
