c++ - Heap fragmentation and windows memory manager

Question

I'm having trouble with memory fragmentation in my program and not being able to allocate very large memory blocks after a while. I've read the related posts on this forum - mainly this one. And I still have some questions.

I've been using a memory space profiler to get a picture of the memory. I wrote a 1 line program that contains cin >> var; and took a picture of the memory:

alt text http://img22.imageshack.us/img22/6808/memoryk.gif Where on the top arc - green indicates empty space, yellow allocated, red commited. My question is what is that allocated memory on the right? Is it the stack for the main thread? This memory isn't going to be freed and it splits the continuous memory that I need. In this simple 1 line program the split isn't as bad. My actual program has more stuff allocated right in the middle of the address space, and I don't know where it's comming from. I'm not allocating that memory yet.

2. How can I try solve this? I was thinking of switching to something like nedmalloc or dlmalloc. However that would only apply to the objects I allocate explicitly myself, whereas the split shown in the picture wouldn't go away? Or is there a way to replace the CRT allocation with another memory manager?

3. Speaking of objects, are there any wrappers for nedmalloc for c++ so I can use new and delete to allocate objects?

Thanks.

Answer 1

First, thank you for using my tool. I hope you find it useful and feel free to submit feature requests or contributions.

Typically, thin slices at fixed points in the address space are caused by linked dlls loading at their preferred address. The ones that load high up in the address space tend to be Microsoft operating system dlls. It's more efficient for the operating system if these can all be loaded at their preferred addresses because then the read-only parts of the dlls can all be shared between processes.

The slice that you can see is nothing to worry about, it barely cuts anything out of your address space. As you've noted, there are dlls, though, which load at other points in the address space. IIRC shlwapi.dll is a particularly bad example, loading at about 0x2000000 (again IIRC) which often splits a large portion of the available address space into two smaller pieces. The problem with this is that once the DLL is loaded, there is nothing that you can do to move this allocate space around.

If you link against the DLL (either directly or via another DLL), there is nothing that you can do. If you use LoadLibrary you can get sneaky and reserve its preferred address, forcing it to be relocated - frequently somewhere better in the address space - before releasing that reserved memory. This doesn't always work, though.

Under the hood, Address Space Monitor uses VirtualQueryEx to examine the address space of the process but there is another call from the psapi library which other tools use (e.g. Process Explorer) which can show you which files (including DLLs) are mapped into which parts of the address space.

As you've found, it can be scarily easy to run out of room in a 2GB user address space. Fundamentally, you're best defence against memory fragmentation is simply to not require any large contiguous blocks of memory. Although difficult to retro-fit, designing your applicationg to work with 'medium sized' chunks usually makes substantially more efficient usage of the address space.

Similarly you can use a paging strategy, possibly using memory mapped files or Address Windowing Extensions.