Garbage Collection: The Art of Forgetting (That Humans Still Haven’t Mastered)

Every application produces objects.

• A user logs in
• someone writes a message
• an order is made
• a request is sent

and, at the time of creation, these objects take up memory. Unfortunately, memory is a limited resource.

Leftover objects, which are no longer needed by the application, lead to memory wasting, which degrades the performance of the application and, sometimes, leads to out-of-memory errors.

This is where Garbage Collection (GC) comes into play.

How Does GC Actually Work?

The garbage collector regularly checks which objects in memory are referenced and which are not.

If an object is unreferenced, it means that there is no way to reach it in the application code.

Such objects are deleted by the garbage collector to free up memory for future allocations.

Not bad, right?

Technically, it’s all very simple.

Emotionally, however, this process can be rather traumatic, as we will see shortly.

GC is Essentially a Breakup

Think about a breakup - when you and your partner are done, you likely do not erase the person from your life immediately.

You might continue to view their photos, look at your mutual stories, chat with them, and go to that cute cafe where you met.

All of these are references to another person, which, as soon as they are gone, make that person ineligible for garbage collection.

The same logic applies to objects in memory: as long as there is a reference to an object, it cannot be collected, even if it is no longer needed.

Once all the references are removed, however, the object becomes unreachable and can be garbage-collected at any time.

Not surprisingly, humans have very similar mechanisms for dealing with unreachable objects in memory.

We call them breakups, unfollows, and block buttons.

Once you have no more references to another person, you delete them from your social media, archive the chat, and avoid visiting the places you used to go together.

However, just like in the case of applications, this does not mean that the object has been collected - it still lives on in dreams, music, and occasional nighttime walks through that familiar cafe district.

A Developer Has a Better GC Than You

It turns out that, in terms of memory management, humans are not that different from basic runtimes.

A garbage collector will not keep thinking about an unreachable object just because it used to have thousands of references to it.

It will not binge-watch your old photos at 3:00 AM just to delete the person from memory later.

It will not go to that cafe where you used to sit together and slowly sip bitter coffee in silence.

A garbage collector will simply recognize an unreachable object as eligible for collection, and move on.

Sounds simple enough, right?

Unfortunately, for humans, the analogous process is much more complicated. Maybe this is why our runtime environment is so much worse than we thought.

We swipe left, block and report, unfollow and erase, but the memory of another person still lives on. In dreams, in music, in the place where everything began.

It can waste a lot of memory, as the GC needs to constantly check for such objects in memory. They may even pop-up uninvited at times, without us asking for them.

Isn’t it a bit ironic that our runtime environment is not as efficient as we claim it to be?

As poetically described by humans in love and loss, such objects can stick around for a lifetime - unless you actively release all of their references.

Wrap-up

Next time your application is using too much memory, remember that, unlike you, the garbage collector has no problem moving on.

You do! 😄