Difference in committed memory and RSS in java process

Question

I am running a simple java process running jetty, for which top shows 2.9g of RAM. JDK version used is 1.8.0_112.

Using Native Memory Tracking (jcmd), it is showing total committed memory is just 1.5G of memory

Also the direct buffer pool size is very less, as reported by jvisualvm.

I am completely aware that memory shown by NMT is committed memory which need not to be in RAM. In that case contribution of NMT memory to RES should be < 1.5GB of RES memory.

In my case, the difference here is of ~1.4G (RES is showing 1.4G of more memory) which can't be attributed just to the shared libs, jars. Can someone suggest me how to know what this extra memory is and which tools can be used to check them?

I have checked all the existing related issues online/Stackoverflow, but couldn't find any suitable answer.

Answer 1

pmap -X <pid> will show the detailed breakdown of RSS from OS perspective.

NMT does not count memory allocated by native non-JVM code, even if this memory is allocated by the standard Java Class Library, e.g. by native methods of ZipInputStream. See the related question.

The other possible reason is malloc itself. Native memory allocator rarely returns unused memory back to the OS. For example, if an application allocates 1 GB in small chunks with malloc and then frees all these chunks, from the application perspective there will be 1 GB of free memory, but OS is likely to count this 1 GB in RSS. This memory basically belongs to the application's malloc pool and can be reused for future malloc calls.

Try to use alternative allocators like jemalloc or tcmalloc. By the way, they both have an allocation profiler that may help in finding native memory leaks.