JIT Compiler (PHP 8.0)
debt(d5/e3/b3/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints list blackfire, opcache-gui, and phpbench — all specialist profiling/benchmarking tools. Misuse (enabling JIT on I/O-bound apps expecting gains) is not caught by the compiler, syntax checks, or default linters; it requires profiling tools to reveal negligible or negative impact.
Closest to 'simple parameterised fix' (e3). The quick_fix describes adjusting opcache.jit mode (e.g. switching to opcache.jit=tracing) and measuring — this is a configuration-level change, not a single-line code patch but not a multi-file refactor either. Remediation is localised to php.ini/opcache settings and possibly re-evaluating architectural caching strategy.
Closest to 'localised tax' (b3). JIT is a runtime/configuration concern (opcache settings) that applies to web and cli contexts. It doesn't reshape the codebase or impose a persistent cross-cutting tax; it sits in server configuration and primarily affects the ops/performance tuning layer rather than every future developer's day-to-day work.
Closest to 'serious trap' (t7). The misconception field states explicitly that enabling JIT 'always improves web application performance' — the canonical wrong belief. Most developers enabling PHP 8 JIT for a Laravel/Symfony app will expect a speedup and see none (or slight regression). This contradicts the intuitive mental model from JIT in other runtimes (JVM, V8) where JIT more broadly accelerates general workloads, making it a serious expectation mismatch.
Also Known As
TL;DR
Explanation
PHP 8.0 introduced a JIT compiler built on top of OPcache. It operates in two modes: tracing JIT (monitors execution and compiles frequently-run code paths) and function JIT (compiles whole functions). For typical web applications — primarily I/O-bound (database, network) — JIT provides little benefit. It shines in CPU-intensive work: image processing, mathematical computation, parsing, and ML inference. Enable with opcache.jit_buffer_size=100M and opcache.jit=tracing. JIT can interfere with some debugging tools; disable in development when using Xdebug.
Watch Out
Common Misconception
Why It Matters
Common Mistakes
- Expecting JIT to speed up typical CRUD web applications — they are I/O bound; JIT benefits are minimal.
- Not enabling opcache first — JIT requires opcache.enable=1 and builds on top of it.
- Using opcache.jit=1255 (default) without benchmarking — the optimal JIT mode depends on your workload.
- Assuming JIT eliminates the need for query optimisation and caching — it does not.
Code Examples
# php.ini — JIT not configured despite PHP 8:
opcache.enable=1
; opcache.jit missing — JIT disabled by default
; opcache.jit_buffer_size missing — required for JIT to function
# Correct:
opcache.jit=1255
opcache.jit_buffer_size=128M
; php.ini — JIT configuration (PHP 8.0+)
opcache.enable = 1
opcache.jit_buffer_size = 128M
opcache.jit = tracing ; best for most workloads
; Options: 0=off | 1205=function JIT | 1254=tracing JIT
; Verify JIT is active:
$ php -r "\$s = opcache_get_status(); var_dump(\$s['jit']['enabled']);"
; JIT helps most with:
; - CPU-intensive work (image processing, maths, data crunching)
; - Not typical web I/O (DB queries dominate — JIT won't help there)
; Benchmark your specific workload — gains vary significantly