Jump to content
  • Advertisement
Sign in to follow this  
apat

Allocation of huge amount of memory, problem XP.

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

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by apat
Below 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 this post


Link to post
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 this post


Link to post
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 apat
Hmm, 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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!