This article is meant to be an easy to understand explanation of GC algorithms to those who think to themselves "I get that garbage collection is useful, but I don’t really understand how it all works". An explanation of how the CRuby*1 GC works will follow. Finally we’ll look a little at recent studies on Ruby GC alternatives. Oh, just to set the record straight, the GC described in this article and the Game Cube system has no relationship :-)
When It Comes To Talking About Garbage Collection
At the December 2008 Kyushu Ruby 01 Conference, I asked the audience "How many of you here have some interest in garbage collection?" Out of 200 people, only 3 raised their hands (even so I still proceeded to talk to no end about the subject). It seems as though the majority opinion about garbage collection is "As long as everything works okay behind the scenes I’m all okay." However garbage collection is one of the taken for granted features that is built into a good number of language processors. It would not hurt as a programmer to properly understand the structure and internal implementation of garbage collection. I would be greatly pleased if you read this article with a "All right, I’ll take a little break and hear out your talk about garbage collection" type of mindset.
What Is GC?
GC is an abbreviation for "Garbage Collection". To execute GC means detecting unused regions in memory and freeing the memory held by these regions. It goes without saying that many programmers consider this a great blessing, so I think I’ll leave the basic definition at that.
GC Enabled Language Processors
Many language processors these days have garbage collection already built-in. A few examples include:
One could say that garbage collection is a feature that modern language processors can’t be without.