On Mon, 23 May 2022 09:58:46 GMT, David Holmes <dhol...@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
