Simple answer: the Ruby runtime has a garbage collector. Depending on the runtime (JRuby/JVM generational GC, IronRuby/CLR generational GC, classic Ruby/mark-sweep GC) different algorithms are used. But the basics are pretty simple:
- Upon an allocation request if there is "insufficient free memory" available - how much is insufficient is one of the ingredients of the GC algorithm - then a GC will commence
- The GC starts by scanning roots, which are global variables and stack locations (parameters and local variables), to discover which objects are still alive; it marks each object it finds
- Then, the GC process looks at links (references) inside these objects, and recurses into those objects that haven't already been marked
- The GC can then start moving / copying all marked objects so that they are compacted in memory
- The "free pointer", from whence new allocations occur, is reset to the end of this compacted chunk of memory
- If there is still "insufficient free memory", then more is allocated from the operating system
- All old objects that weren't marked during the scanning process are garbage and are implicitly discarded through the copying process and resetting of the free pointer.
The frequency of collections depends on the tuning of the GC, which may be affected by the operating system, the amount of physical memory, operating system memory pressure, user-controlled tweaks, underlying platform version revisions, dynamically optimized parameters, etc. Much of it comes down to deciding where the bar lies in that "insufficient free memory" test, though things get more complicated with generational collectors.