Gradual Notes

Recent Writing

Recent Notes

JIT De-optimization Triggers

7 min read

De-optimization (or deoptimization) is the process of invalidating JIT-compiled native code and falling back to interpreted execution. This happens when the assumptions that guided compilation become invalid. Understanding de-optimization triggers is crucial for writing JIT-friendly Ruby code.

Why De-optimization Exists

YJIT execution mechanics relies on speculative optimization - making assumptions about types, method definitions, and runtime behavior to generate fast native code. But Ruby is dynamic: types change, methods get redefined, execution gets traced. When assumptions break, the compiled code becomes incorrect or unsafe.

De-optimization preserves correctness: better to fall back to slow-but-correct interpretation than execute fast-but-wrong native code.

The Four Major Triggers

1. Type Assumption Violations

YJIT’s biggest performance wins come from assuming types remain consistent. When type guards detect type changes, de-optimization triggers:

def calculate(x)
  x * 2  # YJIT assumes Integer after profiling
end
 
# During profiling/early calls - all integers
calculate(5)
calculate(10)
calculate(100)
 
# YJIT compiles assuming Integer input
 
# Type guard fails - de-optimize!
calculate(3.14)  # Float violates assumption

What happens during de-optimization:

  1. Type guard fails (detected in native code)
  2. Take side exit - jump to pre-defined exit point
  3. Restore interpreter state (stack pointer, instruction pointer)
  4. Clear jit_entry pointer in instruction sequence
  5. Return to interpreter
  6. Reset call counter to restart profiling
  7. Eventually re-compile with new type information
Type Guard Failure Flow:
┌──────────────────┐
│ Native code      │
│ executing        │
└────────┬─────────┘
         │
         ▼
    ┌────────────┐
    │Type guard  │
    │check       │
    └─────┬──────┘
          │
    ┌─────┴──────┐
    │            │
  Pass?      Fail?
    │            │
    ▼            ▼
┌────────┐  ┌────────────────┐
│Continue│  │Side Exit:      │
│native  │  │1. Restore state│
│code    │  │2. Clear entry  │
│        │  │3. Return to    │
└────────┘  │   interpreter  │
            └────────────────┘

A side exit is the escape mechanism from JIT-compiled code. It’s a pre-compiled sequence that restores the interpreter’s execution state when assumptions break.

Polymorphic code - code that handles multiple types - triggers repeated de-optimization:

def process(value)
  value.to_s.upcase
end
 
# Pathological case for JIT
process(42)        # Integer - compile
process("hello")   # String - de-optimize, re-compile
process(:symbol)   # Symbol - de-optimize, re-compile
process([1,2,3])   # Array - de-optimize, re-compile
# Each type change wastes compilation effort

Prevention strategy: Keep types consistent in hot paths. Use separate methods for different types rather than polymorphic dispatch.

2. TracePoint Activation

Ruby’s TracePoint API enables observing program execution for debugging, profiling, and code analysis. But JIT-compiled code bypasses the VM’s event system:

def perform_work
  step1
  step2
  step3
end
 
# Method gets JIT compiled for performance
 
# Activate tracing - forces de-optimization!
trace = TracePoint.new(:line, :call, :return) do |tp|
  puts "Event: #{tp.event} in #{tp.method_id}"
end
trace.enable
 
perform_work  # Now interpreted to fire TracePoint events

Why TracePoint forces de-optimization:

Native code executes directly on CPU - the VM doesn’t see individual bytecode instructions. TracePoint events like :line, :b_call, :c_call require the interpreter to execute each instruction and check for registered callbacks.

Execution with TracePoint:
┌────────────────────────┐
│ Bytecode instruction   │
└──────────┬─────────────┘
           │
           ▼
    ┌──────────────┐
    │ Check for    │
    │ TracePoint   │
    │ callbacks    │
    └──────┬───────┘
           │
      ┌────┴─────┐
      │          │
   Registered? None?
      │          │
      ▼          ▼
  ┌────────┐  ┌─────────┐
  │Fire    │  │Continue │
  │callback│  │execution│
  └────────┘  └─────────┘

Native code can’t perform this check - it’s compiled to execute a fixed sequence. So all JIT code must be invalidated when TracePoint activates.

Impact on debugging:

Production applications run fast with JIT. Development with debuggers/profilers runs interpreted - potentially hiding performance bugs that only appear in JIT-compiled code.

Prevention strategy: Profile production workloads without TracePoint when possible. Use sampling profilers that don’t force de-optimization.

3. Method Redefinition

Ruby’s open classes allow redefining methods at runtime. When a method changes, any compiled code calling it becomes invalid:

class Calculator
  def add(x, y)
    x + y
  end
end
 
calc = Calculator.new
 
# This gets JIT compiled
1000.times { calc.add(5, 10) }
 
# Redefinition invalidates JIT code
class Calculator
  def add(x, y)
    x + y + 1  # Changed behavior!
  end
end
 
# All compiled code calling add is de-optimized
calc.add(5, 10)  # Back to interpreter

Method dependency tracking:

YJIT maintains a dependency graph:

Compiled Code Dependencies:
┌─────────────────┐
│ main_loop       │
│ (compiled)      │
└────────┬────────┘
         │ calls
         ▼
    ┌────────────┐
    │ Calculator │
    │ #add       │
    └────────────┘
         │
    Redefined!
         │
         ▼
    ┌────────────┐
    │ Invalidate │
    │ main_loop  │
    └────────────┘

When #add is redefined, YJIT walks the dependency graph and invalidates all compiled code that calls it.

Constant redefinition also triggers de-optimization:

MULTIPLIER = 2
 
def scale(x)
  x * MULTIPLIER  # YJIT inlines constant value
end
 
scale(10)  # Compiled with MULTIPLIER = 2
 
MULTIPLIER = 3  # De-optimize! Inlined value now wrong

Prevention strategy: Avoid redefining methods in hot paths. Use configuration objects instead of redefining constants.

4. Ractor Usage

Ractors enable true parallel execution by running Ruby code on multiple threads without the GVL. This introduces concurrency challenges for JIT compilation:

# JIT compilation works fine
def calculate(n)
  n * 2
end
 
calculate(42)  # Gets compiled
 
# Ractor creation forces de-optimization
r = Ractor.new do
  calculate(100)  # Now de-optimized for thread safety
end

Why Ractors force de-optimization:

JIT-compiled code makes assumptions about object layout, method caching, and shared state. Ractors can access objects from different threads, potentially violating these assumptions:

  • Object mutations: Two Ractors might modify shared objects concurrently
  • Method cache coherence: Method caches become invalid across Ractors
  • Memory ordering: Native code might not respect memory barriers needed for parallelism

Current YJIT takes the conservative approach: de-optimize when Ractors exist to ensure correctness.

Future improvements:

Ractor support is evolving. Future YJIT versions may:

  • Generate Ractor-safe code with appropriate barriers
  • Maintain separate compiled code per Ractor
  • Use copy-on-write for shared compiled code

Prevention strategy: Be aware that Ractors currently disable JIT benefits. Profile both single-threaded and Ractor-based execution.

De-optimization Cost Analysis

De-optimization isn’t free. It involves:

  1. Immediate cost: Exiting native code, clearing jit_entry pointer
  2. Ongoing cost: Re-interpreting bytecode (slower execution)
  3. Re-compilation cost: Profiling and re-compiling (if code stays hot)
De-optimization Timeline:
Time →
│
│ ▲ Performance
│ │
│ ├─────────────┐              ┌──────────
│ │ JIT code    │              │ Re-compiled
│ │ executing   │              │ (if hot)
│ └─────────────┼──────────────┤
│               │ De-optimize  │
│               │ Interpret    │
│               └──────────────┘
│                     ↑
│                 Performance drop
│
└─────────────────────────────────────────→

Frequent de-optimization = performance killer:

If code de-optimizes repeatedly (polymorphic types, frequent redefinitions), the compilation overhead outweighs benefits. The VM wastes time compiling code that immediately becomes invalid.

Monitoring De-optimization

Ruby provides tools to observe JIT behavior:

# Enable YJIT with statistics
ruby --yjit --yjit-stats script.rb
 
# Output includes:
# - Methods compiled
# - De-optimization count
# - Invalidation reasons
# - Type guard failures

Key metrics to watch:

  • Invalidation rate: High rate indicates unstable assumptions
  • Re-compilation frequency: Same method compiled multiple times
  • Type guard failures: Which guards fail most often

Production monitoring:

In production, de-optimization events can indicate:

  • Unexpected type patterns (data validation issues?)
  • Configuration changes (constants being redefined?)
  • Debugging tools left active (TracePoint still enabled?)

Designing for JIT Stability

To minimize de-optimization:

1. Type Stability

# Bad: Polymorphic input
def process(value)
  value.to_s.upcase
end
 
# Good: Type-specific methods
def process_string(str)
  str.upcase
end
 
def process_number(num)
  num.to_s.upcase
end

2. Avoid Runtime Redefinition

# Bad: Runtime configuration via redefinition
class Service
  def endpoint
    "http://localhost"
  end
end
 
# Later...
class Service
  def endpoint
    "http://production.com"  # De-optimization!
  end
end
 
# Good: Configuration object
class Service
  def initialize(config)
    @config = config
  end
 
  def endpoint
    @config.endpoint  # Stable method, data varies
  end
end

3. Conditional TracePoint

# Bad: Always-on tracing
TracePoint.trace(:line) { |tp| log(tp) }
 
# Good: Development-only tracing
if ENV['DEBUG']
  TracePoint.trace(:line) { |tp| log(tp) }
end

4. Ractor Awareness

# If using Ractors, accept JIT won't help
# Focus on parallelism benefits instead
 
# Or isolate Ractor usage to specific modules
# Keep hot paths Ractor-free for JIT benefits

Understanding de-optimization reveals the delicate balance JIT compilers maintain: aggressive optimization for common cases, safe fallback for edge cases, and graceful degradation when assumptions break. Writing JIT-friendly code means keeping assumptions stable, types consistent, and dynamic features minimal in performance-critical paths.

Recent Writing

Recent Notes

Graph View

Backlinks