Understanding RES memory in *nix and debugging mem

Question

RE: Possible native memory release error in Java

It has come to my attention that RES memory may show much more memory than what your application has actually allotted. In the example above, there is lots of alloc/dealloc commands but the RES memory gets stuck at a high number. I know that this is not a result of JIT or other memory processes as typically you can alloc and dealloc 500M and watch the RES go up and down perfectly under normal circumstances.

jon@ubuntu-dev:~$ top -d 1 -p 31067 | grep java
 31067 jon       20   0 6847648  27988  15420 S   0.0  0.2   0:00.09 java       
 31067 jon       20   0 7769264 743952  15548 S 315.5  4.6   0:03.25 java       
 31067 jon       20   0 7900336 847868  15548 S 380.1  5.3   0:07.06 java       
 31067 jon       20   0 7834800 810324  15548 S 379.1  5.0   0:10.86 java       
 31067 jon       20   0 7703728 700028  15548 S 379.2  4.3   0:14.66 java       
 31067 jon       20   0 7900336 894940  15548 S 379.2  5.5   0:18.46 java       
 31067 jon       20   0 7703728 674400  15548 S 277.5  4.2   0:21.24 java       
 31067 jon       20   0 7376048 430868  15548 S  59.9  2.7   0:21.84 java       
 31067 jon       20   0 7376048 430868  15548 S   0.0  2.7   0:21.84 java       
 31067 jon       20   0 7376048 430868  15548 S   1.0  2.7   0:21.85 java       
 31067 jon       20   0 7376048 430868  15548 S   0.0  2.7   0:21.85 java       
 31067 jon       20   0 7376048 430868  15548 S   1.0  2.7   0:21.86 java  

The application here is NOT holding on to that much memory. Java says committed size is 35MB and native memory size is 0.

If this is all true, then how in the world are we supposed to be able to accurately detect memory leaks in our applications if they don't consume all the memory on the system?

Answer 1

Check if the "shared" columns perhaps contains a large value? If so, your RES memory is probably due to memory-mapped files. This is a mechanism for efficiently accessing large data sets and it may be used internally by some library.