Re: Memory fragmentation?

Jean-Marc Desperrier wrote:
> http://msdn2.microsoft.com/en-us/library/aa366794.aspx
> "Page State :
> Free The page is neither committed nor reserved. The page is not 
> accessible to the process. [...]
> A process can use the VirtualFree or VirtualFreeEx function to release 
> reserved or committed pages of its address space, returning them to the 
> free state.
> 
> Reserved The page has been reserved for future use. [...] The page is 
> not accessible and has no physical storage associated with it.
> 
> Committed Physical storage is allocated [...]

When reading the above I had difficulties understanding why there's the 
two levels of non allocated pages, what the use scenarii were for the 
"Reserved" pages, instead of using only "Committed" and "Free" pages.

Reading the description of VirtualFree, it all became a lot clearer:
http://msdn2.microsoft.com/en-us/library/aa366892.aspx

The tree states are there, because there's two level of memory management.

First is the "memory allocation" level where the OS keeps tracks of 
which memory your process owns. You get a block of pages allocated with 
VirtualAlloc (they go from Free to Reserved/Commited), and the process 
owns them until you give the whole block back with VirtualFree.

Then there's a page level tracking of whether each page contains useful 
data or not. If the page is marked as Commited, there's data in it, and 
the OS needs to write the data to swap if it wants to reaffect the page. 
The separation line here is Commited to Free/Reserved.

As a result, when you call VirtualFree, you can decommit any amount of 
memory you want inside the VirtualAlloc block, but you can free only the 
whole block. When you decommit memory with VirtualFree, you must 
remember the area to recommit it later by giving it's address to 
VirtualAlloc (with the flag MEM_COMMIT). VirtualAlloc with the flag 
MEM_RESERVE will never give you back the address of that memory.