Committed memory goes to physical RAM or reserves space in the paging file?

1. When I do VirtualAlloc with MEM_COMMIT this "Allocates physical storage in memory or in the paging file on disk for the specified reserved memory pages" (quote from MSDN article http://msdn.microsoft.com/en-us/library/aa366887%28VS.85%29.aspx).

All is fine up until now BUT:

1. the description of Committed Bytes Counter says that "Committed memory is the physical memory which has space reserved on the disk paging file(s)."

2. I also read "Windows via C/C++ 5th edition" and this book says that commiting memory means reserving space in the page file....

The last two cases don't make sense to me... If you commit memory, doesn't that mean that you commit to physical storage (RAM)? The page file being there for swaping out currently unused pages of memory in case memory gets low.

The book says that when you commit memory you actually reserve space in the paging file. If this were true than that would mean that for a committed page there is space reserved in the paging file and a page frame in physical in memory... So twice as much space is needed ?! Isn't the page file's purpos开发者_JAVA百科e to make the total physical memory larger than it actually is? If I have a 1G of RAM with a 1G page file => 2G of usable "physical memory"(the book also states this but right after that it says what I discribed at point 2).

What am I missing? Thanks.

EDIT: The way I see it is perfectly described here: http://support.microsoft.com/kb/555223

"It shows how many bytes have been allocated by processes and to which the operating system has committed a RAM page frame or a page slot in the pagefile (perhaps both)"

but I have read too many things that contradict my belief like those two points above and others like this one for instance: http://blogs.msdn.com/ricom/archive/2005/08/01/446329.aspx

You're misunderstanding the way windows' memory model works. The terminology and the documentation confuse things a bit which doesn't help.

When you commit memory, the OS is providing you with a "commitment" to providing a page to back that memory. It is not actually allocating one, either from physical memory or from the page file, it is simply checking that the "uncommited pages" counter is larger than zero and then decrementing it. If this succeeds the page is marked as commited in your page table.

What happens next depends on whether you access the memory. If you don't, all you did was stop someone else using a page - it was never actually allocated though so it is impossible to say which page you didn't use. When you touch the memory though a page fault is generated. At this point the page fault handler sees that the page is commited and starts to look for a page that can be used on a number of lists of pages the memory manager keeps. If it can't find one then it will force something else out to the page file and give you that page.

So really a page is never actually allocated until you need it, when it is allocated by the page fault handler. The reason the documentation is confusing is that the above description is quite complicated. The documentation has to describe how it works without going into the gory details of how a paging memory manager works and the description is good enough.

Each page of physical memory is backed by either a pagefile (for volatile pages of memory, such as data) or a disk file (for read-only memory pages, such as code and resources). When I say backed, I mean the behavior/process that when the page is needed, the operating system reads it from the disk file, when it is no longer needed, the operating system frees it and flush the content to the disk file.

When you commit a block of virtual memory, the Virtual Memory Manager(VMM) will allocate you an entry into the process's virtual address descriptor (VAD) tree, and reserve the space in the paging file. The physical memory will only be allocated until this block memory is accessed. In the case that page file is disabled, the space will be reserved in the physical memory directly.

Please refer to these links: Managing Virtual Memory and Managing Memory-Mapped Files