# Ruby 2.1 Garbage Collection: ready for production

DevFeed: [Ruby 2.1 Garbage Collection: ready for production](<https://devfeed.tech/articles/ruby-2-1-garbage-collection-ready-for-production-41335.md>)

Original publisher: [Read original article](<https://samsaffron.com/archive/2014/04/08/ruby-2-1-garbage-collection-ready-for-production>)

Author: Sam Saffron

Published: 2014-04-08T05:16:21Z

Content type: article

Language: en

Sources: [Sam Saffron](<https://devfeed.tech/sources/sam-saffron.md>)

Topics: [Ruby](<https://devfeed.tech/topics/ruby.md>), [Rails](<https://devfeed.tech/topics/rails.md>)

Tags: [algorithm](<https://devfeed.tech/tags/algorithm.md>), [garbage-collection](<https://devfeed.tech/tags/garbage-collection.md>), [max](<https://devfeed.tech/tags/max.md>), [memory](<https://devfeed.tech/tags/memory.md>), [rails](<https://devfeed.tech/tags/rails.md>), [ruby](<https://devfeed.tech/tags/ruby.md>)

## AI overview

This article examines Ruby 2.1's garbage-collection memory limits and responds to claims that Ruby's GC algorithm is fundamentally flawed. It explains how Ruby tracks allocations outside its heaps, describes dynamically growing limits with maximum caps, and notes that Ruby 2.1.1 did not behave as the expected safeguards suggested.

## Source excerpt

The article "Ruby Garbage Collection: Still Not Ready for Production" has been making the rounds. In it we learned that our GC algorithm is flawed and were prescribed some rather drastic and dangerous workarounds. At the core it had one big demonstration: Run this on Ruby 2.1.1 and you will be out of memory soon: while true "a" * (1024 ** 2) end Malloc limits, Ruby and you From very early versions of Ruby we always tracked memory allocation. This is why I found FUD comments such as this troubling: the issue is that the Ruby GC is triggered on total number of objects, and not total amount of used memory This is clearly a misunderstanding of Ruby. In fact, the aforementioned article does nothing to mention memory allocation may trigger a GC. Historically Ruby was quite conservative issuing GCs based on the amount of memory allocated. Ruby keeps track of all memory allocated (using malloc) outside of the Ruby heaps between GCs. In Ruby 2.0, out-of-the-box every 8MB of allocations will result in a full GC. This number is way too small for almost any Rails app, which is why increasing RUBY_GC_MALLOC_LIMIT is one of the most cargo culted settings out there in the wild. Matz picked this tiny number years ago when it was a reasonable default, however it was not revised till Ruby 2.1 landed. For Ruby 2.1 Koichi decided to revamp this sub-system. The goal was to have defaults that work well for both scripts and web apps. Instead of having a single malloc limit for our app, we now have a starting point malloc limit that will dynamically grow every time we trigger a GC by exceeding the limit. To stop unbound growth of the limit we have max values set. We track memory allocations from 2 points in time: memory allocated outside Ruby heaps since last minor GC memory allocated since last major GC. At any point in time we can get a snapshot of the current situation with GC.stat: > GC.stat => {:count=>25, :heap_used=>263, :heap_length=>406, :heap_increment=>143, :heap_live_slot=>1068