This is a good approach. Even if you aren't doing a "replay" allocator like this, having a custom allocator that records what happens can give lots of insight into the allocation patterns of your code.<p>One point I think a lot of people miss about custom allocators is that you don't write a custom allocator because you can do a "better job" than the library authors (well, sometimes you do, but hopefully you can assume that the platform authors know more about their platform than you do). But platform authors have to solve the general case. You can usually do better for your specific case. So your allocator is not going to be better than vanilla malloc/free for other programs, but you can tune it to fit your allocation patterns.