Take the 2-minute tour ×

I'm interested in the type of memory management a game like GTA IV might use given that it needs to create and delete lots of objects very quickly. How do the avoid fragmenting the heap and other things. If someone could point me in the right direction I'd really appreciate it.

share|improve this question
Grab a copy of Modern C++ Design. You'll be taken through the steps to build a fast allocator. –  Crazy Eddie Jan 14 '11 at 4:04

6 Answers 6

up vote 23 down vote accepted

They use things like memory pooling, specialized allocators, and specialized container classes.

  1. The Hoard Memory allocator for multi-threaded programs.
  2. EA's version of the STL. Contains allocators, containers,
share|improve this answer
memory pooling! yes, forgot that term :) –  Daniel Jan 14 '11 at 3:26

While this paper does not specifically refer to games, it provides a good roundup of the kind of custom memory allocators that people often employ in C and C++ applications in an attempt to improve performance (and is a bit of a cautionary tale).

Reconsidering custom memory allocation, Berger, Zorn & McKinley, OOPSLA 2002


share|improve this answer
Amusing that the first answer would link to your blog :) –  Matthieu M. Jan 14 '11 at 8:34

There are two very good malloc implementations for multi-threaded implementations:

  • tcmalloc: by Google
  • jemalloc: used by Apache (for example)

Here is Facebook's article about improving jemalloc. It's about 5 times faster that Hoard's memory allocator in the current top answer :)

share|improve this answer
That result is quite anomalous - I am hoping to work with Jason Evans to see what exactly the problem is. –  EmeryBerger Jan 16 '11 at 19:57
@EmeryBerger: it surprised me too, I certainly hope you find it out, good memory allocators are the first brick to build fast software :) –  Matthieu M. Jan 17 '11 at 7:31

Creating and destroying lots of objects really quickly doesn't necessarily mean heap fragmentation. Often, if the objects are of the same size, then the space freed by one can be allocated for the next.

Often, even just as an optimization, a program might not free and delete memory for objects, but keep old ones in a pool and simply grab one and overwrite the contents to create a 'new' object.

share|improve this answer
+1 for the first sentence. So many people talk about fragmentation and have no idea what it means. –  R.. Jan 16 '11 at 5:26

I think because their objects are mostly of the same size they can use some internal memory manager which doesn't actually free memory, but marks it as available and next time chunk of ~size is allocated it returns it.

share|improve this answer
That's what simple implementations of free() do anyway. –  Artelius Jan 16 '11 at 4:43

Lots of games use some of the memory allocators mentioned here. dlmalloc is one that we have used with great success (we have tied it into Lua). You can get information on dlmalloc here.

One other thing that I would mention though, is that not all games have to use dynamic memory allocation. We have employed mempools and use of static memory regions for most of our gameplay data. Only the systems that require dynamic allocation do so (Lua and some third party libraries). Everything else that we do comes out of static buffers. We use no STL in gamecode either, which helps limit the "damage" of memory fragmentation.

share|improve this answer
Note that any real OS (i.e. an desktop/server/workstation OS except Windows) uses an allocator that's algorithmically very close to dlmalloc, with various improvements, already. The only systems where dropping in dlmalloc as a malloc replacement might serve any purpose are Windows and perhaps game consoles (no idea what their libraries look like). –  R.. Jan 16 '11 at 5:29
That's not quite right. Linux-based systems do generally use the glibc allocator, which is indeed based on dlmalloc. However, Windows, FreeBSD, Solaris, AIX, and Mac OS X all use different memory allocators, none of which are based on dlmalloc. –  EmeryBerger Jan 16 '11 at 19:59
I guess I should have clarified that I was talking about non-real OSes. Personal bias aside, my answer was indeed coming from the windows and console point of view. –  Mark Jan 17 '11 at 20:07

Your Answer


