Activate OPcache in the restarted process and fork workers under it

ForkParallelChecker now blocks fork only on JIT. Concurrent population
of plain OPcache's shared memory from forked children is php-fpm's
normal operating model (writes go through the allocator lock, readers
are lock-free), and the mid-request fork cannot hold that lock or ever
execute a cache restart — only JIT's shared code buffer is fork-unsafe.

TurboProcessRestarter piggybacks -d opcache.enable=1 + enable_cli=1
onto the exec it pays for anyway: optimized opcodes, the inheritance
cache, and forked workers inheriting the parent's warm SHM instead of
each compiling lazily-loaded classes for itself.

JIT is pinned off via both opcache.jit=disable and jit_buffer_size=0 —
one directive alone leaks on one generation of defaults (<= 8.3
defaults jit=tracing, so an ini with a web-tuned buffer size would JIT;
>= 8.4 defaults the buffer to 64M, so an ini setting just opcache.jit
would). It is stripped even when the ini enables it deliberately — a
measured slowdown for PHPStan that would also force spawned workers —
the same treatment the xdebug-handler restart gives xdebug. When
OPcache is not loaded (possible only on <= 8.4; since 8.5 it is always
built in) nothing is added: -d zend_extension= would only emit startup
warnings.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ek2A83bWb3Yf4CRmtvBfi4

Author: ondrejmirtes

src/Parallel/ForkParallelChecker.php

@@ -30,9 +30,11 @@
  *   lost by forking either: the distributed binaries only exist next to a
  *   phar, so spawned workers of a source checkout run without turbo too —
  *   an ini-loaded extension is inherited by fork like any other.
- * - OPcache + JIT off — their shared memory is not safe to populate
- *   concurrently from forked children and doing so corrupts analysis
- *   results.
+ * - JIT off — its shared code buffer is not safe to populate concurrently
+ *   from forked children. Plain OPcache is fine: concurrent population of
+ *   its SHM under the allocator lock is php-fpm's normal operating model,
+ *   and TurboProcessRestarter deliberately activates it for the restarted
+ *   process (with JIT pinned off).
  *
  * A forked worker ends with the extension's _exit() instead of PHP's full
  * teardown (see ForkedChildTerminator): the child inherits every loaded

src/Turbo/TurboProcessRestarter.php

@@ -26,6 +26,10 @@
  * running from a phar) the phar-fork-guard that keeps phar:// reads safe
  * across fork.
  *
+ * The restarted process also gets OPcache activated — with JIT pinned off,
+ * whatever the user's ini says — so forked workers share the parent's warm
+ * opcode cache (see getOpcacheArgs()).
+ *
  * The restart carries a marker ini entry with the extension path. It doubles
  * as the retry stop (a binary that failed to load leaves the extension
  * unloaded — without the marker the restart would loop) and tells
@@ -91,6 +95,10 @@ public static function restartIfSuitable(array $argv): void
 		}
 		$args[] = '-d';
 		$args[] = 'memory_limit=' . ini_get('memory_limit');
+		foreach (self::getOpcacheArgs() as $opcacheArg) {
+			$args[] = '-d';
+			$args[] = $opcacheArg;
+		}
 		$args[] = '-d';
 		$args[] = 'extension=' . $extensionPath;
 		$args[] = '-d';
@@ -103,4 +111,48 @@ public static function restartIfSuitable(array $argv): void
 		// pcntl_exec() returns only on failure — continue without the extension
 	}
 
+	/**
+	 * OPcache directives for the restarted process, as `name=value` ini entries.
+	 *
+	 * The exec is paid for anyway, so it doubles as the chance to activate
+	 * OPcache, usually dormant on CLI (opcache.enable_cli defaults to off):
+	 * optimized opcodes and the inheritance cache speed up the whole run, and
+	 * the pcntl_fork()ed workers inherit the parent's warm shared memory
+	 * instead of each compiling lazily-loaded classes for itself. Concurrent
+	 * population of that inherited cache is safe — it is php-fpm's normal
+	 * operating model (see ForkParallelChecker).
+	 *
+	 * JIT is always pinned off, even when the user's ini enables it — it is a
+	 * measured slowdown for PHPStan's workload and its shared code buffer is
+	 * not fork-safe, so honoring it would cost twice (the same treatment the
+	 * xdebug-handler restart gives xdebug). Merely flipping
+	 * opcache.enable_cli=1 could also activate it behind the user's back: on
+	 * PHP <= 8.3 opcache.jit defaults to `tracing`, so an ini setting just a
+	 * non-zero opcache.jit_buffer_size (common web-tuning advice) suddenly
+	 * JITs; on PHP >= 8.4 the buffer defaults to 64M, so an ini setting just
+	 * opcache.jit does
+	 * (https://php.watch/versions/8.4/opcache-jit-ini-default-changes).
+	 * Pinning both directives covers both generations of defaults.
+	 *
+	 * The only case adding nothing is OPcache not being loaded at all — real
+	 * on PHP <= 8.4, gone on 8.5+ (always built in and loaded). Loading it
+	 * from here is not worth it: -d zend_extension=opcache emits a startup
+	 * warning on builds without the shared object, and on 8.5+ always.
+	 *
+	 * @return list<string>
+	 */
+	private static function getOpcacheArgs(): array
+	{
+		if (!extension_loaded('Zend OPcache')) {
+			return [];
+		}
+
+		return [
+			'opcache.enable=1',
+			'opcache.enable_cli=1',
+			'opcache.jit=disable',
+			'opcache.jit_buffer_size=0',
+		];
+	}
+
 }