OK. Maybe I just don&#x27;t understand game development very well, but I don&#x27;t get why some of the problems they had in the post-MMU era even existed.<p>1) Memory Fragmentation - why? This seems like it would only be a problem if they ran their entire game in the same virtual address space.<p>2) Subsystem A corrupting Subsystem B&#x27;s RAM - once again, wouldn&#x27;t one run the sim code in one address space, the rendering in another, etc. and have strategically shared pages for them to transfer data back and forth?<p>It really seems to me like the idea is &#x27;yeah, we had virtual memory, and it was great, but we didn&#x27;t really use it&#x27;... Granted, they put guard pages on some allocations, but that&#x27;s akin to using supercomputer to solve your family budget. Lots of power available, but using it in a trivial way.<p>I acknowledge that there&#x27;s some cost to a context switch, and that the 2005 generation used PowerPC with its fairly cache-inefficient hashed pagetable (poor locality), but the benefits of having a hard wall in memory between major system functions is immeasurable (I&#x27;m guessing that on PPC, they just set up a few Block Address Translation registers and called it &#x27;good enough&#x27;).<p>Then again, I come from a safety critical background .. we make aerospace code, so it&#x27;s developed using the methods described in the article about &#x27;the right stuff&#x27; that was up a day or two ago.  We&#x27;re really fond of having really hard walls between every resource we can (memory, CPU time, I&#x2F;O bandwidth, FS bandwidth ... you name it) for major system functions. I realize that in game programming most of those walls aren&#x27;t practical (due to performance impact) or necessary, but the memory one is fairly cheap and incredibly helpful.<p>PS - if you&#x27;re wondering, we prevent memory leak problems by just disabling dynamic allocation post-boot, which happens on the ground. Our stack utilization is also required to be statically analyzable, which means that you can&#x27;t do things like recursion. These limitations make the design of some algorithms extremely painful, but what other software have you ever heard of that can truthfully claim 0 memory leaks, guaranteed. We also do 100% code coverage (at the machine language level), 100% decision coverage, static and dynamic worst-case timing analysis, etc. etc. etc. Look up &#x27;DO-178B&#x27; or &#x27;DO-178C&#x27; if you&#x27;re curious about what&#x27;s done and why safety critical stuff is insanely expensive. More recently we&#x27;re throwing in fuzzing for good measure, but fuzzing doesn&#x27;t turn up a whole lot in extremely thoroughly tested code that&#x27;s been reviewed line-by-line by dozens of engineers (and is subject to strict design limitations).