I've been catching up on streams, so I'm pretty far behind, but I've noticed quite a few times people asked questions about how memory is being managed and how you can be sure there aren't any leaks.
Not going to try to explain how no leaks are occurring here since Casey has already explained, but I suspect many people are still left with questions.
A blog post by Noel Llopis I think will give some insight to people wondering about how some games manage the block of memory internally once they have it: http://gamesfromwithin.com/start-pre-allocating-and-stop-worrying
One of the key atrocities that was indoctrinated into me during college was the idea of allocating memory only at the moment of need and only for the size that you need it. For a long time I thought this was the one true way of requesting memory from the system.
However, I'm slowing coming around to the reality that requesting memory in this way has huge burdens on me, the programmer, and in fact is worse for a huge number of cases. My guess is Casey is going to do something similar to what Noel is suggesting in the blog post. I've read quite a bit that game developers especially tend to use very custom tailored, simple allocators to solve the problems they actually have, rather than use a crazy general allocator that does nothing well.
I feel like Noel covers the bases pretty well, but anybody have anything to add or know of any other resources for how people deal with memory? Jason Gregory (Naughty Dog) wrote a book, Game Engine Architecture, which is pretty solid and has a decent section talking about memory. Seems like it's pretty popular (at least in the console development world) to follow this kind of memory allocation strategy. Desktop PC software, however, seems to do quite poorly with memory these days...