Inside the Zend VM: From Opcodes and OPcache to the PHP 8 JIT Compiler (Part 3)

A pervasive misconception regarding PHP is the belief that it evaluates .php source files line-by-line as an interpreted scripting language on every incoming HTTP request.

In production engineering, PHP 8.x operates on a register-based virtual machine: the Zend Engine. Source code undergoes formal tokenization, abstract syntax tree compilation, and bytecode (opcode) generation, before being executed by the virtual machine or compiled directly into native machine instructions via its Just-In-Time (JIT) compiler.

In this third installment of our backend architecture series, we examine the inner mechanics of the Zend VM and demystify the practical impact of the JIT in real-world systems.

---

1. The Zend Engine Compilation Pipeline

When the PHP runtime accepts a script for execution, the code traverses four stages:

[Source Code .php]
        │
        ▼ 1. Lexing & Tokenization
[Language Tokens]
        │
        ▼ 2. Abstract Syntax Tree (AST)
[Hierarchical AST]
        │
        ▼ 3. Bytecode Generation
[Opcodes Array (Zend VM)] ──► Cached in [ OPcache (RAM) ]
        │
        ▼ 4. Virtual Machine Execution
[Zend VM Executor] ──(If JIT active)──► [Native Machine Code x86_64/ARM64]

1. Lexing and Tokenization:

The lexer converts raw script strings into discrete lexical tokens (T_OPEN_TAG, T_VARIABLE, T_STRING, T_IF).

2. AST Generation:

Introduced in PHP 7.0, the compiler converts tokens into a hierarchical Abstract Syntax Tree. Decoupling source syntax from instruction generation enables sophisticated intermediate static analysis and compiler optimizations.

3. Opcode Emission:

The compiler walks the AST and emits a linear array of Opcodes (zend_op_array). Each opcode is an elemental instruction processed by the Zend VM:

• ZEND_FETCH_DIM_R: Array index lookups.
• ZEND_ADD: Arithmetic additions of operands.
• ZEND_INIT_FCALL: Preparing a function invocation stack frame.

---

2. OPcache: Eliminating the Compilation Overhead

In a legacy runtime lacking bytecode caching, steps 1 through 3 occurred on every single HTTP request. In an enterprise codebase loading 1,500 classes, re-parsing files in every request burned up to 80% of CPU time on redundant parsing.

OPcache resolves this by persisting pre-compiled opcode arrays within a Shared Memory Segment (SHM).

Request 1: Reads Disk ──► Compiles AST ──► Stores Opcodes in RAM ──► Executes
Request 2..N: [ OPcache HIT ] ──────────────────────────────────► Executes in RAM

Critical Tuning Parameters for High-Throughput Servers:

In production, the following directives in php.ini dictate operational efficiency:

; Total shared RAM allocated for compiled opcodes and scripts
opcache.memory_consumption=256

; Upper ceiling for cached file keys (must exceed total project file count)
opcache.max_accelerated_files=20000

; In production, NEVER check if files changed on disk (eliminates stat system calls)
opcache.validate_timestamps=0

; Store strings and literals in immutable shared memory
opcache.interned_strings_buffer=16

With opcache.validate_timestamps=0, worker processes completely bypass filesystem checks. The OPcache hit ratio reaches 99.9%, allowing PHP execution to operate purely out of high-speed system RAM.

---

3. Preloading (PHP 7.4+): Permanent In-Memory Framework Bootstrapping

Despite OPcache, traditional PHP-FPM workers still required linking cached class opcodes into the process’s local symbol table during bootstrapping.

Preloading eliminates this final step: it runs an explicit bootstrap script once during daemon or container initialization:

// preload.php
$coreFiles = [
    // Precompiles and permanently registers Laravel/Symfony core symbols
];
foreach ($coreFiles as $path) {
    opcache_compile_file($path);
}

Preloaded classes, interfaces, and functions remain permanently and immutably accessible across all worker processes, lowering overall memory footprint by 20% and trimming baseline request latency.

---

4. The PHP 8 JIT Compiler: Mechanics vs. Realities

With PHP 8.0, Dmitry Stogov led the implementation of an integrated Just-In-Time (JIT) Compiler using DynASM.

How the JIT Operates:

While the Zend VM interprets opcodes through an optimized C switch-dispatch loop, the JIT translates hot opcode sequences directly into native processor instructions (x86_64 or ARM64):

[Opcode: ZEND_ADD] ──(JIT Compiler)──► [Native Assembly: addq %rax, %rbx]

PHP’s JIT supports two distinct modes:

1. Function JIT: Compiles entire function bodies ahead of invocation.
2. Tracing JIT: Profiles execution loops at runtime to identify hotspot execution traces, compiling only the highest-frequency loops into machine code.

The Myth of JIT in Web Applications:

When PHP 8 launched, many developers assumed that activating the JIT would automatically speed up standard Laravel or Symfony REST APIs by 5x.

In rigorous production benchmarks, web APIs typically experience a modest 2% to 5% latency improvement. Why?

• Amdahl’s Law: Modern web APIs are predominantly I/O-Bound: processing latency is governed by database queries (PostgreSQL/MySQL), network hops to Redis, or external third-party API latency.
• The Zend VM with OPcache is already tuned for invoking internal C-level routines (pdo, json_decode, mbstring).

Where the JIT Genuinely Excels:

The JIT unlocks transformative gains (3x to 10x throughput increases) for CPU-Bound workloads:

• Mathematical simulation and fractal rendering algorithms.
• Large-scale AST parsers, linters, and code transformers (such as PHPStan and Psalm).
• Pure PHP cryptographic functions and data compression algorithms.
• Userland neural network inference and machine learning implementations.

---

Summary & Next Up

Understanding the boundary between Zend bytecode, OPcache shared memory segments, and native machine instructions brings clarity to PHP’s true performance characteristics. When configured with preloading and optimized memory allocations, PHP operates at competitive execution latencies.

In our Part 4 (Final) installment, we explore enterprise reality: why tech leaders like Slack, Meta, and Wikipedia continue to rely on PHP at scale, how strict typing and PHPStan Max eliminate runtime type errors, and how native Fibers usher in cooperative async concurrency.