Sign up ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

The Windows XP Task Manager can show two different columns regarding the memory usage of processes. One is Mem Usage and the other is VM Size (not shown by default, you need to activate it).

From what I've gathered, VM size is the size of the entire memory space occupied by the process, and Mem Usage is the amount of memory currently committed and used. This assumption is verified by most processes when VM Size is only slightly larger than Mem Usage. For instance, my Outlook currently has 79,724 K in VM Size and 56,600 K in Mem Usage.

But it fails for other processes such as Firefox, which currently has 171,900 K for Mem Usage and only 156,440 K in VM Size. How can a process use more memory than the amount of virtual memory allocated to it?

So maybe my interpretation of these columns is wrong. What do they actually mean?

share|improve this question

6 Answers 6

From the Windows XP Task Manager Help topics:

Memory Usage
In Task Manager, the current working set of a process, in kilobytes. The current working set is the number of pages currently resident in memory. On the Task Manager Processes tab, the column heading is Mem Usage.

Virtual Memory Size
In Task Manager, the amount of virtual memory, or address space, committed to a process. On the Task Manager Processes tab, the column heading is VM Size.

So Mem Usage is the amount of physical RAM currently allocated to a process, and VM Size is the amount of virtual (disk-based) memory currently allocated to a process.

These two counters are independent, although a process that shows a high number in one will usually show a high number for the other. It's just that there's no specific relationship between the two.

share|improve this answer

The definition of "virtual memory" is based on redefining the address space with a contiguous virtual memory addresses to "trick" programs into thinking they are using large blocks of contiguous addresses. source

So sometimes there may be stuff from older tabs laying in the VM address space. For isntance I have 50 tabs open in my browser session right now. If I click on the very first tab chances are that it's sitting in VM waiting to be called on. So it will take a second to draw on the screen. I start to hear the hard drive churn away while it gets that tab out of VM

If that isn't the case. It may be that FF is leaking memory or a extension is the culprit. I had issue like there with the divx web player plugin on a beta version of firefox.

share|improve this answer

The only explanation I see is memory fragmentation. When the process allocates 1 octet, it counts for 1 octet in the VM size. But this 1 octet occupies a page of the physical memory: for windows operating system, a page is 4K. So if the process memory is fragmented and uses a lot of small blocks it can lead to a huge physical memory usage compares to the real memory size allocated.

share|improve this answer
@user30375 Sorry, but this isn't how it works. You can certainly call malloc or HeapAlloc for one byte, but those calls work within the v.a.s. already allocated for the process heap. (Actually heap allocations are always rounded up to at least 8 bytes iirc, but that doesn't change this explanation.) If the heap has enough free space to satisfy that request then the "VM size" doesn't change at all. If it doesn't, the heap manager allocates more private commit for you with VirtualAlloc, and that always happens in page-sized chunks. – Jamie Hanrahan Sep 14 at 16:23

Sorry, but all of these answers miss the mark.

The short answer: the VM size column does not reflect the total virtual address space (“v.a.s.”) defined by the process. It is only a subset of that. Specifically, it is the "private committed" address space (also known as the process's "commit charge").

Whereas the Mem Usage column shows the subset of the process's total virtual address space which is "valid" for the process, i.e. can be accessed without incurring a page fault.

(It's common, but inaccurate, to say that it's the subset that's "in RAM". "Valid" - i.e. in the process working set - means it's in memory and it can be accessed without incurring a page fault. But due to the action of the page caches (standby and modified page lists), plus shared memory, there is usually quite a bit of the process's v.a.s. that's in RAM but requires a page fault to access... but it'll be a "soft" page fault, i.e. one that does not involve disk I/O. Once resolved the page is in the process working set and further references to it won't incur faults... unless it is later aged out of the working set.)

So if VM size is not all of the process's virtual size, where's the rest of it? The other major contributor to a process's total virtual address space is mapped address space. The difference between them is that private committed v.a.s. - I'll just call it private from now on; there is no such thing as private non-committed - is backed by the pagefile, whereas mapped v.a.s. is backed by the files it's mapped to.

"Backed by" means that the portion that can't be kept in RAM is kept in those files.

There is also nonpaged virtual space (very small) and, possibly, "physically mapped" memory (very uncommonly used).

The total of all of these could be called the total accessible virtual address space of the process, because all of it can be referenced without incurring a memory access violation (but, for the pageable parts, could incur a page fault, but that doesn't mean they're not accessible; it just means the first access takes a little longer).

The first two portions, private committed and mapped address space, could be called the total pageable virtual address space.

The Mem Usage column should have been called "Working Set (total)". It will normally be smaller than the total pageable v.a.s. Unfortunately XP's Task Manager doesn't have a counter for the latter. But anyway, the Mem Usage column shows how much of the total pageable virtual address space can be referenced by the process without incurring a page fault. Some of this will be physical pages associated with private committed pages, and some with mapped pages.

If XP's task manager had a few more columns available, you would see the relationships you expect to see: Total pageable v.a.s. (for which there is not now a counter) should never be smaller than total working set (called Mem Usage in XP); and the private committed v.a.s. should never be smaller than the private portion of the process working set.

Task manager in later versions of Windows does have a few more of these counters. The Process Explorer tool from Sysinternals has even more. In Process Explorer:

"Working Set" is the process' total working set

"WS Shareable" is the subset of the total that is potentially shared with other processes (it's a subset of the mapped v.a.s.)

"WS Shared" is the subset of "WS Shareable" that actually is being shared with other processes, i.e. it's in some other processes' working sets too.

"WS Private" is the subset of "Working Set" that is not shareable with other processes. It's associated and a subset of the process's private committed v.a.s.

"Private Bytes" is the process's private committed v.a.s. You'll notice it's always larger than "WS Private", which is the relationship you're looking for.

"Virtual Size" is the total amount of not-free v.a.s. in the process. This includes private and shared v.a.s., but also "reserved" address space. "Reserved" is not accessible, occupies almost no physical space anywhere, but does reserve ranges of virtual addresses. It does not include physically mapped regions (aka "AWE" memory). On x64 under Win 8.1 and later it may also include a gargantuan area (2,147,483,648 K, or 2 TiB) set aside for a new feature called "Control Flow Guard". For information on that, see this entry at Alex Ionescu's blog.

share|improve this answer
You've used the abbreviation 'v.a.s.' throughout your answer without defining it. It would help if you could do that. – boot13 Sep 13 at 12:25
Assuming you're right, and my answer 'misses the mark', I wonder if you could point out exactly where the Task Manager help is incorrect? I suppose there's not much point in reporting a documentation problem in Windows XP to Microsoft, but it would be nice to know what exactly they got wrong there. – boot13 Sep 13 at 12:45
@boot13 I have to ask why you asked me to define it, then edited my answer to remove the definition I added? – Jamie Hanrahan Sep 13 at 12:45
Yeah, I noticed that too. I didn't do it intentionally. We were just both editing at the same time. But I thought that wasn't supposed to happen with Stack Exchange sites! Anyway, sorry, it wasn't intentional. – boot13 Sep 13 at 12:46
You wrote "VM Size In Task Manager, the amount of virtual memory, or address space, committed to a process. [...] VM Size is the amount of virtual (disk-based) memory currently allocated to a process. But it isn't. It's only the private committed. Mapped is also considered "committed" (and it is certainly disk-backed; while private committed is only disk-backed if there's a pagefile). And re "Mem Usage is the amount of physical RAM currently allocated to a process", not all of it is exclusively allocated to the process, but that's what most think of when they hear that word. – Jamie Hanrahan Sep 13 at 12:53

Just guessing, may it be shared memory blocks that were allocated by Firefox, then given away to some other task and unmapped by FF but still counted as owned by it?

share|improve this answer

VM size in task manager refers to how much it is paging to the actual virtual memory (swap file) on disk. Linky

share|improve this answer
Sorry, but no. If this were true then the "VM size" column would always be zero on systems that don't have a pagefile. But it isn't. The article you linked is flatly wrong. – Jamie Hanrahan Sep 14 at 16:25

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.