//如何在32位程序中突破地址空间4G的限制
//首先要获得内存中锁定页的权限 #define _WIN32_WINNT 0x0501 //xp系统
#include <windows.h>
#include <iostream> using std::cout;
using std::endl; BOOL AWESetLockPagesPrivilege( HANDLE hProcess, BOOL Enable )
{
HANDLE Token = NULL;
BOOL Result = FALSE;
TOKEN_PRIVILEGES Info = { }; // 打开令牌
Result = OpenProcessToken ( hProcess, TOKEN_ADJUST_PRIVILEGES, &Token );
if( !Result )
return FALSE; // 设置权限信息
Info.PrivilegeCount = ;
Info.Privileges[].Attributes = Enable? SE_PRIVILEGE_ENABLED : ; // 获得锁定内存权限的ID
Result = LookupPrivilegeValue ( NULL,SE_LOCK_MEMORY_NAME,&(Info.Privileges[].Luid));
if( !Result )
{
CloseHandle( Token );
return FALSE;
} // 调整权限
Result = AdjustTokenPrivileges ( Token, FALSE,(PTOKEN_PRIVILEGES) &Info,, NULL, NULL);
if( ( !Result ) || ( GetLastError() != ERROR_SUCCESS ) )
{
CloseHandle( Token );
return FALSE;
} // 成功返回
CloseHandle( Token );
return TRUE;
} int main()
{ if( !AWESetLockPagesPrivilege( GetCurrentProcess(), TRUE) )
{
// 输出错误信息
cout<<"do not have privilege!"<<endl;
}
const ULONG_PTR ulRAMByte = *; PVOID pvWindow = VirtualAlloc(NULL, ulRAMByte, MEM_RESERVE|MEM_PHYSICAL, PAGE_READWRITE); SYSTEM_INFO sinf; GetSystemInfo(&sinf); ULONG_PTR ulRAMPages = ulRAMByte/sinf.dwPageSize; cout<<"original: "<<ulRAMPages<<endl;
ULONG_PTR aRAMPages[/]; if(!AllocateUserPhysicalPages(GetCurrentProcess(), &ulRAMPages,aRAMPages))
cout<<"fail to allocate!"<<endl;
cout<<GetLastError()<<endl; cout<<"after allocate: "<<ulRAMPages<<endl;
MapUserPhysicalPages(pvWindow, ulRAMPages, aRAMPages);
Sleep();
FreeUserPhysicalPages(GetCurrentProcess(), &ulRAMPages, aRAMPages); VirtualFree(pvWindow, , MEM_RELEASE);
return ;
}

为运行以上代码,博主建立了实验环境,如下:

  1.操作系统:Microsoft windows server 2003 企业版SP2

  2.vs:vs 2003

  3.系统分配内存为:8GB

  由于该环境为在hyper-v上建立的虚拟机,内存为热添加,所以/PAE开关自动启用,没有手工启用/PAE开关.

运行结果如下:

    

众所周知,所有的32位应用程序都有4GB的进程地址空间,因为32位地址最多可以映射4GB的内存(对于虚拟地址空间概念不 太熟悉的朋友建议去看一下《Windows核心编程》这本书)。对于Microsoft Windows操作系统,应用程序可以访问2GB的进程地址空间(32位Linux可以访问3GB地址空间),这就是称为用户模式的虚拟地址空间。这 2GB的用户模式虚拟地址空间位于4GB地址空间的低一半,而与之相对应的高一半2GB地址空间由操作系统内核使用,因此被成为内核模式的虚拟地址空间。 在一个进程中,所有的线程读共享相同的2GB用户模式虚拟地址空间。 对于一般的应用程序来说,2GB的地址空间是足够使用的了,但是对于一些特殊的需要使用海量内存的应用程序(典型的例子是数据库系统)来说,2GB的地址 空间就远远不够了。为了缓解地址空间的不足,微软提供了一个权宜的解决方案,所有从Windows 2000 Server开始的操作系统版本都提供了一个boot.ini启动开关(/3GB),可以为应用程序提供访问3GB的进程地址空间的能力,从而将内核模式 的地址空间限定为1GB。以下就是一个开启了3GB选项的boot.ini文件示例:

[boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)WINDOWS="Windows Server 2003, Enterprise" /fastdetect  /3GB

虽然使用/3GB选项能够将用户模式的地址空间扩大50%(从2GB增加到3GB),但是对于数据库系统这样的应用程序来说,这1GB的地址空间的增加只 能是杯水车薪,并不能解决多少问题,而且由于操作系统内核只能使用1GB地址空间,这样可能会给操作系统的运行带来一定的负面影响,因此除非没有更好的解 决方案,是不建议使用/3GB方式的。

鉴于像数据库系统这样的应用程序对海量内存的需求,Intel公司也觉得4GB的内存不够用,因此就将CPU芯片中内存地址线由32根扩展到了36根(即 最多64GB),这就是所谓的物理地址扩展(PAE:Physical Address Extension)。PAE使得操作系统或应用程序能够最多使用64GB的物理内存,对于Windows系统(2000以上)来说,只需在 boot.ini文件中使用/PAE选项即可(类似于上面的/3GB选项)。需要提醒大家的是,如果没有在boot.ini文件中使用/PAE选项,那么 即使计算机已经配置了超过4GB的物理内存,在Windows操作系统中也不能使用超过4GB的那些内存(事实上,根据我的经验,如果没有使用/PAE选 项,Windows系统最多只能识别3.25GB的物理内存,我也不清楚为什么不是4GB?如果有知道的,请告诉我一声)。 虽然PAE使得在应用程序中使用超过4GB的物理内存成为可能,但是由于32位应用程序的虚拟地址空间并不随着物理内存的增大而有任何变化,这意味着你不 可能使用类似VirtualAlloc( GetCurrentProcess,2GB,...,...)这样的函数=调直接分配接近用户模式地址空间大小的内存区域。为了突破32位地址空间的限 制,需要使用一种被成为地址窗口扩展(AWE:Address Windowing Extensions)的机制(参见上图)。 AWE是Windows的内存管理功能的一组扩展,它使应用程序能够使用的内存量超过通过标准32位寻址可使用的2~3GB内存。AWE允许应用程序获取 物理内存,然后将非分页内存的视图动态映射到32位地址空间。虽然32位地址空间限制为4GB,但是非分页内存却可以远远大于4GB。这使需要大量内存的 应用程序(如大型数据库系统)能使用的内存量远远大于32位地址空间所支持的内存量。 在使用AWE机制时,需要注意以下几点: (1)AWE允许在32位体系结构上分配超过4GB的物理内存,只有当系统可用物理内存大于用户模式的虚拟地址空间时,才应该使用AWE。 (2)若要使32位操作系统支持4GB以上的物理内存,必须在Boot.ini文件启用/PAE选项。 (3)若在Boot.ini文件中启用了/3GB选项,则操作系统最多能够使用16GB的物理内存,因此如果实际的物理内存超过16GB,必须确保不使用/3GB选项。 (4)使用AWE分配的内存是非分页的物理内存,这意味着这部分内存只能由分配的应用程序独占使用,不能由操作系统或其他程序使用,直到这些内存被释放为止,这与通常的VirtualAlloc函数分配的虚拟内存存在显著的不同,它不会参与分页替换。

在Windows中,跟AWE相关的API函数有以下几个:

BOOL AllocateUserPhysicalPages( HANDLE hProcess, PULONG_PTR NumberOfPages, PULONG_PTR UserPfnArray );
BOOL WINAPI AllocateUserPhysicalPagesNuma( HANDLE hProcess, PULONG_PTR NumberOfPages, PULONG_PTR PageArray, DWORD nndPreferred );
BOOL MapUserPhysicalPages( PVOID lpAddress, ULONG_PTR NumberOfPages, PULONG_PTR UserPfnArray );
BOOL MapUserPhysicalPagesScatter( PVOID* VirtualAddresses, ULONG_PTR NumberOfPages, PULONG_PTR PageArray );
BOOL FreeUserPhysicalPages( HANDLE hProcess, PULONG_PTR NumberOfPages, PULONG_PTR UserPfnArray );

各个函数的具体参数含义可以参考MSDN,其中AllocateUserPhysicalPagesNuma是Windows Vista和Windows 2008 Server新增的函数,用于支持NUMA(非一致性内存访问)。以下就简单说一下如何使用这几个API函数来达到使用超过4GB的内存。 使用AllocateUserPhysicalPages函数分配需要的物理内存,使用方式如下:

ULONG_PTR NumberOfPages = xxx; // 需要分配的内存页数
ULONG_PTR *aPFNs               = new ULONG_PTR[NumberOfPages];
BOOL bResult                         = AllocateUserPhysicalPages( GetCurrentProcess(),&NumberOfPages,aPFNs);
// 检查分配内存是否成功
if(!bResult)
{
// 分配识别,错误处理
// .....
}
// 检查实际分配的内存页数
if( NumberOfPages != xxx )
{
// ....
}

需要注意的是,调用上述代码的用户必须具有“Lock Pages in Memory”(内存中锁定页面)的权限。此权限使得用户可以使用进程将数据保持在物理内存中,这样可防止系统将数据分页到磁盘上的虚拟内存中。行使此权 限会因降低可用随机存取内存(RAM)的数量而显著影响系统性能。需要在本地安全策略管理程序中给用户赋予该权限,如下图所示:

注意:设定权限后需要注销或重启才能起作用!

给用户分配了上述权限之后,需要在程序中使用代码启用该权限,如下所示:

// 设置锁住物理内存的权限,此代码在调用AllocateUserPhysicalPages之前执行
if( !AWESetLockPagesPrivilege( GetCurrentProcess(), TRUE) )
{
// 输出错误信息
..........
} /// <summary>
/// 设置或清除启用AWE( Address Windowing Extensions )所需要的锁住内存的权限。
/// </summary>
/// <param name="hProcess">
/// 进程句柄。
/// </param>
/// <param name="Enable">
/// 设置或者清除标志。
/// </param>
/// <returns>
/// 如果成功,则返回TRUE,否则返回失败。
/// </returns>
BOOL AWESetLockPagesPrivilege( HANDLE hProcess, BOOL Enable )
{
HANDLE Token = NULL;
BOOL Result = FALSE;
TOKEN_PRIVILEGES Info = { }; // 打开令牌
Result = OpenProcessToken ( hProcess, TOKEN_ADJUST_PRIVILEGES, &Token );
if( !Result )
return FALSE; // 设置权限信息
Info.PrivilegeCount = ;
Info.Privileges[].Attributes = Enable? SE_PRIVILEGE_ENABLED : ; // 获得锁定内存权限的ID
Result = LookupPrivilegeValue ( NULL,SE_LOCK_MEMORY_NAME,&(Info.Privileges[].Luid));
if( !Result )
{
CloseHandle( Token );
return FALSE;
} // 调整权限
Result = AdjustTokenPrivileges ( Token, FALSE,(PTOKEN_PRIVILEGES) &Info,, NULL, NULL);
if( ( !Result ) || ( GetLastError() != ERROR_SUCCESS ) )
{
CloseHandle( Token );
return FALSE;
} // 成功返回
CloseHandle( Token );
return TRUE;
}

使用AllocateUserPhysicalPages分配了物理内存之后,下一步就是使用MapUserPhysicalPages或 MapUserPhysicalPagesScatter函数将物理内存映射进用户模式地址空间内,这两个函数用法差不多,只是第一个参数有差别。由于分 配的物理内存的大小超过了用户模式地址空间的大小,因此显然不可能一次将所有的物理内存都映射到地址空间中。通常的做法是在用户模式地址空间内分配一小块 连续的区域(即地址窗口),然后根据使用的需要动态将部分的物理内存映射到地址空间,这也就是“地址窗口扩展”一词的真实含义。代码示例如下:

/ 定义16M的地址窗口
#define MEMORY_REQUESTED (16*1024*1024) // 分配地址窗口
PVOID lpMemReserved = VirtualAlloc( NULL,MEMORY_REQUESTED, MEM_RESERVE | MEM_PHYSICAL,PAGE_READWRITE ); // 将物理内存映射到地址空间(根据需要,每次映射的页面会不同,
// 即下面函数的第三个参数aPFNs会指向不同的物理页)
bResult = MapUserPhysicalPages( lpMemReserved,NumberOfPages,aPFNs); // 以下就像普通的内存一样使用lpMemReserved 指针来操作物理内存了
................... 使用完了之后,可以使用FreeUserPhysicalPages来释放分配的物理内存,示例如下: // 取消内存映射
bResult = MapUserPhysicalPages( lpMemReserved,NumberOfPages,NULL ); // 释放物理内存
bResult = FreeUserPhysicalPages( GetCurrentProcess(),&NumberOfPages,aPFNs ); // 释放地址窗口
bResult = VirtualFree( lpMemReserved,,MEM_RELEASE ); // 释放物理页号数组
delete[] aPFNs;

AWE机制被使用最多的一个场合是数据库系统的缓存管理器(BufferManager),例如SQL Server的内存管理器。虽然以上代码都是基于Windows操作系统,但是PAE和AWE机制并不是Windows特有的,32位Linux也有类似 的API。完整使用AWE机制的例子,大家可以参考MySQL的源码。 最后想说的是,对于开发人员来说,一个好消息是64位CPU和操作系统正越来越普及。在64位环境下,一个进程的用户模式的地址空间可达8TB(也就是说 目前很多的64位系统只使用了40几位的内存地址,远没有充分使用64位的内存地址),在可以预见的未来很长一段时间,估计我们都不会再为地址空间不足而 发愁了,让我们一起为64位时代的到来而欢呼吧!

转:如何在32位程序中突破地址空间4G的限制的更多相关文章

  1. 关于32位程序在Win7&64位系统中连接Microsoft Excel数据源的问题

    最近在新公司电脑上跑以前的selenium测试框架的时候,抛出了如下的错误 出现的是ODBC Driver问题:[Microsoft][ODBC Driver Manager] Data source ...

  2. C# 32位程序在64位系统下运行中解决重定向问题

    在64位的Windows操作系统中,为了兼容32位程序的运行,64位的Windows操作系统采用重定向机制.目的是为了能让32位程序在64位的操作系统不仅能操作关键文件文夹和关键的注册表并且又要避免与 ...

  3. 记32位程序(使用3gb用户虚拟内存)使用D3DX9导致的一个崩溃的问题

    为了增加32位程序的用户虚拟内存的使用量,我们使用了/LARGEADDRESSAWARE编译选项来使32位程序可能使用到3gb的内存,能否使用到3gb内存也跟平台.系统和设置有关系,现摘抄部分作为参考 ...

  4. Ubuntu14.04 64位运行32位程序

    最近公司新增的机器安装Ubuntu14.04 64bit导致之前在32bit下编译的Qt工具软件无法运行. 于是google的了一下找到一些解决办法,但不能保证全部32bit的Qt程序都能正常,测试了 ...

  5. C# 32位程序访问64位系统注册表

    原文:C# 32位程序访问64位系统注册表 我的上一篇文章已经阐述了“32位程序和64位程序在64位平台上读\写注册表的区别”,那么接下来将要回答上篇所留下来的一个问题:32位程序如何访问64位系统注 ...

  6. Linux64位程序中的漏洞利用

    之前在栈溢出漏洞的利用和缓解中介绍了栈溢出漏洞和一些常见的漏洞缓解 技术的原理和绕过方法, 不过当时主要针对32位程序(ELF32). 秉承着能用就不改的态度, IPv4还依然是互联网的主导, 更何况 ...

  7. win764位系统上让32位程序能申请到4GB内存方法

    win764位系统上让32位程序能申请到4GB内存方法. 2016年09月18日 18:36:26 阅读数:1550 最近测试一个32位程序总是在1.2G左右内存时崩溃,怀疑是内存申请失败,本身32位 ...

  8. 通过修改EIP寄存器实现32位程序的DLL注入

    功能:通过修改EIP寄存器实现32位程序的DLL注入 <如果是64位 记得自己对应修改汇编代码部分> 原理:挂起目标进程,停止目标进程EIP的变换,在目标进程开启空间,然后把相关的指令机器 ...

  9. 使 32 位程序使用大于 2GB 的内存

    不管在 32 位 Windows 上还是在 64 位 Windows 上,32 位的应用程序都只能使用最大 2GB 的内存,这是我们司空见惯的一个设定.但其实 Windows 提供了一些方法让我们打破 ...

随机推荐

  1. 我的android学习经历

    我为什么选择android? 我基本上前一年的时间都是在学习java的语法和线程之类的,没有注意java的分类,所以到现在慢慢接触到深处的时候我了解到,java的优势主要在web,而我不是特别喜欢网页 ...

  2. 验证码做得不错,有.net 版本 https://captcha.com/

    https://captcha.com/ https://captcha.com/demos/features/captcha-demo.aspx

  3. SAE上传文件到storage

    还有什么比代码更清晰的讲解 html代码: 一定需要下面这个: method="post" enctype="multipart/form-data" < ...

  4. CentOS 6.3下MySQL 5.6源码安装

    Linux操作系统:CentOS 6.3 1:下载:当前mysql版本到了5.6.10 下载地址:http://dev.mysql.com/downloads/mysql/5.6.html#downl ...

  5. Linux服务器下nginx的安全配置

    1.一些常识 linux下,要读取一个文件,首先需要具有对文件所在文件夹的执行权限,然后需要对文件的读取权限. php文件的执行不需要文件的执行权限,只需要nginx和php-fpm运行账户的读取权限 ...

  6. yii2开发后记

    h2:first-child, body>h1:first-child, body>h1:first-child+h2, body>h3:first-child, body>h ...

  7. SQL Server锁定【2015.12.17】

    锁定的体系分类   1.表级锁 保证数据在逻辑上的一致性. 包含:行级锁.分页锁.表.数据分页.LOB分页以及索引叶子级锁. 2.闩 保证数据在物理上的一致性,系统采用,比锁少耗资源,对用户不可见. ...

  8. Linux 引导修复

    前些天,我的Ubuntu老提示"Filesystem root"空间不足,于是,我煞笔的用win pe去扩展空间,结果,空间扩展不成,反倒丢失了引导..... 于是就上网查资料,看 ...

  9. my_mosaic

    //功能:输入想要打马赛克的坐标点,宽,高以及每个边需要划分的块数进行打马赛克 //只能处理位图,根据不同色深定义depth即可 //还没写从文件头读取图片分辨率 #include<unistd ...

  10. ASP.NET Core 1.0 安装并发布到Centos 7.2 使用jexus 5.8.2

    安装运行环境 sudoyuminstall libunwind libicu 下载.net core https://www.microsoft.com/net/download 下载完后上传文件 安 ...