Ruby Garbage Collection Deep Dive: Generational Garbage Collection | Jemma Issroff

This is the third post in the Ruby GC Deep Dive series. It’ll make most sense if you check out the previous two first:GC::INTERNAL_CONSTANTS lays out necessary definitions to understand the Ruby Object SpaceTri-Color Mark and Sweep explains the overall algorithm Ruby’s GC usesFor this post, we’ll learn about Generational GC. Generational garbage collection is predicated on the weak generational hypothesis: most objects die young. This means most objects will not have any active references, and so be available for collection soon after creation. The hypothesis also says that those objects which don’t die young tend to live for a long time. If they aren’t pretty immediately available for collection, they likely won’t be available for a while.We can look at a Rails example to justify this hypothesis to ourselves. To generate a webpage for a client request, the Rails application will create many new Ruby objects. Once the page has been returned to the client, all of these objects are no longer needed and their space in memory can be reclaimed. However, there are some objects which need to live between all requests, like controllers, configuration data, user sesssion data, and so on. These objects will live for a long, long time.