虽然Windows的32位版本可以支持多达128GB物理内存,但每个32位用户
进程在默认情况下只有2GB虚拟地址空间(在Boot.ini中使用/3GB和/
USERVA开关时,此限制值可配置为3GB)。
注意:当创建一个进程时,操作系统会为该进程分配一个4GB大小的虚拟进程地址空间。之所以是4GB,是因为在32位的操作系统中,一个指针长度是4字节,而4字节指针的寻址能力是从0x00000000~0xFFFFFFFF,最大值0xFFFFFFFF表示的即为4GB大小的容量。与虚拟地址空间相对的,还有一个物理地址空间,这个地址空间对应的是真实的物理内存。如果你的计算机上安装了512M大小的内存,那么这个物理地址空间表示的范围是0x00000000~0x1FFFFFFF。当操作系统做虚拟地址到物理地址映射时,只能映射到这一范围,操作系统也只会映射到这一范围。当进程创建时,每个进程都会有一个自己的4GB虚拟地址空间。要注意的是这个4GB的地址空间是“虚拟”的,并不是真实存在的,而且每个进程只能访问自己虚拟地址空间中的数据,无法访问别的进程中的数据,通过这种方法实现了进程间的地址隔离。那是不是这4GB的虚拟地址空间应用程序可以随意使用呢?很遗憾,在Windows系统下,这个虚拟地址空间被分成了4部分:NULL指针区、用户区、64KB禁入区、内核区。应用程序能使用的只是用户区而已,大约2GB左右(最大可以调整到3GB)。内核区为2GB,内核区保存的是系统线程调度、内存管理、设备驱动等数据,这部分数据供所有的进程共享,但应用程序是不能直接访问的。
为了允许一个32位进程分配和访问更多的物理内存,突破这一受限地址空
间所能表达的内存范围,Windows提供了一组函数,称为地址窗口扩展(
AWE , Address Windowing Extensions)。例如,在一个具有8GB物理内
存的Windows 2000 Advanced Server系统上,一个数据库服务器应用程
序有可能使用AWE来分配和使用6GB内存作为数据库缓存。
AWE函数分配和使用内存:
1.分配所要使用的物理内存。
2.创建一个虚拟地址空间区域,把它当作一个窗口来映射物理内存的多个
视图。
3.将物理内存的视图映射到窗口中。
一个应用程序想要分配物理内存,可以调用Windows函数
AllocateUserPages(这个函数要求“lock pages in memory[将页面锁在内存中]
”用户权限)。然后,应用程序使用VirtualAlloc函数以及MEM_PHYSICAL标
志,在进程地址空间的私有部分创建一个窗口,该窗口被映射至原先分配
的物理内存中的全部或一部分。之后,AWE分配的内存几乎可以与所有的
Windows API一起使用(当然,不能与如Microsoft DirectX函数一起使用)
。
如果一个应用程序在它的地址空间中创建一个256MB的窗口,并且分配4
GB的物理内存(当然系统物理内存要超过4GB),此应用程序就可以使用
MapUserPhysicalPages或MapUserPhysicalPagesScatter函数,将4GB物理
内存映射到256MB窗口中,从而访问此4GB物理内存中的任何部分。
应用程序的虚拟地址空间大小决定了该应用程序通过一次映射可以访问的
物理内存的数量。
Windows的所有版本都有AWE功能,而且不管一个系统有多少物理内存,
AWE功能都可以使用。当然,在超过2GB物理内存的系统上,AWE才是最
有用的。(哈哈,如果内存本来就是捉襟见肘,还能用AWE吗?)因为对
于一个32位进程来说,这是直接使用超过2GB内存的惟一途径。(所以一
般拥有4GB及以上内存,就推荐使用64位操作系统)
另一种用途是出于安全性考虑:AWE内存永远不会被换出,AWE内存中的
数据不会在页面文件中有拷贝,从而避免坏蛋将系统重新引导到另一个操
作系统中,通过检查页面文件来获取数据。
对于通过AWE函数分配和映射的内存,有以下限制:
1.进程之间不能共享页面;
2.同样的物理页面不能被映射至同一进程的多个虚拟地址;
3.老版本的Windows中,对页面的保护仅限于读/写;在Windows Server
2003 Service Pack1及以后的版本中,也支持不可访问和只读模式。
进程在默认情况下只有2GB虚拟地址空间(在Boot.ini中使用/3GB和/
USERVA开关时,此限制值可配置为3GB)。
注意:当创建一个进程时,操作系统会为该进程分配一个4GB大小的虚拟进程地址空间。之所以是4GB,是因为在32位的操作系统中,一个指针长度是4字节,而4字节指针的寻址能力是从0x00000000~0xFFFFFFFF,最大值0xFFFFFFFF表示的即为4GB大小的容量。与虚拟地址空间相对的,还有一个物理地址空间,这个地址空间对应的是真实的物理内存。如果你的计算机上安装了512M大小的内存,那么这个物理地址空间表示的范围是0x00000000~0x1FFFFFFF。当操作系统做虚拟地址到物理地址映射时,只能映射到这一范围,操作系统也只会映射到这一范围。当进程创建时,每个进程都会有一个自己的4GB虚拟地址空间。要注意的是这个4GB的地址空间是“虚拟”的,并不是真实存在的,而且每个进程只能访问自己虚拟地址空间中的数据,无法访问别的进程中的数据,通过这种方法实现了进程间的地址隔离。那是不是这4GB的虚拟地址空间应用程序可以随意使用呢?很遗憾,在Windows系统下,这个虚拟地址空间被分成了4部分:NULL指针区、用户区、64KB禁入区、内核区。应用程序能使用的只是用户区而已,大约2GB左右(最大可以调整到3GB)。内核区为2GB,内核区保存的是系统线程调度、内存管理、设备驱动等数据,这部分数据供所有的进程共享,但应用程序是不能直接访问的。
为了允许一个32位进程分配和访问更多的物理内存,突破这一受限地址空
间所能表达的内存范围,Windows提供了一组函数,称为地址窗口扩展(
AWE , Address Windowing Extensions)。例如,在一个具有8GB物理内
存的Windows 2000 Advanced Server系统上,一个数据库服务器应用程
序有可能使用AWE来分配和使用6GB内存作为数据库缓存。
AWE函数分配和使用内存:
1.分配所要使用的物理内存。
2.创建一个虚拟地址空间区域,把它当作一个窗口来映射物理内存的多个
视图。
3.将物理内存的视图映射到窗口中。
一个应用程序想要分配物理内存,可以调用Windows函数
AllocateUserPages(这个函数要求“lock pages in memory[将页面锁在内存中]
”用户权限)。然后,应用程序使用VirtualAlloc函数以及MEM_PHYSICAL标
志,在进程地址空间的私有部分创建一个窗口,该窗口被映射至原先分配
的物理内存中的全部或一部分。之后,AWE分配的内存几乎可以与所有的
Windows API一起使用(当然,不能与如Microsoft DirectX函数一起使用)
。
如果一个应用程序在它的地址空间中创建一个256MB的窗口,并且分配4
GB的物理内存(当然系统物理内存要超过4GB),此应用程序就可以使用
MapUserPhysicalPages或MapUserPhysicalPagesScatter函数,将4GB物理
内存映射到256MB窗口中,从而访问此4GB物理内存中的任何部分。
应用程序的虚拟地址空间大小决定了该应用程序通过一次映射可以访问的
物理内存的数量。
Windows的所有版本都有AWE功能,而且不管一个系统有多少物理内存,
AWE功能都可以使用。当然,在超过2GB物理内存的系统上,AWE才是最
有用的。(哈哈,如果内存本来就是捉襟见肘,还能用AWE吗?)因为对
于一个32位进程来说,这是直接使用超过2GB内存的惟一途径。(所以一
般拥有4GB及以上内存,就推荐使用64位操作系统)
另一种用途是出于安全性考虑:AWE内存永远不会被换出,AWE内存中的
数据不会在页面文件中有拷贝,从而避免坏蛋将系统重新引导到另一个操
作系统中,通过检查页面文件来获取数据。
对于通过AWE函数分配和映射的内存,有以下限制:
1.进程之间不能共享页面;
2.同样的物理页面不能被映射至同一进程的多个虚拟地址;
3.老版本的Windows中,对页面的保护仅限于读/写;在Windows Server
2003 Service Pack1及以后的版本中,也支持不可访问和只读模式。
本文探讨了32位Windows操作系统如何管理和分配物理内存给进程,特别是在面对有限的地址空间时,如何通过地址窗口扩展(AWE)技术允许进程访问超过2GB的物理内存。

被折叠的 条评论
为什么被折叠?



