virtual v. physical memory in assessing C/C++ memory leak

Question

I have a C++ application that I am trying to iron the memory leaks out of and I realized I don't fully understand the difference between virtual and physical memory.

Results from top (so 16.8g = virtual, 111m = physical):

4406 um 20 0 16.8g 111m 4928 S 64.7 22.8 36:53.65 client

My process holds 500 connections, one for each user, and at these numbers it means there is about 30 MB of virtual overhead for each user. Without going into the details of my application, the only way this could sound remotely realistic, adding together all the vectors, structs, threads, functions on the stack, etc., is if I have no idea what virtual memory actually means. No -O optimization flags, btw.

So my questions are:

• what operations in C++ would inflate virtual memory so much?
• Is it a problem if my task is using gigs of virtual memory?
• The stack and heap function variables, vectors, etc. - do those necessarily increase the use of physical memory?
• Would removing a memory leak (via delete or free() or such) necessarily reduce both physical and virtual memory usage?

Answer 1

Virtual memory is what your program deals with. It consists of all of the addresses returned by malloc, new, et al. Each process has its own virtual-address space. Virtual address usage is theoretically limited by the address size of your program: 32-bit programs have 4GB of address space; 64-bit programs have vastly more. Practically speaking, the amount of virtual memory that a process can allocate is less than those limits.

Physical memory are the chips soldered to your motherboard, or installed in your memory slots. The amount of physical memory in use at any given time is limited to the amount of physical memory in your computer.

The virtual-memory subsystem maps virtual addresses that your program uses to physical addresses that the CPU sends to the RAM chips. At any particular moment, most of your allocated virtual addresses are unmapped; thus physical memory use is lower than virtual memory use. If you access a virtual address that is allocated but not mapped, the operating system invisibly allocates physical memory and maps it in. When you don't access a virtual address, the operating system might unmap the physical memory.

To take your questions in turn:

• what operations in C++ would inflate virtual memory so much?

new, malloc, static allocation of large arrays. Generally anything that requires memory in your program.

• Is it a problem if my task is using gigs of virtual memory?

It depends upon the usage pattern of your program. If you allocate vast tracks of memory that you never, ever touch, and if your program is a 64-bit program, it may be okay that you are using gigs of virtual memory.

Also, if your memory use grows without bound, you will eventually run out of some resource.

• The stack and heap function variables, vectors, etc. - do those necessarily increase the use of physical memory?

Not necessarily, but likely. The act of touching a variable ensures that, at least momentarily, it (and all of the memory "near" it) is in physical memory. (Aside: containers like std::vector may be allocated on either stack or heap, but the contained objects are allocated on the heap.)

• Would removing a memory leak (via delete or free() or such) necessarily reduce both physical and virtual memory usage?

Physical: probably. Virtual: yes.

Answer 2

Virtual memory is the address space used by the process. Each process has a full view of the 64 bit (or 32, depending on the architecture) addressable bytes of a pointer, but not every byte maps to something real. The operating system manages the table that maps virtual address to real physical memory pages -- or whatever that address really is (no matter it seems to be memory for your application). For instance, for your application an address may point to some function, but in reality it has not yet been loaded from disk, and when you call it, it generates a page fault interruption, that the kernel treats by loading the appropriated section from the executable and mapping it to the address space of your application, so it can be executed.

From a Linux perspective (and I believe most modern OS's):

• Allocating memory inflates virtual memory. Actually using the allocated memory inflates physical memory usage. Do it too much and it will be swapped to disk, and eventually your process will be killed.
• mmaping files will increase only virtual memory usage, this includes the size of the executables: the larger they are, the more virtual memory used.
• The only problem of using up virtual memory is that you may have it depleted. It is mainly an issue on 32 bits system, where you only have 4gb of it (and 1gb is reserved for the kernel, so application data only have 3gb).
• Function calls, that allocates variables on stack, may increase physical memory usage, but you (usually) won't leak this memory.
• Allocated heap variables takes up virtual memory, but will only actually get the physical memory if you read/write on them.
• Freeing or deleting variables does not necessarily reduces virtual/physical memory consumption, it depends on the allocator internals, but usually does.