RFR: 8287135: Calculation of jmm_GetMemoryUsage is wrong

[Yi Yang]

On Mon, 23 May 2022 09:58:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Sorry but I can't agree with this change as presented. By definition the total non-heap memory is the sum of all pools which identify as non-heap as per the specification:
> 
> "The non-heap memory consists of one or more memory pools. The used and committed size of the returned memory usage is the sum of those values of all non-heap memory pools ..."
> 
> so the existing code that sums the non-heap pools is correct. If you think `CompressedClassSpace` should not be counted then you need to argue for it to not be "non-heap".
> 
> Cheers, David

Hi David,

As far as APIs go, nobody wants to count ClassTypeSpace twice(`NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)`) when using getNonHeapMemoryUsage. The documentation should be there to explain the API more clearly, rather than guiding how to implement the API. Digging into commit history, I found only CodeHeap was presented as NonHeap pool [originally](https://github.com/kelthuzadx/jdk/blob/ca3a1be3fe174f6e406a0f5f61a77d3d8d4ec4d7/hotspot/src/share/vm/services/memoryPool.cpp)

But yes, there is a slightly conflict between API doc and internal implementation. I think there are some possible changes:
1. Tweak API documentation and adopt patch. Clearly document on what NonHeap really is. e.g. it consists of CodeCache + Metaspace.
2. Remove CompressedClassSpacePool. As there is no explicit use for it.

Or some other candidates? Looking forward to your suggesstions.

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

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