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