On Thu, 26 May 2022 22:17:17 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> 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. > Sorry for chiming in in a not very helpful way, but I am not sure what even > the point is of this API. > > I'm seriously interested in who uses it, and for what. Calculating real > memory usage is notoriously difficult. This one seems to be just an arbitrary > selection of stuff. It leaves out C-heap usage (VM, outer JDK, and third > party libs), native mappings, sometimes massive system library overhead, text > segments, thread stacks... that it counts class space twice is probably its > smallest problem... AFAIK, some DevOps platforms monitor JVM memory occupation by MemoryMXBean:  Users are confused about why `HeapMemory+NonHeapMemory` is not equal to resident memory(top->res). It's still not clear what NonHeap means from `Java Doc`, I tried to understand the definition of NonHeap in source code, then found this bug... ------------- PR: https://git.openjdk.java.net/jdk/pull/8831
