Sign in to follow this  

Custom Memory Allocation

This topic is 2851 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 Guys. I was wondering if you could share some of your ideas on memory allocation in games. Specifically, I was thinking about using the Doug Lea Malloc. For my memory allocations, I have the following requirements: 1) Zero to no memory fragmentation. I am working on embedded devices. 2) Fast allocations and deallocations. 3) Moving memory allocations from the kernel space to the user space on embedded devices. 4) Minimizing memory consumption, although the other points are by far more important than this one. Previously, I have been using pools of various sizes for memory allocation. I am, however, also looking at other ideas and came across Doug Lea malloc, which would be a little more flexible. I am also willing to combine several approaches and use them individually, when appropriate. What other ideas are out there? Thanks! Florian

Share this post


Link to post
Share on other sites
In some (last gen) console games that I've seen, they just allocate a whole chunk of memory for a level to use. An index into the next unused byte is maintained, allocations just increment this index. There is no deallocation until the end of the level, where the index is set back to 0.
Obviously no allocations take place at all during gameplay, it's all done during the loading phase.
I've heard this strategy called a "mark and release heap".

Share this post


Link to post
Share on other sites
Thank you, Hodgman, for sharing your idea. I have read about this approach and while it certainly deserves its existance (fast and efficient, no fragmentation, dynamic allocation sizes, etc). It does come with a couple of drawbacks, specifically being comparatively hard to use (not very forgiving if you make an error) and not allowing for deallocation, hence memory might go wasted if it is used only once, but never thereafter. Depending on whether one can live with these drawbacks, its certainly an approach to consider.

In my case, I want to be able to pseudo-allocate and deallocate memory at any time during the game (think dynamically spawning particles, for example), even on a per frame basis. Of course, I will not be actually allocating the memory, but just retrieving a pointer to whatever memory chunk is currently free. The actual allocation however, would happen at startup or level-load.

Are there any other approaches out there, that might be worth considering?

Share this post


Link to post
Share on other sites
1) The mark-release heap is very useful. Expecially for single-frame buffers you might need, since you can drop the whole allocation at the end of the frame. You can always add new "marks" allowing you to use it for temporary allocations within some scope, and dropping it back to a previous point.

2) Memory pools are common. Allocating a segment of memory, and using it to quickly return allocations and frees of many small items. (like your game entities).

3) Block allocators. Allocate memory only in fixed sized blocks (ie one cache worth of data). Anything can use it however it wants, but the blocks only come in one size. Useful for things like file/network buffers. Useful as a layer ontop of memory pools, where each pool would grab "blocks" to allocate from (good for particles). Usually done in with a simple linked list of "free" blocks.

4) Custom heaps. Sometimes it isn't that "new"s "heap" algorithm is bad, but choice algorithm doesn't fit your needs. Maybe first fit, best fit, or worst fit, will give you better performance.

5) Consider allocators that take in fixed blocks of memory to use. That way you can make the same allocator rutine work on both a global scale, and on small stack allocated buffers. You can also use this to make sure each thread gets its own allocator pool, instead of having to lock a global allocator.

6) Consider that memory alignment can be beneficial. It increases performance in the general case, but is needed for some specific optimizations like using SSE instructions effectively.

7) YES! Do choose the right allocator for the job. Pool allocators might be good for game objects or particles, but won't work for allocating temporary buffers for loading/decompressing files and sounds. Likewise, using a heap for your particles is a bad idea, but heaps still work wonders in the general allocation case.

Share this post


Link to post
Share on other sites

This topic is 2851 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this