VM Size is ridiculous

Virtual Memory, which is an age-old technique for extending the apparent memory usable by an application.

Though, 217 GB seems awfully healthy, unless you have a boatload of applications running or you have some application that for some reason has been doing malloc()'s by the ton.

I assume that by looking at the process window of Activity Monitor and sorting on Virtual memory size you figured out what was doing it?

alin0steglinski wrote:

unfortunately there is nothing in activity monitor that would cause me to have a 217gb VM size... what to do what to do!?

Unless you are actually seeing a problem, i.e., low disk warnings, or anything like that, I wouldn't worry about it. It's kind of like inactive memory (the blue wedge) which is inactive because it has been recently used by an application that might use it again, but if need be can be allocated to an active process. After a certain time, inactive memory is returned to the free category, but it was, in essence, free all of the time.

VM on my particular system, with maybe 10 apps active on the dock right now, is running around 17-18 GByte. I can account for most of it in the activity monitor, but I don't really consider it much of an issue, as it is less than six percent of the free space on my boot volume.

alin0steglinski wrote:

I guess... but my god is it huuuge. and its HALF of my boot volume. i mean come on! What the heck should I do to remedy this issue. I've tried reinstalling many times so that wont work.

Just out of curiosity, what does you boot volume show for free space? Since you are running Snow Leopard, I'm wondering if VM is treated a bit differently, as in maybe a Max limit of available VM as a fraction of free space, maybe. Looking at my Tiger Activity Monitor Help topics, I see, for instance the following statement: "VM, or virtual memory, is hard disk space that can be used as memory." (italics added) This then is actually an upper limit of how much VM the system will allow. That may be different in Snow Leopard, in the sense that the OS appears to set a higher limit.

It's only used when it is used. If you take up more disc space with new files, then I suspect the VM limit will be reduced. Unless you are running some applications that may have huge amounts of data active, I don't think that VM will ever be a problem. When you start seeing a lot of Page Outs showing up, then you will be seeing VM actually being used.

If you want to see if VM is even being used, find a process in Activity Monitor probably called dynamic_pager. That's the process controlling the swapmeet. Right now, on my machine, which has been up for 2 days, 10 hrs, dynamic_pager shows an accumulated CPU time of 00.000 seconds. That is what I would expect with zero pageouts. So even though my VM size is between 15 and 20 GByte, I am not using one block of disk right now for virtual memory, or so it would seem.

Again, that number is what you can use, not what you are actually using.

Just ignore Virtual Memory size. It is a number only a "Kernel Developer" could love, and very few of those even care.

The Activity Monitor VM Size is just adding up the highest address of every running application. And since your applications can be 64 bit apps, they could have a high address of 18,446,744,073,709,551,615 :-)

Most virtual address space is empty. I don't mean it has memory that is not used, I mean it has no real memory nor swap space associated with it. Nothing. Nada. Zilch!

When an application starts, it need address space for the program's code, for the program's data, for any application frameworks and shared libraries, and for dynamically allocated memory the program may need (more on this in a moment).

When shared application frameworks and libraries are mapped into the program's address space it is generally given its own unique chunk of address space that is NOT contiguous with the program's code, nor other shared frameworks and libraries. So for each mapped shared framework and library there will generally be a gap of unused virtual addresses. These virtual addresses may never get used, but since they do not take up real memory nor any disk space, it is not a problem, and it makes the operating system's life easier, especially if the operating system can place their shared frameworks and libraries in every application that uses them at the same virtual address. And it makes loading those shared frameworks and libraries much faster for you, as the operating system does not need to do address fixup for each shared framework and library, which then saves real memory for address fixup vectors. And the only cost is some empty virtual address space.

Dynamically allocated memory. The program's stack dynamically grows as the program calls different subroutines and those subroutines need local memory. This local memory comes from the stack. If a program calls almost no subroutines, it might use almost no stack space. But if a program calls lots of deeply nested subroutines, and if some of those subroutines need lots of local memory, a program's stack may grow to 100's of megabytes, or even gigabytes. The operation system does not know in advance how large a program's stack is going to grow, so the operating system need to map the application's stack into virtual memory so that it has room to grow contiguously.

An application can also ask the operating system to give it chunks of memory that have to be mapped into the program's virtual address space. The operating system will get the virtual address space for allocations like this from existing ranges of unused virtual address space if it can, but if it cannot, then the operating system will just grow the highest virtual address range and map the program's request from the new virtual address space.

But wait there's more! A program does not need to accept the dynamically allocated memory at the virtual address specified by the operating system. It can ask the operating system to give it the memory at a specific address. If that address is beyond the current highest virtual address currently being used the the application, then the OS will just extend the application's virtual address space so it can give the app the virtual address it wants. The OS will not put anything in the gap between the old highest address and the start of the dynamically allocated memory virtual address. And that gap will not require memory nor swap space as it is not being used for anything.

Anyway, chances are most of your virtual address space is unused, and just comes from the collection of shared frameworks and libraries, or from an application asking for some dynamically allocated memory at a specific high address.

OK, unused Virtual Memory it not 100% free. The operating system does have to keep track of it, and generally this costs 8 bytes for every page (4096 bytes) of unused virtual address space. But that is a 512 to 1 ratio, and while I do not know what Mac OS X is using for virtual memory page tables, I know there are sparse page table algorithms available so it is not necessary to even worry about some parts of the unused virtual address space.

If you really want to know what is mapped into what parts of a program and find the parts of used virtual address space vs unused gaps, you can play with the Applications -> Utilities -> Terminal and run the vmmap command (man vmmap). You may need to use the sudo command to access the virtual memory map of some applications.

Bottom line. Just ignore it, most kernel developer do, and they are the only ones that come even close to caring about VM Size.