Jump to content
  • Advertisement
Sign in to follow this  
glutz7878

Memory Mgmt: Separate Heaps

This topic is 4158 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

So I get out of memory problems on CE devices a lot and I've attempted to create my own heap management scheme by using separate heaps for different things. For example, I put all my small allocs in Heap A, all my larger Allocs in Heap B and so on. This is to hopefully reduce fragmentation. (For this i use the APIs HeapCreate, HeapAlloc, HeapDestroy, etc) I also have separate heaps for separate caches so I can at any point destroy the cache and its heap as well, and re-create it all. This gives me a hard cap on memory I am using for each heap as well as giving me a way to know that when I re-create the heaps I have no fragmentation again. Despite this effort, I still see some behavior where I run out of memory even faster than before in some cases. Is there something that I am not understanding about the way Windows manages its heaps? For example, am I wasting space by putting all small allocs into 1 heaps? If I have too many heaps am I wasting some overhead? Any advice or documentation you can point me to about this topic would be much appreciated! Thank you

Share this post


Link to post
Share on other sites
Advertisement
If you're running out of memory, there's time to check the whether the computer is plugged in. Or, in this case, memory leaks.

How are you allocating memory? Small object allocations sound like a static pool. There should be nothing to run out of. When it's empty, you throw an exception, or suspend execution until it frees.

There's really not much to do if you run out of memory, 3 heaps or one. Fragmenting into several pieces makes the problem worse.

Or better yet, use custom allocators if you aren't yet. That way, you get full control over allocation. Purging the heap to solve fragmentation (is it even a) problem is somewhat radical without some solid garbage collection mechanism (like generational garbage collector).

Quote:
For example, am I wasting space by putting all small allocs into 1 heaps?


Yes. Each allocation will likely consume 4 extra bytes (IIRC). That's prime example for pre-allocation. Not only does it improve performance, it also gives you a very managable indication of when something goes wrong. And there's also no fragmentation if you pre-allocate the memory.

Quote:
If I have too many heaps am I wasting some overhead?
Yes, but nothing noteworthy. What you are losing is flexibility. No individual heap will ever be full before it starts choking, and by providing less free space for each one you've made the problem worse.

Pre-allocate buffers, then see what you're running out of and adjust accordingly. The problem here isn't in the system - your application excessively allocating memory - nothing short of RAM upgrade will solve that. Find solution in your code. Since you're running out of memory it's time to start re-working algorithms to avoid these bottle-necks.

Share this post


Link to post
Share on other sites
You need to find out how much memory is lost to fragmentation before you decide to reduce fragmentation. It is possible that even if you reduced fragmentation to 0, you would still run out of memory, and so fragmentation is not your problem.

There are several strategies for reducing fragmentation. The first one is organize heaps by the persistence of the contents. A common method is to allocate short-term allocations from one end of the heap and long term allocations from the other. Organizing heaps by size is another but it is not as effective.

If you are making lots of small allocations, you can reduce allocation overhead by creating memory pools for specific allocation sizes. Memory pools can have close to 0 overhead per allocation but have other complications.

Anyway, as you can see, the solutions are complicated so you should figure out exactly what the problem is before you proceed.

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!