Discuss.

But seriously, I'm doing some research for work on custom memory handling and I'm not finding so much that's useful via Google so I was wondering if anyone had any thoughts or pointers on writing a memory manager. Basically, I'm working on a game for a hand-held platform where we'll have about 20Mbs of memory to play with and I've been hearing from other developers that using the standard new and delete for memory allocation is a "bad thing."

You can generally only do better than new and delete if your objects have some unifying characteristic, like being a uniform size.

This is one of those things where I wouldn't worry about it until it turns out to be a problem.

Still, it might be an educating experience.
What you need to do (if you want to simulate those 20MB:s on the Mac) is to just new[] a 20MB block and clear it.

The basics, then is to reserve parts of that block when you call MyAlloc. Free them up again when you do MyFree. You basically start out with a "bottom" pointer that points to the first free address. When you allocate, bump it up by the size of the allocation, and return the address it was on before. I'm sure you've figured this much out already. The beef is in where you place those blocks.

First off, you should align them to good byte boundaries - this is dependent on your platform. Secondly, when you free memory, you will have holes in your memory block. Eventually, you end up having enough total space to allocate a new block, but you won't be able to find anywhere to fit it. (Your total memory block is, say, ten bytes in size, every other byte is occupied. You want to allocate three bytes, have five free bytes, but you can't find three contiguous free bytes.) When this happens, you have to compact your memory, i.e. physically move allocations around in order to make room for the new block. If all the blocks you allocate are of the same size, then memory fragmentation won't occur, since every freed block can be filled by another block, without having to move anything. (This is the case Keith is talking about.)

In some special cases, you can look at frame based allocation. It works in a stack-like way: you allocate a bunch of memory blocks, but when you release one, it releases all the other ones that were released after it as well. For level loading routines and such, it can be blisteringly fast. For instance, you load your level, load all the assets into the block you're using, allocations are quick and so on... but when you're done, you release all the memory you allocated at once. There are some other applications as well.

If you're indeed doing this as a learning project, I can go on.

If youre working with low level code, such as ASM/C (and even low level c- no malloc), and youre not planning on having any or much portability, writing a new allocator can be great. Standard command allocators are very bulky, they have to deal with portability, making sure all types can be allocated without crashing the system, etc. Basically, if you can write a very specific allocation system, it can result in a huge performance increase