Chapter 7. Managing Memory Within the Execution Engine
Component-based applications, viewed as the vast graphs of interconnected type instances that they are, are notorious for their complex internal pointer manipulation, and as a result, their profligate thrashing of memory allocators. One of the longest standing feuds in the world of programming language design has centered on best practices for memory management in this kind of demanding environment. For some, it is even a long-standing joke: it’s said that C programmers have long understood that memory management is so critical, it can’t be left up to the system, and Lisp programmers have long understood that memory management is so critical, it can’t be left up to the programmers.
Since its introduction in the 1950s, garbage collection has received something of a nefarious reputation with many programmers. Garbage collection (GC) was for programmers who couldn’t keep track of their own resources; GC was slothful; GC would force an application to hang for nontrivial portions of time while it was running internal bookkeeping; or GC was simply for wimps. But now, it is clear that garbage collection is enjoying something of a renaissance. Why?
For starters, GC implementations have improved. Not only are they running on faster hardware than before, but the algorithms and approaches to managing garbage have gotten more accurate and faster. The pauses during program execution simply aren’t there anymore. More importantly, however, programmers ...