I remember this kind of approach being proposed for a game debugging tool, and for writing games in a managed language. Basically, everything you wanted to keep

I remember this kind of approach being proposed for a game debugging tool, and for writing games in a managed language. Basically, everything you wanted to keep or consider permanent was marked or kept in one part of the heap, and everything that was allocated to execute a frame was implicitly thrown away. (One way to do it would be to compact the heap before starting the frame, then use the top of the heap as a barrier.) I also saw this strategy used in coursework. I was in graduate school, and I had just done the Compiler class the previous semester. My best friends were taking the course, and the professor had concocted a home made leak checker and foisted it on the class, declaring that no program with leaks would be accepted for the final project. It was only a few weeks before the end of the term, and everyone was demoralized. Jokingly, I suggested that everyone just make their own mechanism of the same kind, which would track allocations then release all of the program's allocated memory just before the prof's leak checker ran. As it turns out, the whole class ended up implementing my idea. The test data was small enough, that everyone's compilers could afford to simply leak memory, then release it all at the end. Problem solved.