1) Virtual memory only helps you to the granularity of a page. So, 4k at minimum. Meanwhile, a PS3 has exactly 256 megs of memory available to the CPU and we

1) Virtual memory only helps you to the granularity of a page. So, 4k at minimum. Meanwhile, a PS3 has exactly 256 megs of memory available to the CPU and we are highly motivated to use every last goddamned byte of it because if we don't, our competitors will. Meanwhile 2, the vast majority of allocations are under 512 bytes. In practice, even that subset is mostly <64 bytes. In that situation, fragmentation within a single page becomes serious business. You can't afford to have 10% of a given page be 9-15 bytes gaps between allocations. That could add up to 15-25 megs out of 256 wasted! When you get really tight, you can't even afford a heap header for each allocation --thus the specialized small block allocators. 2) A lot could be done better here. 4 gigs is not a ton of address space to protect different systems from each other. But, if you assume no system is going to ever need more that 64 megs, then you could divide memory into 64 spaces of 64 megs each and never have to reuse memory between different systems. I haven't heard of anyone doing this. You'll still get corruption from garbage data ending up in pointers. But, virtual memory segregation would cut out a large class of problems. Static allocation post-boot is not an option in games. You can be very strict and structured, but the needs of different situations are still too varied. Sometimes you need 90% UI, sometimes you need 10 gameplay regions, sometimes you need 100% devoted to a single, small room for a boss fight. Similar to fuzzing, I've worked on games that user controller-monkeys. An AI "player" was set up to artificially progress through the game while spamming the system with random actions. We would set all of our machines to monkey-mode each night before going home. In the morning, we would have a fresh set of obscure crashes to investigate.