View Full Version : gpu/cpu memory consumption at particular point

04-23-2014, 07:44 AM

I am trying to allocate some memory in my code and I am running into some exception at the line where I do new BYTE[count].
This makes me that I am being denied any more memory. BYTE is unsigned char by the way and I was requesting 252698112 bytes.

Further tracing shows that when I do new BYTE, I am trying to do
{ // try to allocate count bytes for an array
return (operator new(count));

Since this request is on the cpu side, and I have atleast 16 GB RAM (although Visual Studio is 32 bit) , I would think I have plenty of memory. Could something else be the real problem?

To make it easier for me to debug, is there a way to check how much cpu and gpu memory has been allocated at a particular point in code?Other than, freeing up buffers and hoping for the best.

04-23-2014, 12:10 PM
If it's a 32-bit program you're still restricted to the 32-bit address space limits, even on a 64-bit version of Windows (I'm assuming Windows since you mention Visual Studio). That means 4gb, divided into 2gb for kernel mode allocations (you don't touch these, you don't control these, they belong to the OS) and 2gb for user mode allocations (your stuff goes here). That can be overridden by certain startup switches, but it's generally not recommended unless you're running a very specific program where it's advised in the documentation (it used to be recommended for Exchange 2000 for example) - in other words, you very probably don't have it, and you definitely can't rely on anyone else having it.

So your program has 2gb of address space available for you own allocations, and this is true irrespective of how much memory you have in your PC.

The quick and dirty way is to fire up task manager and check how much memory your program is using.

Slightly (but only very slightly) more sophisticated is to set a breakpoint on the failing allocation, then run it in the debugger. When the breakpoint is hit fire up task manager and check then.

You can also use the Windows API GlobalMemoryStatus (http://msdn.microsoft.com/en-us/library/windows/desktop/aa366586%28v=vs.85%29.aspx) call to get a view of how much address space you're using and how much you've left. Look at the dwTotalVirtual and dwAvailVirtual members of the returned MEMORYSTATUS struct (remembering that in Windows memory terminology, "virtual memory" is not the same thing as your page file).

It's possible also that the allocation is failing because your memory is fragmented and Windows can't find a large enough free block. If you're using C++ new and delete a lot this may happen. A solution (there are others) is to allocate a large-ish pool at program startup, and cast a byte* (or whatever*) to this pool as required instead of doing new and delete every time you need a buffer for working with (using placement new if you need constructors). That way you'll never fragment memory and as a nice bonus your memory allocations will be much faster (the other side of the coin is that you're on the slippery slope to your own custom allocator which you'll then need to manage).

On Windows, new, malloc, etc eventually resolve to HeapAlloc (C is not the lowest-level API on Windows). I'm not sure which heap they use, but if it is (as I expect) the process heap, you can call HeapCompact (GetProcessHeap (), 0) to defragment it. If it's not, GetProcessHeaps () will return all the heaps used by your process and you can defragment them all. Obviously only do this if your first allocation attempt fails - you don't want to make allocations slower in the general case. If the second attempt fails after this, you're SOL.

04-23-2014, 07:34 PM
ok, thank you for the pointers. I will give it a shot.

04-23-2014, 07:47 PM
Any reason why you can't use a 64-bit build? Recent versions of Visual Studio support 64-bit builds, and I believe they have so for quite some time. A quick search suggests that Visual Studio 2005 already supported 64-bit builds. The Express edition used to not support it, but the latest version (2012) does.