Detecting Deoptimizations

Traces every deoptimization event where execution falls back from compiled code to interpreter. Critical for finding the most severe performance problems.

Why Deoptimizations Are Catastrophic

• •Single transfer cost: Hundreds of nanoseconds (vs ~5ns for normal call)
• •Deoptimization loops: 10-100x slower than pure interpreter!
• •Wasted compilation: Compile → deoptimize → recompile → deoptimize = disaster

Goal: Zero transfers in steady-state execution!

When to Use This Skill

• •Investigate poor performance despite successful compilation
• •Profile shows methods in interpreted mode
• •Debug why compiled code keeps falling back
• •Verify benchmarks have properly warmed up

Quick Start

# Basic deoptimization trace
<launcher> --experimental-options \
  --engine.TraceTransferToInterpreter <program>

# Combined with compilation trace (HIGHLY RECOMMENDED)
<launcher> --experimental-options \
  --engine.TraceTransferToInterpreter \
  --engine.TraceCompilation \
  <program> 2>&1 | tee transfers.log

# Focus on specific function
<launcher> --experimental-options \
  --engine.TraceTransferToInterpreter \
  --engine.CompileOnly=functionName \
  <program>

⚠️ REQUIRED: Fermi Verification (Every Tool Invocation)

Before running:

• • Pre-calculate: Expected transfers (0-50 during warmup, 0 in steady-state)
• • Smoke test: <launcher> --experimental-options --engine.TraceTransferToInterpreter -c 'print 1;' → Verify no false transfers

After running:

• • Validate: Transfer count within expectation? YES / NO
• • If >100 transfers: CRITICAL - Deoptimization loop, analyze repeated locations
• • Save output: tool-outputs/trace-transfers-[benchmark].txt

Gate: All boxes checked? → Proceed to analysis

Key Options

Understanding Output

Transfer Event

[engine] transferToInterpreter at
problemFunction(<source>:42:123-456)
callerFunction(<source>:18:78-90)
topLevelFunction(<source>:5:10-50)

Problem Patterns

Pattern 1: Deoptimization Loop (CRITICAL!)

[engine] transferToInterpreter at MyNode.execute(<source>:42)
[engine] transferToInterpreter at MyNode.execute(<source>:42)
[engine] transferToInterpreter at MyNode.execute(<source>:42)
...dozens more at same location...

🚨 This is catastrophic! Often worse than never compiling.

Cause: Unstable type assumptions Fix: Implement proper type specializations, avoid mixing types

Pattern 2: Warmup Transfers (Normal)

[First 5 seconds]
...many transfers...
[After 10+ seconds]
[No more transfers]  ✅

Acceptable: Decreases over time, stops after warmup

Pattern 3: Rare Path Transfers (Acceptable)

[During entire execution]
[engine] transferToInterpreter at errorHandler(<source>:250)

Acceptable: Infrequent, from error handling or validation

Transfer Count Guidelines

Analysis Commands

# Count total transfers
grep -c "transferToInterpreter" transfers.log

# Count unique locations
grep "transferToInterpreter at" transfers.log | sort -u | wc -l

# Find repeated locations (deoptimization loops)
grep "transferToInterpreter at" transfers.log | sort | uniq -c | sort -rn

Integration with Other Skills

Related Skills

• •tracing-compilation-events - See compilation cycles
• •profiling-with-cpu-sampler - Measure impact
• •detecting-performance-warnings - Find barriers
• •analyzing-compiler-graphs - Deep analysis

Reference

<launcher> --help:engine | grep -i transfer

See PATTERNS.md for detailed problem patterns and solutions.