Finished reading The Garbage Collection Handbook[1]. I’m glad that I read through it, but I’m pretty sure that my takeaway is something other than what the authors would have hoped for. I completely believe the subtitle when it says, “The Art of Automatic Memory Management.” Something *that* overly complex has got to be an “art” as opposed to something you might be able to build a discipline around.
To be fair, the concept behind garbage collection is actually relatively straightforward. If a programmer allocates dynamic memory, then track all references to any specific entity of dynamic memory and once all references to an entity are gone then delete that memory. Unfortunately, the modern world we live in necessitates making the whole process rather more complicated in order to support the lavish lifestyles we are currently enjoying.
Near as I can tell there’s three problems: 1) mutable state means old memory can reference new memory 2) hierarchical memory architectures means memory locality trumps any level of sophistication 3) concurrent programs means the simple must be made complex in order to avoid locks. With their powers combined, it looks suspiciously like you have to be a super expert in order to create a garbage collector and a skilled expert if you need to troubleshoot one.
My guess is that we’re going to see mutable state and concurrency transform into something very different than what we see today in the industry standard languages. Of course it’s also possible that something like memristors[2] might change everything, but I’m not sure that’s going to show up soon enough to avoid a paradigm shift.
Also C has it’s own problems[3] so I’m not convinced we can just ‘move back to the trees’ as it were.
I guess it’s time to figure out linear typing and regional calculus and hope the Rust[4] guys are able to blaze a trail for the rest of us.
[1] - http://gchandbook.org/
