mjhjmtu

I've analyzed memory consumption of a java program on Linux Mint. I used top to capture memory statistics (memory used by program and also system-wide indicators like total_mem_used and mem_free). The results were surprising:

• "used physical memory" (RAM_USE_DELTA on chart) increased and "free physical memory" (reverted RAM_FREE_DELTA on chart) decreased the same amount the RES (P_RSS on chart) increased - this is what I expected


• the DATA (P_DATA on chart) field (described in top's man as "the amount of physical memory devoted to other than executable code") was 150 megs above RES.


• SWAP (SWAP_USE_DELTA on chart) was zero all the time


• SHR (shared memory; P_SHR on chart) was less than 15MB

The question is: what was counted in the aforementioned 150MB? Virtual (reserved but not allocated) stack? Memory mapped files? As I wrote before: RES ~ RAM_USED_DELTA so the amount of free memory did NOT decrease by 150MB so it may indicate virtual memory but it would be weird for a memory indicator to be a sum of a resident set and a virtual amount...

(on this chart lines described *_DELTA are relative to the start of the program i.e. close to the left side, where red P_RSS starts)

The field DATA is the virtual memory of the process allocated for stuff which is not executable code, that is to say, data; it includes static data, the stack, and dynamically allocated memory; together with the field CODE it is included in the total VIRTual memory. The RESident size is the amount of virtual memory which is actually in RAM; it consists of part of the CODE, part of the DATA and part of other things such as memory mapped files.

You will notice that there is no direct relationship between VIRT, CODE, DATA and RES. The CODE comes from the compiler; the VIRT and DATA are under the control of the process (malloc(), free(), mmap(), and so on); the RES part is controlled by the operating system.