Bytecode VMs

Also Known As

TL;DR

Explanation

Bytecode VMs provide: portability (compile once, run on any OS with the VM), sandboxing (VM controls what bytecode can do), JIT optimisation opportunity (compile hot paths to native code based on runtime profiling). Zend Engine (PHP): stack-based VM, OPcache adds caching and optional JIT. JVM (Java, Kotlin, Scala): .class bytecode, HotSpot JIT with 20+ years of maturity, longer warm-up time. CLR (.NET): CIL bytecode, JIT via RyuJIT. Key difference: JVM and CLR were designed for JIT-heavy long-running servers; Zend Engine serves short-lived request processes where JIT warm-up is often not amortised.

Common Misconception

Why It Matters

Common Mistakes

• Expecting PHP JIT to match JVM HotSpot performance — different maturity levels and workload targets
• Not understanding that Zend opcodes are stack-based — variable accesses involve push/pop operations
• Thinking the VM prevents all malicious code — open_basedir and disable_functions restrict PHP capabilities
• Comparing benchmarks without controlling for workload type — I/O-bound vs CPU-bound gives completely different JIT results

Code Examples

// Expecting JVM-level JIT speedup from PHP JIT:
// PHP web app benchmark with JIT enabled:
// Without JIT: 1000 req/s
// With JIT:    1020 req/s (2% improvement — I/O bound app)
// Expected based on JVM knowledge: 2-5x improvement
// Reality: minimal for typical PHP web apps

// PHP JIT meaningful for CPU-bound long-running workers:
// Image resizing benchmark (CPU-intensive, long-running worker):
// Without JIT: 10 images/s
// With JIT (tracing mode): 14 images/s — 40% improvement

// Configure for long-running PHP workers where JIT warms up:
// php.ini:
// opcache.jit = tracing          ; Best for loops
// opcache.jit_buffer_size = 128M ; JIT compiled code cache

References

• ↗ https://wiki.php.net/rfc/jit

Tags

Related Terms