views:

662

answers:

4

Hello everyone,

I am learning from here about Windows 32-bit virtual memory page mapping,

(I am targeting modern Windows versions, like Vista, Win 7, Server 2003/2008 32-bit versions.)

http://blogs.msdn.com/ericlippert/archive/2009/06/08/out-of-memory-does-not-refer-to-physical-memory.aspx

Two confusions,

  1. user space virtual memory space is limited to 2G normally, but physical disk page storage could be much larger than 2G. Since there are more disk pages than virtual memory pages, so in theory more than one disk pages could be mapped to one virtual address page. If user request to access some virtual address, how did memory manager know which disk page should be accessed if more than one disk pages are mapped to one virtual address page?

  2. I do not know why there is restrictions like byte[] array must use continuous virtual memory space. I think in theory even if we only allocate 500M virtual space address, we can re-use such virtual space address to continue to map/unmap disk page file to consume as much as we want, even larger than 2G.

Any ideas?

thanks in advance, George

+1  A: 

(There is a switch for some versions of Windows to enable 3G for user programs, but we'll ignore that for purposes of this discussion, since the principle is the same.)

32bit programs can only access 4G of memory, since that's the largest pointer you can fit in 32 bits. When a program runs, some of the memory space is mapped to itself, and some is mapped into the operating system. Otherwise, when you call into the operating system, the operating system code couldn't see both its own memory and the program memory at the same time.

So your program doesn't get all of the memory, and hence the restrictions on contiguous allocation.

Now, different programs can have different subsets of all of the addressable memory. Some 32bit chips allow physically more than 4G of memory, but still, any given process, since it's 32bits, can only "see" directly up to 32bits-worth, or 4G, at a time, some of which belongs to the process (2G), and some to the operating system (2G) for managing the program and other programs.

That's as simple an explanation as I can give; see Virtual Memory for a longer and more technical explanation.

lavinio
Thanks lavinio, your reply is great. But it does not answer my question item 1 which is dealing with when multiple physical disk pages are mapped to one virtual memory page, and when we access the virtual memory page, how did memory manager know which physical disk page should be used? Any ideas?
George2
BTW: if your suggested reading for Windows? I did not find any words mentioning it is for Windows. I think different OS are different for memory management. :-)
George2
The same principles apply for Windows or other operating systems.
lavinio
Virtual memory *space* is made up of lots of virtual *pages*. Any of those pages can be backed by a same-sized piece of physical memory or disk. A piece of memory managed by the operating system in conjunction with the CPU's memory manager keeps a map of what physical memory and what disk backing store belongs where.
lavinio
Hi lavinio, here is a scenario which describes my confusion of item #1. Suppose in virtual memory we have a disk page D1 mapped to virtual page V1. Then at some time, memory manager needs to load more disk page and reuse the same virtual page V1 to load disk page D2. When program access virtual page V1, how did memory manager know whether D1 or D2 data should be accessed? Suppose D1 is requested by Thread 1 and D2 is requested by thread 2. How did memory manager tracks if more disk pages are mapped to the same virtual page? Since in 32-bit machine, virtual memory is 4G but disk could be
George2
(continue) much larger. There are much chances more than one disk pages are mapped to one virtual pages and makes the scenario I described happen. Any ideas how memory manager solves this issue?
George2
+2  A: 

Mark Russinovich wrote good article Pushing the Limits of Windows: Virtual Memory. I think you should read it to clearly understand how it is works.

Kirill V. Lyadvinsky
Thanks JIa3ep, I read this document and it is great! But it does not answer my question #1 -- which is dealing with when multiple physical disk pages are mapped to one virtual memory page (since disk could be mucher larger than virtual address space 4G), and when we access the virtual memory page, how did memory manager know which physical disk page should be used? Any ideas?
George2
here is a scenario which describes my confusion of item #1. Suppose in virtual memory we have a disk page D1 mapped to virtual page V1. Then at some time, memory manager needs to load more disk page and reuse the same virtual page V1 to load disk page D2. When program access virtual page V1, how did memory manager know whether D1 or D2 data should be accessed? Suppose D1 is requested by Thread 1 and D2 is requested by thread 2. How did memory manager tracks if more disk pages are mapped to the same virtual page? Since in 32-bit machine, virtual memory is 4G but disk could be
George2
(continue) much larger. There are much chances more than one disk pages are mapped to one virtual pages and makes the scenario I described happen. Any ideas how memory manager solves this issue?
George2
There is no static connection between virtual memory pages and disk space. Memory manager dynamically maps data on disk to virtual memory pages. If there program wants to map all disk data at once and there is not enough virtual memory, it'll get an error.
Kirill V. Lyadvinsky
Thanks JIa3ep, I want to confirm with you that if a virtual page address range is mapped to a disk page, and your point is if this virtual page is still used by the process, OS memory manager will never map this virtual page address range to other disk page? If so, I think total disk page can never exceeds 4G? My understanding correct?
George2
If my understanding is correct, then the points from the document I posted in my original question post is not correct, it said there are unlimited space of virtual memory, which is only limited by disk space, but from the above statements, I think the max disk page could be used is 4G for each process. Any comments?
George2
Yes, virtual memory for each process is limited by 4Gb in theory. But on practice limit is 2Gb. Other 2Gb are reserved for OS needs. That is correct for 32-bit OS.
Kirill V. Lyadvinsky
Thanks, JIa3ep. My confusion is for page (either disk or RAM page). I am wondering for one process, could the total disk/RAM page be larger than 4G? I think the virtual memory address space is max 4G, so for each process the mapped disk/RAM page could not be larger than 4G?
George2
If yes, then this MSDN document is wrong, http://blogs.msdn.com/ericlippert/archive/2009/06/08/out-of-memory-does-not-refer-to-physical-memory.aspx because it said for each process the only memory limitation is disk size (used for paging), so if disk is 200G, then the memory for one process used could be 200G.
George2
I think it is talking about PAE (http://en.wikipedia.org/wiki/Physical_Address_Extension)
Kirill V. Lyadvinsky
I'd not recommend to use PAE. If your program need more than 2Gb of memory, it is more appropriate to use 64-bit OS.
Kirill V. Lyadvinsky
+1  A: 

byte (or any other) arrays must use contiguous address space, in this case contiguous virtual address space. This is an area that can make fragmentation becomes an issue, and is actually exacerbated by virtualization of memory. Since the various 'redirections' inherent in a such a system system and the performance considerations in making it efficient lead to actual allocation of physical address space mapped to virtual address space in chunks (commonly pages).

So requesting a 10 byte chunk of virtual address space might actually lead to a whole 4K page being reserved and mapped. Since the physical memory within the page must be contiguous this can lead to a whole 4K of virtual address space being 'blocked off'.
Multiple small allocations can be placed within one page (and good memory managers will try to achieve this) but none the less address space has in effect been reserved over and above what was strictly required. Consider the allocation of a single byte at the start f a page, then 4K - 2 bytes followed by another single byte. This occupies (efficiently) the whole page.
Consider if the middle allocation is no longer necessary, and is thus freed. Until the 'top' and 'tail' values are either freed or moved elsewhere a gap has been created in the virtual address space which can only be filled by something < 4K-1 bytes in size. If sufficient of these sorts of things occur the contiguous regions in virtual address space shrink much faster than the actual total really used memory does.

You are correct in that there is nothing stopping you, the user, mapping your (limited in 32bit land) address space to the much larger disk or memory space that the CPU/OS supports . Some chips make this possible with more than 4GB of physical address space via mechanisms like PAE.

Windows itself provides an API to deal with most aspects of 'changing the mapping of your address space to get a different 'window' onto a wider pool (be it via things like PAE, running WoW64, disk or a mixture). This is called AWE. But mechanisms like this have existed for years (as those who remember the days of EMS with conventional memory or indeed the days of segmented memory.

Even without CPU and OS support you can still do it yourself by hand by a variety of techniques (see below).

A great deal of the more complex aspects of this in windows were dealt with by ever interesting Raymond Chen.

ShuggyCoUk
Thanks ShuggyCoUk, your reply answered my question item #2 quite well, for my question #1, I still have confusion -- which is dealing with when multiple physical disk pages are mapped to one virtual memory page (since disk could be mucher larger than virtual address space 4G), and when we access the virtual memory page, how did memory manager know which physical disk page should be used? Any ideas?
George2
here is a scenario which describes my confusion of item #1. Suppose in virtual memory we have a disk page D1 mapped to virtual page V1. Then at some time, memory manager needs to load more disk page and reuse the same virtual page V1 to load disk page D2. When program access virtual page V1, how did memory manager know whether D1 or D2 data should be accessed? Suppose D1 is requested by Thread 1 and D2 is requested by thread 2. How did memory manager tracks if more disk pages are mapped to the same virtual page? Since in 32-bit machine, virtual memory is 4G but disk could be
George2
(continue) much larger. There are much chances more than one disk pages are mapped to one virtual pages and makes the scenario I described happen. Any ideas how memory manager solves this issue?
George2
Virtual Memory is NOT the same as virtual address space. to the MMU a virtual page maps to an actual page which may/may not be on disk but it only maps to one. This mapping can be *changed* (and something else remember this) but at any point virtual page maps to either nothing or to a single actual page. Also remember the virtual address space is *per process*. sharing pages between process is also fine, it's still one to one in the direction that matters to the MMU/OS which is tranlating virtual address into an actual page
ShuggyCoUk
Thanks ShuggyCoUk, I want to confirm with you that if a virtual page address range is mapped to a disk page, and your point is if this virtual page is still used by the process, OS memory manager will never map this virtual page address range to other disk page? If so, I think total disk page can never exceeds 4G? My understanding correct?
George2
If my understanding is correct, then the points from the document I posted in my original question post is not correct, it said there are unlimited space of virtual memory, which is only limited by disk space, but from the above statements, I think the max disk page could be used is 4G for each process. Any comments?
George2
You can allocate memory but NOT map it to your virtual address space (see the linked article from Raymond Chen).Also the *per process* virtual address space is separate (that's kind of the point) so 10 processes all mapping 1GB gives you 10GB potential VM usage (some pages may be shared but you get the idea)
ShuggyCoUk
Thanks ShuggyCoUk, but for one process, could it use more than 4G memory page (disk + RAM page), also considering the shared scenario?
George2
If yes, then this MSDN document is wrong, http://blogs.msdn.com/ericlippert/archive/2009/06/08/out-of-memory-does-not-refer-to-physical-memory.aspx because it said for each process the only memory limitation is disk size (used for paging), so if disk is 200G, then the memory for one process used could be 200G.
George2
the memory *yes* the address space no. the two are *entirely separate* (which is what that blog post is trying to get across). Also Eric's stuff is excellent but I don't think he would want you to call it an 'msdn documment' (even if it is better than most f them). I fear you are not under standing the key separation of *memory* and *address space* and I'm running out of analogies.
ShuggyCoUk
A: 

The total virtual address space available to a process is 4GB. The upper 2GB of this is common to all processes and is accessible only to system level components. The lower 2GB is private to each process, it is not shared. This has absolutely nothing to do with the size of RAM. There can be far more than 2GB of disk pages mapped to user processes. Since the 2GB process space is private the total address space for all processes will be far more than 2GB. It is impossible, even in theory, for more than one disk page to be mapped to one virtual address in the same process.

Larry Miller