DEV Community: Damilare Akinlaja

Building a JIT Compiler from Scratch: Part 1 — Why Build a JIT Compiler?

Damilare Akinlaja — Thu, 19 Feb 2026 17:28:35 +0000

After reading Crafting Interpreters, I thought building a bytecode VM would be enough. I built Cabasa, a WebAssembly runtime. I’m now building Rayzor, a Haxe compiler in Rust. Each project taught me the same lesson: interpretation has a ceiling.

I could wire up Cranelift or LLVM and call it done. But I wanted to understand JIT compilation from first principles — what happens between IR (Intermediate Representation) and machine code, and why it makes things fast. This series is that journey.

In Part 0, we explored how computers run our code, and touched on the history of compilers and runtimes. Now we will actually write a JIT compiler.

The Interpreter Performance Ceiling

In a bytecode interpreter, we use symbols (opcodes) to represent instructions, these opcodes are encoded in a byte array which are then looped through for translation. The code below demonstrates a typical stack-based interpreter.

// A simple bytecode interpreter loop
#[repr(u8)]
enum Opcode {
    Add,
    Sub,
    Mul,
    Load,
    Store,
    Jump,
    Return,
    // ... dozens more
}
fn interpret(bytecode: &[u8], constants: &[i64]) -> i64 {
    let mut ip: usize = 0;                    // Instruction pointer
    let mut stack: Vec<i64> = Vec::new();

    loop {
        // ┌─────────────────────────────────────────────────────┐
        // │ FETCH: Memory read, bounds check                    │
        // │ Cost: ~3-5 cycles                                   │
        // └─────────────────────────────────────────────────────┘
        let opcode = bytecode[ip];
        ip += 1;
        // ┌─────────────────────────────────────────────────────┐
        // │ DECODE + DISPATCH: Branch on opcode                 │
        // │ Cost: ~10-20 cycles (branch misprediction penalty)  │
        // │                                                     │
        // │ The CPU tries to predict which case we'll take.     │
        // │ With 50+ opcodes, it guesses wrong ~95% of the time.│
        // │ Each misprediction: flush pipeline, start over.     │
        // └─────────────────────────────────────────────────────┘
        match opcode {
            0 => {  // Add
                // ┌─────────────────────────────────────────────┐
                // │ EXECUTE: The actual work                    │
                // │ Cost: 1 cycle                               │
                // └─────────────────────────────────────────────┘
                let b = stack.pop().unwrap();
                let a = stack.pop().unwrap();
                stack.push(a + b);  // <-- This is ALL we wanted to do
            }
            1 => {  // Sub
                let b = stack.pop().unwrap();
                let a = stack.pop().unwrap();
                stack.push(a - b);
            }
            2 => {  // Mul
                let b = stack.pop().unwrap();
                let a = stack.pop().unwrap();
                stack.push(a * b);
            }
            3 => {  // Load constant
                let idx = bytecode[ip] as usize;
                ip += 1;
                stack.push(constants[idx]);
            }
            4 => {  // Return
                return stack.pop().unwrap();
            }
            _ => panic!("Unknown opcode"),
        }
        // Then we loop back and do it ALL again for the next instruction
    }
}

Why is this slow? Because we pay the price in CPU branch misprediction penalties. Let’s look at how a modern CPU executes instructions.

The CPU Pipeline

Your computer’s CPU does not execute instructions one at a time, while one instruction is being executed, the next is being decoded, and the one after that is being fetched, simultaneously.

Modern CPUs have between 15–20+ pipeline stages. This means the instructions are “in-flight” all at once. This is great for throughput, but there is a catch!

The Branching Problem

The CPU maintains a branch prediction mechanism, a hardware feature in modern processors that guesses the outcome of conditional branches like if-statements and loops. The CPU gains a massive performance boost when it is able to predict branching patterns, but when it can’t predict the patterns it “flushes” the pipeline and that degrades the performance, this is the tax we pay.

Let’s take a look at a simple for-loop where the next iteration is determined by a simple increment from 0-n. The CPU can predict this pattern.

// Loop: branch taken 999 times, not taken once
for i in 0..1000 {   
    sum += i;        // Predictor learns: "always taken"
}                    // 99.9% accuracy

But for our interpreter, the CPU can’t predict the next opcode in the bytecode, the pipeline gets flushed on every instruction, this makes the interpreter inefficient, and causes a spike in latency.

I experienced this first hand: a Mandelbrot took about ~45s to complete with an interpreter, while the JIT version executed it in under 300ms.

So what exactly does a JIT compiler do differently? Let’s see what native code gets you.

INTERPRETER:                          JIT COMPILED:
─────────────────────────────────     ─────────────────────────────────
fetch opcode          ← branch        ; No dispatch loop
match opcode          ← branch        ; No opcode decoding  
  Add:                                ; Just the actual operations:
    pop, pop, add, push               
fetch opcode          ← branch        add x0, x1, x2
match opcode          ← branch        mul x3, x0, x4
  Mul:                                sub x5, x3, x6
    pop, pop, mul, push               
fetch opcode          ← branch        ; Linear code = perfect prediction
...                                   ; Pipeline stays full

The Numbers Don’t Lie

Here’s a real comparison from Rayzor, the Haxe compiler I’m building. Same source code, different execution strategies:

The interpreter spends most of its time deciding what to do. The JIT just does it.

Full benchmark methodology →

When we JIT compile, we eliminate the dispatch entirely: The branches that remain in JIT code (loops, conditionals) are your program’s branches — which often are predictable. The artificial dispatch branches are gone.

When JIT Makes Sense

Not every project requires a JIT compiler, it is really complex — especially if you intend to make it useful in real world applications. But in the right scenarios the pay-off is great!

Long-Running Programs
If your program runs for seconds, minutes, or hours, JIT compilation cost becomes negligible. The time spent compiling hot functions is amortized across millions of executions.

Examples of Long-Running Programs: Web servers and application backends, database query engines, game engines with scripting, IDEs and developer tools.
The Common pattern: Startup can be slow; steady-state performance matters.

Dynamic Languages In dynamic languages, you don’t know the type of most values until runtime. For example, let’s look at the code snippet below for an untyped dynamic language:

function process(item) {
    return item.value * 2;
}
// Same call site receives different types over time
eventQueue.forEach(item => process(item));
// Iteration 1-1000:   item is {value: Number}
// Iteration 1001:     item is {value: String}  ← type changed!
// AOT must handle ALL cases (slow)
// JIT observes: "99.9% are Numbers" → specializes → guards → fast path

No static analysis can predict this. The types depend on what data flows through the program — often from user input, network responses, or database queries.

AOT dilemma: It generates code that handles every possible type. Every operation becomes a type check followed by a dispatch.
JIT advantage: An opportunity to observe what actually happens at runtime, then specialize. The snippet below demonstrates how real world JIT runtimes will execute the code:

JIT observes: "First 1000 calls, item.value is always Number"
  → Compiles fast path: direct numeric multiplication
  → Inserts guard: "if not Number, bail out"
Iteration 1001: item.value is String

  → Guard fails
  → Deoptimize, fall back to interpreter [It is good to pair with an interpreter in such cases]
  → Recompile with polymorphic handling
Iteration 1002+: mostly Numbers again
  → Fast path still works 99.9% of the time

This is why V8, LuaJIT, and PyPy can approach native performance despite running dynamic languages. They don’t solve the “what type is this?” problem statically — they observe and adapt.

Statically typed languages still benefit greatly from JIT compilation than Dynamic languages, because we have solved the “what type is this” problem before handling hot functions in JIT, we get runtime performance boost, but we pay the cost in compile-time analysis phase.

Domain-Specific Languages

DSLs can benefit from JIT compilation, especially DSLs capable of expensive runtime behavior that simple interpreters can not optimise or data intensive applications.

Query engines: SQL JIT compilation (PostgreSQL, DuckDB)
Shader compilers: GPU pipeline optimization
Rule engines: Business logic that changes at runtime
Template engines: Server-side rendering
Expression evaluators and formula engines: Spreadsheets, Data filtering, financial models, animation curves

Hot Code Paths

It’s commonly observed that programs spend the majority of execution time (often cited as 90%) in a small fraction of the code.

“Studies have shown that a program typically spends 90% of its execution time in only 10% of its code.” — Jon Bentley, “Writing Efficient Programs” (1982)

A tiered JIT interprets the cold 90% of your code (which takes 10% of time) and compiles the hot 10% of your code (which takes 90% of time). Best of both worlds.

When JIT Is Overkill

Rule of thumb is to always start with an optimised interpreter, then evaluate if you need JIT.

Short-lived scripts: Compilation cost > execution time
Memory-constrained: JIT infrastructure is heavy
Predictable latency required: Compilation pauses are unpredictable
Simple glue code: Interpretation is fast enough

So Let’s Build One

We’ve covered a lot of ground : dispatch overhead, CPU pipelines, branch prediction, and when JIT makes sense. Now let’s get practical.

In this series, we’re building a JIT compiler from scratch. Not a toy that emits hardcoded bytes, but a real pipeline:

Source → IR → SSA → Optimize → ARM64 → Execute

Here’s the roadmap:

Part 2: A minimal Intermediate Representation (IR)
Part 3: Control Flow Graphs — blocks, branches, loops
Part 4: SSA transformation — making data flow explicit
Part 5: Dominance analysis — where to place φ-nodes
Part 6: Optimization passes — constant folding, dead code elimination
Part 7: ARM64 code generation — turning IR into machine code
Part 8: Register allocation — fitting values into hardware registers
Part 9: Executable memory — the Apple Silicon W^X challenge
Part 10: Testing across architectures with QEMU

Why ARM64?

Apple Silicon is everywhere now — MacBooks, iPads, even servers. ARM64 has a clean, fixed-width instruction set that’s easier to emit than x86’s variable-length encoding. And if you’re on Intel, we’ll use QEMU to test cross-platform.

But first, let’s write some machine code.

First Taste: Hello, Machine Code

Whew! Enough theory. Let’s generate and execute machine code.

If you don’t have Rust development environment on your computer, you need to set it up so that you can run the code examples.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Then create a new project:

cargo new jit-hello
cd jit-hello

Add dynasmrt to your cargo.toml file:

[dependencies]
dynasmrt = "5.0.0"

Now, the simplest possible JIT — a function that returns 42:

use dynasmrt::{dynasm, AssemblyOffset};
use dynasmrt::aarch64::Assembler;
fn main() {
    // Create an assembler for ARM64
    let mut asm = Assembler::new().unwrap();
    // Write actual assembly instructions
    dynasm!(asm
        ; mov x0, #42    // Return value goes in x0 (ARM64 calling convention)
        ; ret            // Return to caller
    );
    // Finalize: makes memory executable
    let code = asm.finalize().unwrap();
    // Cast to function pointer and call
    let func: fn() -> i64 = unsafe { 
        std::mem::transmute(code.ptr(AssemblyOffset(0))) 
    };
    println!("JIT returned: {}", func());
}

Run it:

$ cargo run
JIT returned: 42

That’s it. We wrote ARM64 assembly, it got encoded to machine code, and we executed it as a native function.

What Just Happened?
Let’s break it down:

Assembly::new() — Allocates a buffer for machine code
dynasm!(...) — Encodes our assembly into bytes (mov x0, #42 → 0xD2800540)
finalize() — Marks the memory where buffer was allocated as executable, this is where the OS gets involved.
transmute — Casts raw pointer to the callable function

The unsafe block is unavoidable, we're telling Rust "trust me, these bytes are a valid function." Since the transmute is also marked by the Rust standard library as unsafe because both the argument and the result must be valid, else it could cause undefined behavior. This is the JIT contract: we take responsibility for generating correct code.

Why This Doesn’t Scale

This is bad developer experience, very daunting task to write assembly by hand all the time.

We just hand-wrote two instructions. Real programs have:

Thousands of operations
Branches and loops
Function calls
Values competing for limited registers

Writing dynasm! blocks by hand would be unmaintainable. We need structure between "source code" and "machine code"—a representation we can analyze, optimize, and systematically lower.

That’s what the rest of this series builds. An Intermediate Representation.

In Part 2, we’ll design a minimal Intermediate Representation — the data structure that represents code in a form we can work with. We’ll define values, types, and operations, and build a function that does more than return a constant.

Teaser:

// Coming in Part 2:
let mut builder = FunctionBuilder::new("add");
let a = builder.param(Type::I64);
let b = builder.param(Type::I64);
let sum = builder.add(a, b);
builder.ret(sum);

Building a JIT Compiler from Scratch: Part 0 - How Computers Run Your Code

Damilare Akinlaja — Sun, 07 Dec 2025 05:52:47 +0000

This is the first part of the series on Building a JIT Compiler from Scratch. I have been exploring the world of compilers and interpreters for many years, from theory to many failed attempts. As a hobbyist trying to cure my curiosity. I did not have a Computer Science background even though programming was a mandatory course as a student of Applied Physics. Every advance topic I have learned about compilers were based on personal reading, learning and attempts.

Writing a language parser is the easy part, then it gets a bit dramatic once you start tree-walking your AST to interpret it. But I wanted to go beyond parsers and basic interpreters. My journey led me to the world of virtual machines, made attempts like developing Cabasa and Wasp experimental runtimes for WebAssembly, and now developing Zyntax - a multi-paradigm and multi-tier JIT compilation and runtime framework.

For the curious cats, I am writing this blog series to demystify compiler and virtual machine development. I might oversimplify some definitions or use diagrams to explain concepts, but the major fun part is in the hands-on coding of our own JIT compiler in Rust.

But first, let's touch on a brief overview of compilers and runtimes.

A Tour of Interpreters, Compilers and Everything In Between

Every time you run a program, something bridges the gap between your code and the transistors that execute it. That bridge is the programming language runtime, a program designed to interpret or translate your code.

Code Is Just Text

When you write:

fn add(a:i32, b:i32) -> i32:
    return a + b

This is meaningless to the CPU. The processor understands only binary encoded instructions specific to its architecture. Someone or something must translate this code.

Since the invention of high level programming languages, two main translation philosophies emerge:

Translate everything upfront (Compilation)
- Convert entire program to machine code before running
- Pay translation cost once
- Run at full hardware speed
Translate on demand (Interpretation)
- Read and execute code line by line
- Quick upstart, no upfront wait to compile
- Pay translation cost at repeatedly

The split, established in the 1950s, still define how we think about language implementation today.

A Brief History of Language Execution

The Foundations - 1950s

1952 - A-0 System

"All I had to do was to write down a set of call numbers, let the computer find them on the tape, bring them over and do the additions. This was the first compiler."

Grace Brewster Murray Hopper, A computer pioneer and United States Navy rear admiral created a system that translates symbolic mathematical code into machine language. Grace had been collecting subroutines and transcoded them on tape, each routine had a call number which the computer finds and then compute.

1958 - FORTRAN (FORmular TRANslator)

This is the first widely used high-level programming language with an optimizing compiler. Though it was first developed in 1954 by John Backus at IBM to simplify math programming, subsequent versions in 1958 introduced a features that made code reusable.

1958 - LISP

This is the first interpreted language. Lisp was created by John McCarthy at MIT, it's the second high-level language designed for symbolic computation. Lisp introduced the REPL (Read Evaluate Print Loop) system that interactively interprets Lisp code.

The Divergence - 1960s-70s

Between the 60s and 70s, more high-level programming languages had emerged, for systems programming, numerical computation, and rapid prototyping.

Compiled Languages: COBOL, FORTRAN, C

Systems programming and numerical computation
Maximum performance, minimal runtime overhead
Steep edit-compile-run cycle

Interpreted Languages: BASIC, early Smalltalk

Education, rapid prototyping
Immediate feedback, slow execution
Often 10-100x slower than compiled code

An Optimized Interpretation: The Bytecode Virtual Machine - 1980s

Bytecode immediate representations were introduced in this period with Smalltalk-80 as the first consistently object-oriented language (after Simula, which introduced OO concepts). Unlike in classical interpreters, Bytecode borrows the structure of machine code - compact opcodes and operands but they are interpreted by a virtual processor (not directly on the CPU via machine code). This makes it more efficient to interpret while remaining portable and higher-level than machine code.

Bytecode designs vary widely in abstraction level, some are quite close to machine code in structure, others are typically serialized abstract syntax trees.

Other benefits of the Bytecode virtual machine (VM) is that it allows languages to be executable anywhere the VM can run, this made languages (like UCSD Pascal's P-code) to be written once and run anywhere, using the Bytecode as a distribution format.

Just-In-Time Execution (JIT) - 1990s

In 1987, David Ungar and Randall Smith pioneered Just-In-Time compilation techniques while developing the Self programming language. Self was developed as an object-oriented language based on prototypes instead of classes. This design choice posed a significant challenge to the efficiency of the runtime implementation. Every operation was a method invocation, even simple operation like a variable access, this increased the complexity of the language's execution.

As a workaround to Self programming language's implementation bottleneck, the team experimented with several approaches that led to key innovations in Just-In-Time execution:

Adaptive optimization
Inline caching, poplymorphic inline caches
Type feedback and On-the-fly recompilation
Achieved half the speed of C language, proving that a dynamic language could also be fast

The Self language team's innovation eventually laid the foundation for modern JIT compilers in languages implementations like Java Hotspot Virtual Machine, and more recent ones like V8 (Javascript), LuaJIT (lua), PyPy (python).

JIT Changed Everything

Modern language implementations can now achieve best-in-class runtime performance without Ahead-Of-Time compilation to machine code. JIT opened the doors to more runtime innovation.

Java (1995) / Hotsport (1999)
- Bytecode + JIT hybrid architecture became mainstream
- Hot paths and Cold paths compilation philosophy for runtime optimization
- JIT became industry standard
Javascript / V8
- Earlier Javascript implementation started as a slow interpreter
- V8's JIT made Javascript among the fastest dynamic language implementations
Modern VMs combine everything
- Interpreter for cold startup (start fast, optimize later)
- Baseline JIT for quick compilation and hot paths (move hot code to JIT for better performance)

Execution Models Compared

Pure Interpretation

How it works:

A parser reads the source text and translate it into an Abstract Syntax Tree
AST contains information about the language which is used to decode what to execute
In a loop we walk the AST and interpret the next statement or operation in the tree.
Repeat for the next statement

Examples of interpreter implementations can be found in shell scripts and early programming language implementations of BASIC, Python, Ruby.

Characteristics:

Aspect	Assessment
Startup time	Instant
Execution speed	Slow (10-100x native)
Memory usage	Low
Debugging	Excellent (source available)
Portability	High (interpreter handles platform)

Why it's slow:

Parse/decode cost paid on every execution
Dispatch overhead
Little opportunity for optimization
No direct use of CPU's native instruction pipeline

Bytecode Interpretation

Bytecode gets its name from its structure: a sequence of bytes where each byte (or small group of bytes) encodes an instruction (or set of operands). Think of it as machine code for a virtual computer, it doesn't execute on the native CPU hardware. This buys you portability (the same bytecode runs anywhere the VM runs) and efficiency (no re-parsing source code on every execution).

How it works:

Compile source to bytecode (once)
Bytecode is sequence of simple operations
Interpreter loops: fetch opcode → dispatch to handler → execute

Popular examples of bytecode-based programming languages: Ruby MRI, Lua, early versions of Java, Wren.

Types of Bytecode Interpreters

Stack-based vs Register-based:

Stack-based (JVM, CPython, Wasm)     Register-based (Lua, Dalvik, LuaJIT)
─────────────────────────────────    ─────────────────────────────────────
push 3                               load r0, 3
push 4                               load r1, 4  
add          ; implicit operands     add r2, r0, r1   ; explicit operands
push 2                               load r3, 2
mul                                  mul r4, r2, r3

Smaller bytecode                     Fewer instructions
Simpler compiler                     Easier to optimize
More instructions executed           Maps better to real CPUs

Fixed vs Variable Width:

Fixed width (simpler, faster decode):
┌────────┬────────┬────────┬────────┐
│ opcode │ operand│ operand│ operand│   Always 4 bytes
└────────┴────────┴────────┴────────┘

Variable width (compact, complex decode):
┌────────┐  or  ┌────────┬────────┐  or  ┌────────┬────────┬────────┐
│ opcode │      │ opcode │ operand│      │ opcode │  wide operand   │
└────────┘      └────────┴────────┘      └────────┴────────┴────────┘

Characteristics:

Aspect	Assessment
Startup time	Fast (compile once)
Execution speed	Moderate (3-10x native)
Memory usage	Moderate
Debugging	Good (with source maps)
Portability	Excellent (bytecode is platform-independent)

Why it's faster than pure source interpretation:

Parsing done once, not per execution
Bytecode is compact (cache-friendly)
Simpler dispatch (opcode vs. AST node type)

Why it's still slow:

Dispatch overhead on every instruction
No native code generation
Can't use CPU's branch prediction effectively

Study Recommendation For Building Interpreters

If you are interested in building an interpreter, pure or bytecode based, I highly recommend Rob Nystrom's free book Crafting Interprers

A Tree-Walker Interpreter: https://craftinginterpreters.com/a-tree-walk-interpreter.html
A Bytecode Virtual Machine: https://craftinginterpreters.com/contents.html#a-bytecode-virtual-machine

Ahead-Of-Time (AOT) Compilation

AOT compilation transforms the source code into machine code once. Some implementations have to choose between aggressive optimization versus compile time. Optimization may take more time and this usually means you have to wait for the code to compile before you can run it. Most systems programming language implementations prefer AOT compilation for maximum performance. Some give you option to switch between JIT and AOT.

Common examples of AOT compiled languages are Rust, Haskell, C, C++, Go.

Characteristics:

Aspect	Assessment
Startup time	Instant (already compiled)
Execution speed	Fast (native)
Compile time	Slow (seconds to minutes)
Binary size	Depends on optimization
Portability	Low (recompile per platform)

Why it's fast:

No runtime interpretation overhead
Heavy optimization possible (compiler has time)
Direct use of CPU features

Limitations:

Must know everything at compile time
Can't optimize based on runtime behavior
Long edit-compile-run cycle

Just-In-Time Compilation

JIT gives you half the performance of AOT, yet more portable. If you are developing a programming language for long-running fault-tolerant servers, JIT is the best choice. Most modern JIT infrastructure starts out from the Cold Path - When the code runs the first time, it is interpreted for quicker execution, a profiler is then used to analyze the Hot Paths - When certain functions or operations are being used more frequently, or require better optimization to perform. Hot path code is recompiled into machine code and executed on-demand while the interpreter is still in process. Unlike AOT, the JIT architecture is a collaborative one, between the interpreter and the JIT executor.

Modern compiler vendors support JIT execution, giving you the opportunity to skip AOT compilation before executing machine code. Common examples are LLVM and Cranelift.

How it works:

Start executing (interpret or baseline compile)
Profile: track which code runs frequently, what types appear
Hot code triggers JIT compilation - inside the running process
Generated native code stored in executable memory - in the same address space
Continue profiling, recompile if behavior changes

Characteristics:

Aspect	Assessment
Startup time	Fast (interpret first)
Peak execution speed	Near-native
Warm-up time	Moderate (JIT needs profile)
Memory usage	High (code + compiler in memory)
Portability	Good (bytecode portable, JIT per-platform)

Why it can match AOT in some scenarios:

Optimizes based on actual runtime behavior
Can specialize for observed types
Can inline across module boundaries
Can deoptimize and reoptimize as behavior changes

Key Distinctions Between AOT and JIT Compilation

The fundamental tradeoff:

AOT	JIT
Compile once, run forever	Compile repeatedly, run smarter
Optimizations are guesses	Optimizations are informed
No runtime compilation cost	Pays compilation cost during execution
Predictable memory usage	Memory includes compiler infrastructure
Must handle all possible cases	Can specialize for observed cases

Summary

Programming language compilers and runtimes have evolved over many decades as computing advancements. In smaller projects, the differences in runtimes are not usually immediately obvious, but in performance and memory critical environments we begin to see where the other implementations shine and why they do. In upcoming sequels to this post, we will discuss the anatomy of modern high performance runtimes, the different optimization strategies, and then we will build a JIT compiler from scratch!

DEV Community: Damilare Akinlaja

Building a JIT Compiler from Scratch: Part 1 — Why Build a JIT Compiler?

The Interpreter Performance Ceiling

When JIT Makes Sense

When JIT Is Overkill

So Let’s Build One

First Taste: Hello, Machine Code

Further Reading

Building a JIT Compiler from Scratch: Part 0 - How Computers Run Your Code

A Tour of Interpreters, Compilers and Everything In Between

Code Is Just Text

A Brief History of Language Execution

The Foundations - 1950s

1952 - A-0 System

1958 - FORTRAN (FORmular TRANslator)

1958 - LISP

The Divergence - 1960s-70s

Compiled Languages: COBOL, FORTRAN, C

Interpreted Languages: BASIC, early Smalltalk

An Optimized Interpretation: The Bytecode Virtual Machine - 1980s

Just-In-Time Execution (JIT) - 1990s

JIT Changed Everything

Execution Models Compared

Pure Interpretation

How it works:

Characteristics:

Why it's slow:

Bytecode Interpretation

How it works:

Types of Bytecode Interpreters

Characteristics:

Why it's faster than pure source interpretation:

Why it's still slow:

Study Recommendation For Building Interpreters

Ahead-Of-Time (AOT) Compilation

Characteristics:

Why it's fast:

Limitations:

Just-In-Time Compilation

How it works:

Characteristics:

Why it can match AOT in some scenarios:

Key Distinctions Between AOT and JIT Compilation

The fundamental tradeoff:

Summary

Further Reading