You Take Out The Trash, Man!
When I started writing this post, I thought I was going to write about game development using Ruby. I love games, and I’ve always wanted to make my own, so researching how to do that with Ruby seemed like an obvious choice.
Before I even started, I figured that Ruby was probably not an ideal language for high-end game-dev. Mainly because I assumed that Ruby couldn’t be fast or powerful enough to handle it. As I began my research though, I found myself more intrigued by the things that made it difficult to build games in Ruby, than I was in the actual game development process. In fact, I was drawn to one subject in particular: Garbage Collection!
**Quick Fun Fact!***
Computer Scientist John McCarthy is credited with:
Inventing Garbage Collection
Creating the List Processing — or Lisp — programming language
Pioneering research into “Artificial Intelligence” - a term which he also coined
What is Garbage Collection?
Garbage collection is an automated memory management process that runs “behind the scenes” in most high-level programming languages, and can often be added through an external library if needed. Without garbage collection, memory needs to be managed manually.
So, what does “memory management” mean to us as programmers, and why should we care?
Thankfully, the answer isn’t really any different than the name would imply. It is a process that ensures that our programs always have enough memory available in order to continue to run. The specifics might vary a bit from language to language, but the basics remain the same.
So how does Ruby handle garbage collection?
Ruby’s garbage collector utilizes a process known as “mark and sweep” collection. This process works in three phases: Allocate memory, mark, and sweep!
To begin, before your program gets going, Ruby sets aside a certain amount of memory for it to use.
Next, once your program has started running, it can enter the marking phase. This phase works by running through all of the information that has been created and stored, and keeping track of whether or not it is being used or still needed. If something is still needed, it “marks” it to protect it from being destroyed.
It then runs through its sweep phase, removing the items that are unmarked, and freeing up space for new information to be stored.
That’s pretty much it! The process is a bit more complicated than that, but this is essentially how it works.
How does that process compare to manual memory management?
Garbage collection has been iterated over and refined year after year to run as smoothly as possible. Without it, developers are responsible for keeping track of that entire process themselves.
Doing so can require quite a bit of effort and time, and given that humans are pretty prone to making mistakes, it can be very tedious as well. That said, the benefits are actually pretty easy to understand. It’s all about freedom and flexibility.
While automated garbage collection can be a fantastic thing, it does take some decision making power away from the developer, such as what should be deleted and when. Additionally, despite the fact that it is designed to be a quick and painless process, it does still cause interruptions and slow things down. For developers working on large-scale projects that need to process huge amounts of information rapidly, especially in real time, even these brief interruptions can add up and cause problems.
To bring things full circle, these interruptions and the lag that they can cause are the reason automated garbage collection can make game development difficult. There are ways to work around it, such as implementing your own garbage collector to override the existing one, or even just overriding parts of the process. But that is a subject for another day.
Thanks for reading!
