On Mon, 23 May 2022 07:28:41 GMT, Yi Yang <yy...@openjdk.org> wrote: > It seems that calculation of > MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong. > > Currently, > `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)` > > ==> CodeHeap 'non-nmethods' 1532544 (Used) > ==> CodeHeap 'profiled nmethods' 0 > ==> CodeHeap 'non-profiled nmethods' 13952 > ==> Metaspace 506696 > ==> Compressed Class Space 43312 > init = 7667712(7488K) used = 2096504(2047K) committed = 8454144(8256K) max = > -1(-1K) > > In this way, getNonHeapMemoryUsage is larger than it ought to be, it should > be `NonHeapUsage = CodeCache + Metaspace`.
Memory pool API does not support "nested" memory pools (or sub-memory pools). JDK 18 memory pools are the following: HEAP G1 Eden Space HEAP G1 Old Gen HEAP G1 Survivor Space NON_HEAP CodeHeap 'non-nmethods' NON_HEAP Metaspace NON_HEAP CodeHeap 'profiled nmethods' NON_HEAP Compressed Class Space NON_HEAP CodeHeap 'non-profiled nmethods' If `Metaspace` memory pool contains the compressed class space, then I agree with David that the current non-heap memory pools need to be examined. The meta space should be separated into multiple non-heap memory pools without overlap. ------------- PR: https://git.openjdk.java.net/jdk/pull/8831
