在32位XP上分配大于1 GB的内存 [英] allocate more than 1 GB memory on 32 bit XP
问题描述
我遇到一个奇怪的问题，我的进程不能分配多于似乎略低于1 GiB。当我的软件提供 bad_alloc 异常时，Windows任务管理器Mem Usage列显示的值接近1 GiB。是的，我检查了传递给内存分配的值是明智的。 （没有竞争条件/腐败存在，将使这失败）。是的，我需要所有这些记忆，没有办法。 （这是一个缓冲区的图像，不能压缩任何进一步）
我不是试图分配整个1 GiB内存一次，有几个分配300 MiB。这会造成问题吗？ （我会试着看看是否使更多的小分配工作更好）。有没有一些编译器开关或别的，我必须设置为了得到过去1 GiB？我看到其他人抱怨2 GiB限制，这将是对我很好..我只需要一点点:)。我使用VS 2005 SP1和我运行它在32位的XP和它在C + +。
32位操作系统，一个进程总共有4GB的地址空间。
在Windows上，一半是禁用的，您的进程有2GB。
这是2GB的连续内存。但它是碎片。您的可执行文件在一个地址加载，每个DLL在另一个地址加载，然后是堆栈和堆分配等。所以，虽然你的进程可能有足够的空闲地址空间，没有足够大的连续块来满足你的内存请求。因此，制作更小的分配可能会解决它。
如果您的应用程序是用LARGEADDRESSAWARE标志编译的，它将允许使用剩余的2GB， 。 （这取决于您的平台和环境。）对于在64位操作系统上运行的32位代码，
所以真的，设置标志总是一个好主意，如果你的应用程序可以处理它（它基本上是一个能力标志。它告诉Windows，我们可以处理更多的内存，所以如果Windows也可以，它应该只是继续，给我们尽可能大的地址空间），但你可能不能依赖它有一个效果。除非你在一个64位的操作系统，它不太可能买你（/ 3GB引导开关是必要的，它已知会导致驱动程序，特别是视频驱动程序的问题）
I'v run into an odd problem, my process cannot allocate more than what seems to be slightly below 1 GiB. Windows Task Manager "Mem Usage" column shows values close to 1 GiB when my software gives a bad_alloc exception. Yes, i'v checked that the value passed to memory allocation is sensible. ( no race condition / corruption exists that would make this fail ). Yes, I need all this memory and there is no way around it. ( It's a buffer for images, which cannot be compressed any further )
I'm not trying to allocate the whole 1 GiB memory in one go, there a few allocations around 300 MiB each. Would this cause problems? ( I'll try to see if making more smaller allocations works any better ). Is there some compiler switch or something else that I must set in order to get past 1 GiB? I've seen others complaining about the 2 GiB limit, which would be fine for me.. I just need little bit more :). I'm using VS 2005 with SP1 and i'm running it on a 32 bit XP and it's in C++.
On a 32-bit OS, a process has a 4GB address space in total.
On Windows, half of this is off-limits, so your process has 2GB.
This is 2GB of contiguous memory. But it gets fragmented. Your executable is loaded in at one address, each DLL is loaded at another address, then there's the stack, and heap allocations and so on. So while your process probably has enough free address space, there are no contiguous blocks large enough to fulfill your requests for memory. So making smaller allocations will probably solve it.
If your application is compiled with the LARGEADDRESSAWARE flag, it will be allowed to use as much of the remaining 2GB as Windows can spare. (And the value of that depends on your platform and environment.
- for 32-bit code running on a 64-bit OS, you'll get a full 4-GB address space
- for 32-bit code running on a 32-bit OS without the /3GB boot switch, the flag means nothing at all
- for 32-bit code running on a 32-bit OS with the /3GB boot switch, you'll get 3GB of address space.
So really, setting the flag is always a good idea if your application can handle it (it's basically a capability flag. It tells Windows that we can handle more memory, so if Windows can too, it should just go ahead and give us as large an address space as possible), but you probably can't rely on it having an effect. Unless you're on a 64-bit OS, it's unlikely to buy you much. (The /3GB boot switch is necessary, and it has been known to cause problems with drivers, especially video drivers)
这篇关于在32位XP上分配大于1 GB的内存的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
