What’s next?

There are still enough ideas on how to make the tool much more powerful. For instance, the fragmentation view is somewhat weak at this moment. Currently it is only possible to view the physical locations of the memory allocations of a certain moment in time.

It would be great to see an animated playback of the recording of the physical locations of the blocks. If you could playback that view at various speeds, I think it would be much easier to see what parts of your program are responsible for most of the fragmentation. The fragmentation could also display more statistics like the largest free memory block, which is essential information for a fragmentation view.

Conclusion

We have seen that intercepting allocations at a very low level can certainly be done for PC and we know it can also be done, at least to a very reasonable extent, for the Xbox and Xbox 360. For some other platforms it is sometimes hard or even impossible to track certain allocations, like the loading of the executable images, the allocations that are being performed by third parties or the allocations that are being performed by the kernel.

Besides the fact that we could really use help from the platform manufacturers to intercept allocations easier, I also feel that tools like MemAnalyze should be part of every standard SDK that comes with the development kits. Imagine that you would be able to launch any game in a special debug mode and that a tool like MemAnalyze would capture all of the allocation behaviour. The game programmer would not need to perform any additional work.

An attempt like this has already been made for Xbox using XbMemDump. Too bad Microsoft did not put some more work in XbMemDump. If they would have put in some extra effort it could have been really useful. In my opinion they were looking in the right direction.

In the future the amount of memory that is available for games will increase. This does not mean that we can loosen up on memory management. In fact, I state the exact opposite: with more memory available the amount of content will increase, so it is becoming more important to be able to manage that memory properly. So I hereby call upon platform manufacturers to start writing better tools and APIs to attack memory related problems in console games.

Until a good alternative shows up, we will just continue building solutions ourselves - which is fortunately a fun thing to do. I think I will build a new version of MemAnalyze with the new ideas in mind. I have to get going with the Windows Presentation Foundation anyway.

Acknowledgements

I would like to thank the people at Playlogic Game Factory, Tom van Dijck, Harm van Dinter and Arjan Janssen for their contributions they have made over the years.

References

¹ Boost pool implementation:

http://www.boost.org/libs/pool/doc/index.html

² Windows’ Low Fragmentation Heap

http://msdn2.microsoft.com/en-us/library/aa366750.aspx

³ Detours, a library by Microsoft Research to detour DLL functions:

http://research.microsoft.com/sn/detours/

⁴ Matt Conover’s solution to DLL hooking:

http://mconover.openrce.org

⁵ Jochen Kalmbach’s StackWalker:

http://www.codeproject.com/threads/StackWalker.asp

⁶ Dan Mouldin’s trick to obtain the instruction pointer:

www.thecodeproject.com/tools/visualleakdetector.asp

⁷ The latest Debugging kit for Windows:

http://www.microsoft.com/whdc/devtools/debugging/default.mspx

⁸ Marshalling data with platform invoke:

http://msdn2.microsoft.com/en-us/library/aa720284(VS.71).aspx

⁹ Platform invoke data types:

http://msdn2.microsoft.com/en-us/library/aa720411(vs.71).aspx

¹⁰ Scott Meyer’s Effective C++, third edition. Published by Addison-Wesley, ISBN: 0-321-33487-6.

¹¹ Discussion on MSDN forums about StackWalk64 performance:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=396838&SiteID=1