# Allocation of huge amount of memory, problem XP.

This topic is 3839 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi! I've recently bought some more memory and thought I'd try to allocate and see how much I could use. I've got 4 gb, xp (32 bit) is reporting 3.5 for some reason (wich is normal I've read) and taskmanager is reporting atleast 3 gb of free physical memory to use but I can only allocate about 1.4 gb! How come? I've tried to increase the pagefile (as if that should have anything to do with it..) but no difference. Below is the code I used, if I add one byte more to allocate p becomes 0.
int main()
{
char *p;
p=new char [1499398060];
if (p==0)
return -1;
delete[] p;
}


##### Share on other sites
One issue is that you are trying to allocate the amount in one large continuous chunk, the other issue is that I suspect that 32bit XP might only allow 2GB per process (this I am not sure of though). Moreover, because XP does do virtual memory, the amount of RAM one has does not necessarily affect how much you can allocate, it is perfectly possible to have a 512MB machine and allocate 1GB, the problem being that as you walk through the large array, the pagefile will become very, very active.

##### Share on other sites
Yes, normally each process in XP is only allowed 2 gb of memory usage.
There is a command line switch that you can set in your boot.ini file (/3gb) that will allow your processes to use 3 gb of memory.
It is however very unlikely that you'll be able to allocate a continuous chunk of that big size.
To increase the chances of success, you'll need to allocate this chunk as early as possible after a reboot (as a service for instance).

##### Share on other sites
Ah, yes that was the first reason for buying more memory, to avoid the pagefile. So I guess 1.4gb is the largest continuous chunk availibly, so why isn't the pagefile used if I allocate more?. 2 gb limit per process maybe, must read about that.

Thanks

##### Share on other sites
Aha, going to try the /3gb switch.

##### Share on other sites
As others have said, it's because there's no contiguous block of 1.5GB in your address space.

In a 32-bit application, you only have 4GB of address space, and the upper 2GB of that is usually reserved for the kernel. That leaves you 2GB, in which you have to fit your application, any DLLs loaded, and the heap for all DLLs and your EXE.

##### Share on other sites
Quote:
 Original post by apatBelow is the code I used, if I add one byte more to allocate p becomes 0.

No, it doesn't. On a standards-compliant compiler, the ordinary form of 'new' will never return a null pointer. You need to use new (std::nothrow) to get that behaviour. The default is to throw an exception, which terminates the program. (You might see a zero value in 'p' with the debugger for example if you are compiling in debug mode and the compiler helpfully zero-initializes the variable automatically - since the new statement won't change whatever was there if it throws.)

##### Share on other sites
Hmm, the /3GB switch didn't improve things (linked with the /LARGEADDRESSAWARE too).

Oh well, now I know.

Zahlman:

My 'new' does return 0 when trying to allocate too much (when I debug atleast). And p was 0xCCCCCCCC at start. Using VS 7.1.

Thanks all.

##### Share on other sites
I've found Visual Studio (2003 and 2005, not sure about 2008) usually returns null rather than throwing an exception when allocating a massive array. I seem to recall that there's something that changes this behaviour, depending on what you link to...

EDIT:
Quote:
 Original post by apatHmm, the /3GB switch didn't improve things (linked with the /LARGEADDRESSAWARE too).
Yup, you probably still don't have 1.5GB of contiguous address space. I know for instance that kernel32.dll loads at around the 0x7f000000 mark, which isn't going to help with address space fragmentation if you're trying to use the upper 1GB.

• ### What is your GameDev Story?

In 2019 we are celebrating 20 years of GameDev.net! Share your GameDev Story with us.

• 9
• 11
• 15
• 11
• 11
• ### Forum Statistics

• Total Topics
634149
• Total Posts
3015830
×