Stack vs Heap

Overview

Stack and heap represent two distinct memory regions that programs use to store data during execution. Each region follows different allocation strategies, access patterns, and lifetime management rules. The stack operates as a Last-In-First-Out (LIFO) structure for managing function calls and local variables, while the heap provides dynamic memory allocation for objects with flexible lifetimes.

The distinction between stack and heap affects program performance, memory usage patterns, and debugging strategies. Stack allocation occurs automatically when entering function scope and deallocates when leaving scope. Heap allocation requires explicit request through language mechanisms and typically involves garbage collection or manual deallocation.

Memory layout in a typical process separates these regions:

High Memory
+------------------+
|      Stack       |  ← Grows downward
|        ↓         |
+------------------+
|                  |
|   Unused Space   |
|                  |
+------------------+
|        ↑         |
|      Heap        |  ← Grows upward
+------------------+
|   Static Data    |
+------------------+
|   Code Segment   |
+------------------+
Low Memory

Stack memory grows from high addresses toward low addresses, while heap memory grows from low addresses toward high addresses. This arrangement maximizes available memory for both regions before they collide.

Key Principles

Stack Memory Management

The stack maintains a contiguous block of memory organized as a stack data structure. When a function executes, the program pushes a stack frame containing local variables, parameters, and return address onto the stack. Upon function return, the stack frame pops off, automatically deallocating all local data.

Stack frames contain:

• Function parameters passed by value
• Local variables declared within function scope
• Return address for resuming execution in calling function
• Saved register values for function context
• Frame pointer for accessing local variables

Stack pointer register tracks the current top of stack. Allocation increments or decrements this pointer by the required byte count. Deallocation simply adjusts the pointer back, making stack operations extremely fast.

Heap Memory Management

The heap provides dynamic memory allocation without scope restrictions. Programs request heap memory through allocation functions, receiving pointers to memory blocks. These blocks persist until explicitly deallocated or garbage collected.

Heap allocation involves:

• Searching free list or memory pool for adequate space
• Updating memory management metadata
• Returning pointer to allocated block
• Tracking allocation for later deallocation

Memory allocators maintain data structures (free lists, buddy systems, slab caches) to manage heap space efficiently. Fragmentation occurs when allocation and deallocation patterns leave small unusable gaps between allocated blocks.

Lifetime and Scope

Stack memory follows lexical scope. Variables allocated on stack exist only within their defining function. Attempting to return pointers to stack variables creates dangling pointers after function return:

function create_danger
  local_variable = 42
  return &local_variable  // Danger: points to deallocated memory
end

Heap memory persists beyond allocation scope until deallocated. Multiple references can point to the same heap object, requiring reference counting or garbage collection to determine safe deallocation timing.

Access Patterns

Stack access exhibits excellent spatial and temporal locality. Sequential function calls place related data contiguously in memory, improving CPU cache performance. The stack's predictable access pattern enables efficient prefetching.

Heap access patterns vary based on allocation strategy. Related objects allocated at different times may scatter across memory, reducing cache effectiveness. Memory allocators attempt to group related allocations, but fragmentation degrades locality over time.

Allocation Speed

Stack allocation requires only adjusting the stack pointer, typically one or two CPU instructions. This constant-time operation makes stack allocation extremely fast regardless of data size.

Heap allocation involves multiple steps: searching for free space, updating allocator metadata, possibly requesting memory from operating system. These operations scale with heap size and fragmentation, making allocation time variable and typically slower than stack allocation.

Ruby Implementation

Ruby abstracts memory management from developers, handling both stack and heap allocation automatically. The Ruby virtual machine (VM) manages the stack for method calls and local variables, while the heap stores all objects.

Object Allocation

Ruby allocates all objects on the heap. This includes instances of custom classes, arrays, hashes, strings, and even integers beyond a certain range. The Ruby VM maintains object references as pointers to heap memory:

# Heap allocation
user = User.new              # User object on heap
numbers = [1, 2, 3, 4, 5]    # Array object on heap
data = { name: "Ruby" }       # Hash object on heap
message = "Hello World"       # String object on heap

# These objects persist until garbage collection
def create_objects
  temp = "Temporary"  # String on heap, reference on stack
  temp                # Returns reference
end

result = create_objects  # result references heap object

Fixnum Optimization

Ruby optimizes small integers (Fixnum in Ruby 2.x, unified Integer in Ruby 2.4+) by encoding them directly in the pointer value rather than allocating heap objects. This immediate value representation avoids heap allocation overhead for common integer operations:

# Small integers stored as immediate values
small = 42        # No heap allocation
large = 10**100   # Bignum allocated on heap

# Check representation
small.class       # => Integer (immediate value)
large.class       # => Integer (heap object)

# Performance difference
require 'benchmark'

Benchmark.bm do |x|
  x.report("small:") { 1_000_000.times { a = 42; a + 1 } }
  x.report("large:") { 1_000_000.times { a = 10**100; a + 1 } }
end

Stack Usage

Ruby's VM stack stores method call frames containing:

• Local variable references (pointers to heap objects)
• Method parameters
• Block arguments
• Return addresses
• Frame control information

def calculate(x, y)
  # x, y references stored on VM stack
  result = x + y  # result reference stored on VM stack
  result          # Returns heap object reference
end

value = calculate(10, 20)
# After method return, stack frame deallocates
# but heap objects persist if referenced

Symbols and Frozen Strings

Ruby stores symbols in a special symbol table rather than creating new objects for each occurrence. This provides memory efficiency and fast comparison:

# Symbols reference same object
sym1 = :name
sym2 = :name
sym1.object_id == sym2.object_id  # => true

# Frozen string literals (Ruby 2.3+)
str1 = "frozen".freeze
str2 = "frozen".freeze
str1.object_id == str2.object_id  # => true with frozen_string_literal

# Regular strings create new objects
str3 = "regular"
str4 = "regular"
str3.object_id == str4.object_id  # => false

Garbage Collection

Ruby uses mark-and-sweep garbage collection to reclaim heap memory. The collector traces reachable objects from root references (stack variables, global variables, constants) and marks them. Unmarked objects become candidates for collection:

# Object eligible for GC
def create_temporary
  temp = "Temporary data"
  # temp becomes unreachable after method return
end

create_temporary
GC.start  # Explicitly trigger collection

# Object remains reachable
def create_permanent
  $global = "Permanent data"  # Global reference keeps alive
end

create_permanent
GC.start  # Object survives collection

Memory Statistics

Ruby provides methods to inspect heap and stack usage:

# Heap statistics
stats = GC.stat
puts "Heap slots: #{stats[:heap_available_slots]}"
puts "Live objects: #{stats[:heap_live_slots]}"
puts "Free slots: #{stats[:heap_free_slots]}"

# Memory usage
require 'objspace'
ObjectSpace.count_objects
# => {:TOTAL=>50000, :FREE=>20000, :T_OBJECT=>1000, ...}

# Object allocation tracing
ObjectSpace.trace_object_allocations_start
array = [1, 2, 3]
file = ObjectSpace.allocation_sourcefile(array)
line = ObjectSpace.allocation_sourceline(array)
ObjectSpace.trace_object_allocations_stop

Practical Examples

Stack Overflow from Deep Recursion

Stack space is limited. Deep recursion or large local arrays can exhaust stack memory:

def infinite_recursion(n)
  infinite_recursion(n + 1)  # Each call adds stack frame
end

# Raises SystemStackError
begin
  infinite_recursion(0)
rescue SystemStackError => e
  puts "Stack exhausted: #{e.message}"
end

# Tail recursion optimization (limited in Ruby)
def factorial_tail(n, accumulator = 1)
  return accumulator if n <= 1
  factorial_tail(n - 1, n * accumulator)
end

# Alternative: iteration uses single stack frame
def factorial_iterative(n)
  result = 1
  (2..n).each { |i| result *= i }
  result
end

Heap Object Lifetime

Objects persist on heap until no references remain:

class DataProcessor
  def process(data)
    # Temporary processing objects
    temp_array = data.map { |x| x * 2 }
    temp_hash = temp_array.each_with_object({}) { |v, h| h[v] = true }
    
    # Return value keeps one object alive
    temp_hash.keys
    # temp_array becomes unreachable after return
  end
end

processor = DataProcessor.new
result = processor.process([1, 2, 3])
# result keeps returned array alive
# temp_array and temp_hash eligible for GC

Memory Leak from Unintended References

Global references or class variables prevent garbage collection:

class CacheExample
  @@cache = {}
  
  def self.store(key, value)
    @@cache[key] = value  # Persists until process ends
  end
  
  def self.clear
    @@cache.clear  # Explicit cleanup required
  end
end

# Memory accumulates
10_000.times do |i|
  CacheExample.store("key_#{i}", "x" * 1_000_000)
end

# Memory remains allocated
GC.start
puts "Cache size: #{CacheExample.class_variable_get(:@@cache).size}"

# Fix: implement size limit or use WeakRef
require 'weakref'

class BetterCache
  def initialize(max_size = 1000)
    @cache = {}
    @max_size = max_size
  end
  
  def store(key, value)
    @cache.delete(@cache.keys.first) if @cache.size >= @max_size
    @cache[key] = value
  end
end

Stack vs Heap Performance

Comparing allocation patterns shows stack efficiency:

require 'benchmark'

def stack_heavy_operation
  # Method parameters and locals on stack
  x = 1
  y = 2
  z = 3
  result = x + y + z
end

def heap_heavy_operation
  # Object allocations on heap
  array = [1, 2, 3]
  hash = { x: 1, y: 2, z: 3 }
  string = "result: #{array.sum}"
  string
end

iterations = 100_000

Benchmark.bm(20) do |x|
  x.report("stack-heavy:") do
    iterations.times { stack_heavy_operation }
  end
  
  x.report("heap-heavy:") do
    iterations.times { heap_heavy_operation }
  end
end

# Stack operations significantly faster

Closure and Heap Retention

Closures capture references, keeping objects alive:

def create_closure
  large_data = "x" * 1_000_000  # Heap allocation
  
  # Closure captures large_data reference
  lambda { large_data.length }
  # large_data remains on heap while closure exists
end

closure = create_closure
GC.start
puts "Data still accessible: #{closure.call}"

# Release closure to allow GC
closure = nil
GC.start
# Now large_data can be collected

String Concatenation Patterns

Different string building approaches affect heap allocation:

require 'benchmark'

n = 10_000

Benchmark.bm(20) do |x|
  x.report("concatenation:") do
    result = ""
    n.times { |i| result += "item#{i}" }
  end
  
  x.report("append:") do
    result = ""
    n.times { |i| result << "item#{i}" }
  end
  
  x.report("join:") do
    items = []
    n.times { |i| items << "item#{i}" }
    result = items.join
  end
  
  x.report("string builder:") do
    result = String.new
    n.times { |i| result << "item#{i}" }
  end
end

# += creates new string each iteration (more heap allocations)
# << modifies string in place (fewer allocations)
# join creates single final string

Performance Considerations

Allocation Speed Differences

Stack allocation completes in constant time regardless of data size. The VM adjusts stack pointer and initializes memory. Heap allocation scales with heap size, fragmentation, and allocator complexity:

require 'benchmark'

def measure_allocation_patterns
  Benchmark.bm(25) do |x|
    x.report("method calls (stack):") do
      1_000_000.times do
        def sample_method(a, b, c)
          x = a + b
          y = b + c
          x + y
        end
        sample_method(1, 2, 3)
      end
    end
    
    x.report("object creation (heap):") do
      1_000_000.times do
        object = Object.new
      end
    end
    
    x.report("array creation (heap):") do
      1_000_000.times do
        array = [1, 2, 3]
      end
    end
  end
end

Cache Locality

Stack access benefits from CPU cache due to sequential memory layout. Heap access patterns depend on allocation order and can suffer cache misses:

# Poor cache locality: scattered heap allocations
def scattered_access(n)
  objects = n.times.map { Object.new }
  objects.each { |obj| obj.instance_variable_set(:@value, 42) }
end

# Better locality: contiguous array
def contiguous_access(n)
  array = Array.new(n, 42)
  array.each { |value| value * 2 }
end

# Measure cache effects
require 'benchmark'

n = 100_000

Benchmark.bm(20) do |x|
  x.report("scattered:") { scattered_access(n) }
  x.report("contiguous:") { contiguous_access(n) }
end

Garbage Collection Overhead

Heap allocation incurs garbage collection cost. Large heap sizes increase collection pause times:

# Monitor GC impact
GC::Profiler.enable

def generate_garbage
  100_000.times { Array.new(100) { "x" * 100 } }
end

generate_garbage

puts GC::Profiler.result
GC::Profiler.disable

# Reduce allocations
def optimized_generation
  # Reuse objects where possible
  buffer = Array.new(100)
  100_000.times do
    buffer.map! { "x" * 100 }
  end
end

Memory Pooling

Reusing objects reduces allocation overhead:

class ObjectPool
  def initialize(size, &block)
    @pool = Array.new(size, &block)
    @available = @pool.dup
  end
  
  def acquire
    @available.pop || raise("Pool exhausted")
  end
  
  def release(object)
    @available.push(object)
  end
end

# Usage
pool = ObjectPool.new(100) { Array.new(1000) }

Benchmark.bm(20) do |x|
  x.report("pooled:") do
    10_000.times do
      array = pool.acquire
      array.fill(0)
      pool.release(array)
    end
  end
  
  x.report("allocated:") do
    10_000.times do
      array = Array.new(1000)
      array.fill(0)
    end
  end
end

Stack Size Limits

Default stack sizes vary by platform. Deep recursion requires increasing stack size:

# Check current stack size
def measure_stack_depth(n = 0)
  measure_stack_depth(n + 1)
rescue SystemStackError
  puts "Maximum depth: #{n}"
end

measure_stack_depth

# Increase stack size (system dependent)
# Unix: ulimit -s <size_in_kb>
# Ruby: RUBY_THREAD_VM_STACK_SIZE environment variable

# Alternative: convert to iteration
def deep_process(items)
  stack = items.dup
  results = []
  
  until stack.empty?
    item = stack.pop
    results << process_item(item)
  end
  
  results
end

Memory Fragmentation

Long-running processes accumulate heap fragmentation:

# Simulate fragmentation
def create_fragmentation
  arrays = []
  
  # Allocate various sizes
  1000.times do |i|
    size = (i % 10 + 1) * 100
    arrays << Array.new(size)
  end
  
  # Deallocate alternating elements
  arrays.each_with_index { |arr, i| arrays[i] = nil if i.even? }
  
  GC.start
  
  # Heap now fragmented with gaps
end

# Monitor fragmentation
stats_before = GC.stat
create_fragmentation
stats_after = GC.stat

puts "Fragmentation increase: #{stats_after[:heap_free_slots] - stats_before[:heap_free_slots]}"

Common Pitfalls

Returning Stack References

Languages with explicit pointers can return stack addresses. Ruby prevents this by copying or maintaining heap references:

# Ruby always returns heap references
def create_value
  local = "stack reference"
  local  # Returns reference to heap string
end

result = create_value
puts result  # Safe: string persists on heap

Unbounded Recursion

Forgetting base cases exhausts stack:

# Missing base case
def factorial(n)
  n * factorial(n - 1)  # Never terminates
end

# Correct implementation
def factorial_correct(n)
  return 1 if n <= 1
  n * factorial_correct(n - 1)
end

# Better: iterative approach
def factorial_iterative(n)
  (1..n).reduce(1, :*)
end

Memory Leak Misconceptions

Ruby's garbage collection prevents traditional memory leaks, but reference retention still wastes memory:

# Unintentional retention
class EventManager
  def initialize
    @handlers = []
  end
  
  def register(handler)
    @handlers << handler  # Retains reference
  end
  
  # Missing unregister method
  # Handlers never deallocate
end

# Fix: provide cleanup
class BetterEventManager
  def initialize
    @handlers = []
  end
  
  def register(handler)
    @handlers << handler
  end
  
  def unregister(handler)
    @handlers.delete(handler)
  end
  
  def clear
    @handlers.clear
  end
end

Large Local Variables

Allocating large structures as locals still uses heap:

def process_data
  # Large array on heap, reference on stack
  large_array = Array.new(1_000_000) { rand }
  
  # Processing
  large_array.map { |x| x * 2 }
end

# Memory consumed during execution
# Released after method return

Circular References

Ruby's GC handles cycles, but they delay collection:

class Node
  attr_accessor :next, :value
  
  def initialize(value)
    @value = value
    @next = nil
  end
end

# Create cycle
node1 = Node.new(1)
node2 = Node.new(2)
node1.next = node2
node2.next = node1

# Both nodes reference each other
# Ruby GC detects and collects cycles
node1 = nil
node2 = nil
GC.start  # Cycle collected

# Prevent cycles when possible
def create_chain(n)
  nodes = n.times.map { |i| Node.new(i) }
  nodes.each_cons(2) { |a, b| a.next = b }
  nodes.first  # Return head only
end

Stack Overflow in Frameworks

Deep middleware chains or callbacks can exceed stack:

# Middleware chain
class Middleware
  def initialize(app)
    @app = app
  end
  
  def call(env)
    # Processing
    @app.call(env)  # Recurses through chain
  end
end

# Limit middleware depth
class MiddlewareStack
  MAX_DEPTH = 100
  
  def initialize
    @stack = []
  end
  
  def use(middleware)
    raise "Stack too deep" if @stack.size >= MAX_DEPTH
    @stack << middleware
  end
end

Premature Optimization

Optimizing for stack vs heap prematurely adds complexity:

# Over-optimized: trying to "save" allocations
def process_items_complex(items)
  # Reusing array to "save" allocations
  buffer = []
  results = []
  
  items.each do |item|
    buffer.clear
    buffer << item * 2
    results << buffer.dup
  end
  
  results
end

# Clear and sufficient
def process_items_simple(items)
  items.map { |item| [item * 2] }
end

# Optimize only when profiling identifies bottleneck

Reference

Memory Region Characteristics

Data Location by Type

Ruby Memory Operations

Performance Optimization

Common Errors