Memory management in the Glow engine
Memory management matters a lot in the console world. On a PC we can mostly forget about it, at least for a few hours of running without leaks. Consoles are restricted, so we have to assume that at some point a memory allocation will return NULL (or throw an exception, depending on the compiler). Fragmentation is another serious problem once many small objects have been allocated. We plan to move to mobile devices, so we decided to build a proper memory management system.
The Glow engine now has a new memory manager. Instead of the single common C++ heap, every module of the engine (physics, AI, navigation, sound and so on) gets its own optimised single-threaded heap with pools for small objects.
There is also a special heap for passing messages between modules, memory leak debugging, and shared pointers (from the Boost C++ library) for memory arrays.
I implemented an allocator for STL containers, so every allocation in a given module comes from that module’s heap. STL containers and strings are a major source of memory fragmentation, though, so I have started removing every STL container from the code. Some vectors are replaced by a special stack vector container, based on boost::array with limited dynamic growth. Most constant std::strings have been replaced with a const char* equivalent, with the memory allocated from a constant string pool and “copy on create if exists” usage.
Finally there is a memory debugger UI. It draws memory fragmentation and shows information about allocated blocks: count, amount and overhead.
The remaining part of the memory manager is a garbage collector for geometry.
A January release date was very optimistic, so we have moved the alpha release to spring 2011. The major parts are ready, but there are many small tasks left to polish the editor and the engine.