Memory Allocation

If you have not programmed embedded systems before, you may be surprised by some of the issues that come up when allocating memory on the Nintendo 64!

Background: Problems malloc/free must solve
The normal way to allocate memory in C on a modern system is to use malloc and free, provided by the standard C library. These functions are not magic! They use various data structures (some clever, some simple) to keep track of which ranges of memory are in use, and which blocks of memory are available.

Note: In C++, new/delete are just wrappers around malloc/free, and std::unique_ptr / std::shared_ptr are wrappers around new/delete. So the same problems with malloc and free also apply to C++.

The main problem that malloc/free must face is that you can allocate memory and free memory however you like. This can cause heap fragmentation, which is when you have free memory, but the free memory is “fragmented” into many small chunks. If you need to allocate a larger chunk of memory, you can’t use the small chunks. If heap fragmentation gets bad enough, malloc/free will start failing, and your game won't be able to continue running.


 * Wikipedia: Fragmentation (computing)


 * Stack Overflow: What is memory fragmentation?

Is this a problem on modern systems, too? Yes, but modern systems have tons of memory (usually, gigabytes) and it’s easier to deal with fragmentation problems if you have a large amount of memory to play with. Modern systems will use a malloc/free implementation like dlmalloc, jemalloc, or tcmalloc.

Memory Allocation Strategies
Working on this section… –Vanadium


 * Use globals (allocate memory with the linker!)


 * Allocate memory on startup


 * Use per-system heaps


 * Allocate memory on transitions


 * Use per-frame scratch memory