Tracking of retained objects in CRuby

Name Last Update
bench Loading commit data...
ext/liballocations Loading commit data...
lib Loading commit data...
spec Loading commit data...
task Loading commit data...
.gitignore Loading commit data...
.gitlab-ci.yml Loading commit data...
Gemfile Loading commit data...
LICENSE Loading commit data...
README.md Loading commit data...
Rakefile Loading commit data...
allocations.gemspec Loading commit data...


A Gem for counting the amount of objects that have been allocated but not released yet. Tracking this makes it easier to see if objects are being leaked over time and if so what kind of objects. This Gem does not provide any insight into where objects are being leaked or why.

This Gem can only be used on CRuby, it does not work on Rubinius due to TracePoint not being supported on Rubinius.


The usual approach of getting object counts is by using ObjectSpace.each_object. For example:

counts = Hash.new(0)

ObjectSpace.each_object(Object) do |obj|
  counts[obj.class] += 1

Sadly this approach is rather slow (e.g. for GitLab this would take roughly 800 ms) and (seems to) force a garbage collection run after every call. In other words, this isn't something you'd want to run in a production environment.

The allocations Gem on the other hand doesn't suffer from this problem as it counts objects whenever they're allocated and released. This does mean that allocating objects is slightly slower than usual, but the overhead should be small enough to use this Gem in a production environment.

Another big difference between ObjectSpace and this Gem is that the former gives an overview of all currently retained objects whereas the allocations Gem only tracks objects that have been allocated since it was enabled.


Load the Gem:

require 'allocations'

Enable it:


Getting a snapshot of the current statistics:


This will return a Hash with the keys set to various classes and the values to the amount of instances (of each class) that have not yet been released by the garbage collector.

Disable it again and clear any existing statistics:


Thread Safety

This C extension does not use any internal locking and instead relies on the GIL to prevent multiple Ruby threads from accessing the allocation data in parallel. Note that calling Allocation.start and Allocations.stop also affects all running threads instead of only the current thread.


All source code in this repository is subject to the terms of the MIT license, unless stated otherwise. A copy of this license can be found the file "LICENSE".