[RFC] RFC Discussion - CLI-Only Development Mode and AOT Compilation Architecture

Hi

Am 2025-06-16 09:05, schrieb wheakerd:

To make PHP compilable in AOT mode, certain dynamic features must be
restricted or restructured. The following are required:

[…]

b. Unified Standard Library

• Procedural global functions (e.g., strlen, array_merge) are
  consolidated into base classes (e.g., Str::len(), Arr::merge()).

Why would that be required?

I would like to clarify that I am currently not in a position to
implement
this proposal independently, as it would involve deep modifications to
the
PHP runtime, compiler pipeline design, or extension interfaces.

This RFC is submitted with the intention of initiating structured
discussion and community exploration around this long-term direction. I
am
willing to contribute research, coordination, and specification work if
there is interest from core contributors.

I greatly appreciate any feedback, suggestions, or interest in
collaborating on prototyping or feasibility assessment.

I believe you are greatly underestimating the effort that would need to
go into this proposal. Generally speaking from experience a proposal
where the author does not have the knowledge / capability to do the
implementation - or at least a clear implementation plan - will go
nowhere. See also: Generics.

Best regards
Tim Düsterhus

Dear PHP Internals,

I am submitting this proposal for discussion regarding a potential
future direction for PHP: moving toward a CLI-only development model
and introducing an optional Ahead-of-Time (AOT) compilation
infrastructure.

All of this reflects a growing shift: PHP is increasingly behaving
like a static backend language, except it still runs on a dynamic
interpreter.

This proposal attempts to provide native language support and compiler
infrastructure that aligns with these modern PHP usage patterns.

This is true to an extent. Certainly there are ample places where the engine could be simplified or performance improved if we had a whole-app view at compile time. But that is a vastly different language than what we have today.

About 80% of the benefit you seek can be had today with FrankenPHP in worker mode Most code works, but it retains a persistent process. That makes all of the compiled graphs and such in-memory, which is exactly what a persistent process compiled system would give you. And ReactPHP has been around since 5.4 or something, offering a persistent process with the same benefit (and the same tradeoffs).

3. CLI-Only Development Focus

• CLI becomes the canonical platform for PHP execution and development.
• PHP-FPM and SAPI models remain available for backward compatibility
  but are not required for future application delivery.
• Built-in CLI runners or Web adapters (e.g., php serve, Swoole
  adapters) provide development/testing environments.

PHP-FPM and mod_php run 70%+ of the Internet. Deprecating them is not even remotely on the table until/unless other options like FrankenPHP become standard practice across the board, including in WordPress. Which means about 20 years, if we're optimistic and push hard on it.

===== Compatibility Note =====
This proposal is entirely opt-in and defines a strict static subset
of PHP. Dynamic runtime via Zend VM and JIT continues to be supported
and unchanged. This is an addition, not a replacement.

That doesn't jive with what you had above about dropping PHP-FPM.

===== Request for Feedback =====
I’d appreciate feedback from internals and community members on:

• Whether such a compiler pipeline is desirable and feasible.
• Acceptability of the required language subset restrictions.
• Pathways to prototype this outside core, e.g., via PHP extensions or
  userland tooling.

===== Note =====
I would like to clarify that I am currently not in a position to
implement this proposal independently, as it would involve deep
modifications to the PHP runtime, compiler pipeline design, or
extension interfaces.

This RFC is submitted with the intention of initiating structured
discussion and community exploration around this long-term direction. I
am willing to contribute research, coordination, and specification work
if there is interest from core contributors.

I greatly appreciate any feedback, suggestions, or interest in
collaborating on prototyping or feasibility assessment.

Sincerely,
[wheakerd]

As Tim said, I think you vastly under-estimate the amount of effort you describe, even ignoring the massive existing ecosystem. You're talking many years of work.

Using FrankenPHP worker mode or one of the Fibers-based frameworks (ReactPHP, AmPHP, Revolt, etc.) will give you 80% of what you're looking for or better, today. Talking about anything even more drastic is severely premature until that model achieves critical mass, and ideally becomes the most widely used SAPI. Until then, this sort of "change the world" redesign is not feasible.

--Larry Garfield

Dear PHP Internals,

I am submitting this proposal for discussion regarding a potential future direction for PHP: moving toward a CLI-only development model and introducing an optional Ahead-of-Time (AOT) compilation infrastructure.

While this may not fully align with PHP’s traditional interpreter-based design, I believe it opens up valuable opportunities to modernize PHP's runtime and improve performance, portability, and long-term maintainability.

We kinda already have this — to a degree. You can enable pre-loading and OPcache. In case you aren’t aware (I wasn’t just a year ago!) OPcache is quite advanced and does much of the same stuff a traditional compiler does: (transforms the source into an IR and can even run SSA on it — assuming I read the extension correctly, and I’m fairly confident in that).

===== Current Development Landscape =====
Contemporary PHP projects are already moving toward architecture patterns that resemble compiled systems:

• Frameworks define service containers, dependency graphs, and code generation layers.
• Static analysis tools (Psalm, PHPStan) are integral to modern development.
• Code is often bootstrapped through CLI pipelines: for build, testing, deployment, and even request simulation (php artisan, bin/console, etc.).
• Composer autoloading, annotation processors, and classmaps are precomputed.
• Web servers (e.g., Swoole, RoadRunner) are replacing FPM in performance-critical applications, with CLI processes becoming long-lived daemons.

All of this reflects a growing shift: PHP is increasingly behaving like a static backend language, except it still runs on a dynamic interpreter.

This proposal attempts to provide native language support and compiler infrastructure that aligns with these modern PHP usage patterns.

I’m unsure why you’re asserting that compiled systems only use these architectural patterns? They’re patterns and thus can be used in JavaScript, or even Lisp, if you want to. It doesn’t mean the language has to be compiled to generate code (in fact, were it a compiled language, generating code would be nigh impossible during runtime).

===== Motivation =====
PHP’s traditional runtime model (FPM or mod_php) is optimized for short-lived, script-based execution. However, this limits PHP’s potential in:

• Serverless or event-driven environments (high cold start cost).
• Embedded targets and containers with limited runtime support.
• Modular system design where PHP extensions must be written in C.
• Distributable binaries for CLI tools or desktop-style apps.

PHP developers are often forced to work around these limitations using complex workarounds (e.g., caching containers, annotation scans, custom autoloaders, preload hacks). AOT compilation and CLI-first design can solve these challenges directly, natively.

I’m sorry; you’ve lost me here.

How does "short-lived" execution fail in serverless or event-driven environments? Isn’t that the entire point? Serverless is basically a reinvention of CGI, which PHP excels at. However, the people who built these runtimes didn’t realise what they were reinventing to run long-lived applications and didn’t include PHP because "PHP is dying" for the last 20 years. This is a failure of the people who built the runtimes, not PHP’s execution model. It is a political issue, not a technical one.

I primarily work with embedded PHP, there is even an ancient book about it (which is how I first got into php-src). Embedded PHP is where it is at if you ask me. It is a great language for it, especially because there is a lot of PHP talent out there quite used to dealing with "shared nothing", "stateless", "event driven" architecture.

Then there is the fact that PHP extensions must be written in C. This is a false assertion. They may also be written in C++, or any language that can bind with C libraries (like Go, Zig, Rust, or even C#).

Also, it is false that you can’t distribute CLI tools written in PHP. There is at least one project that lets you bundle your PHP project in a statically built, self-extracting executable.

===== Proposal =====

1. Compiler Infrastructure (AOT Mode)

A new compiler pipeline would be introduced:

• Frontend: Parse PHP source into AST (reusing current infrastructure).
• IR Layer: Transform AST into intermediate representation (IR).
• Backend: Compile IR into native binary via C transpilation or LLVM backend.

2. Required Language Model Changes

To make PHP compilable in AOT mode, certain dynamic features must be restricted or restructured. The following are required:

a. Static Code & Configuration

• Dynamic constructs (e.g., eval, dynamic includes/classes/functions) are disallowed.
• Project must provide static configuration file (php.compiler.json) for classmap, entrypoint, environment constants, etc.
• No runtime-based code discovery or composition.

b. Unified Standard Library

• Procedural global functions (e.g., strlen, array_merge) are consolidated into base classes (e.g., Str::len(), Arr::merge()).
• Modules gain clearer boundaries and dependency injection support.

c. Environment Interfaces

• Superglobals ($_ENV, $_SERVER, etc.) are abstracted via interfaces or injectable system services.

d. Type System Enhancements

• Strong use of declare(strict_types=1), interfaces, final classes, and property types.
• Optional compilation-time type enforcement and inference.

e. Compiler Extension Hooks

• Developers or frameworks can hook into compilation stages (AST transformation, IR passes) to generate optimized artifacts.

3. CLI-Only Development Focus

• CLI becomes the canonical platform for PHP execution and development.
• PHP-FPM and SAPI models remain available for backward compatibility but are not required for future application delivery.
• Built-in CLI runners or Web adapters (e.g., php serve, Swoole adapters) provide development/testing environments.

===== Expected Benefits =====

• Native, standalone executables—no PHP interpreter dependency.
• Fast cold start (useful in serverless and event-driven environments).
• PHP extensions can be authored in PHP and compiled, removing the C barrier.
• Clean separation between compilation-time and runtime.
• Enables new use cases: embedded systems, WASM targets, mobile SDKs, long-lived CLI daemons.

You would still be dependent upon the PHP runtime environment. Much like the C# CLR. There is nothing stopping someone from working on OPcache to its natural conclusion and getting the machine code out of it, into a file that can run directly. However, you’re still going to want to run your old code, which most likely calls "exec" somewhere (to compile a twig template), or uses autoloading shenanigans to mock out code, or DI systems that generate new code on demand when you make changes.

===== Compatibility Note =====
This proposal is entirely opt-in and defines a strict static subset of PHP. Dynamic runtime via Zend VM and JIT continues to be supported and unchanged. This is an addition, not a replacement.

===== Request for Feedback =====
I’d appreciate feedback from internals and community members on:

• Whether such a compiler pipeline is desirable and feasible.
• Acceptability of the required language subset restrictions.
• Pathways to prototype this outside core, e.g., via PHP extensions or userland tooling.

You may be interested in kphp, which compiles a subset of PHP to machine code. It is still actively developed and maintained. It is a pretty interesting project and has stood the test of time.

===== Note =====
I would like to clarify that I am currently not in a position to implement this proposal independently, as it would involve deep modifications to the PHP runtime, compiler pipeline design, or extension interfaces.

This RFC is submitted with the intention of initiating structured discussion and community exploration around this long-term direction. I am willing to contribute research, coordination, and specification work if there is interest from core contributors.

I greatly appreciate any feedback, suggestions, or interest in collaborating on prototyping or feasibility assessment.

Sincerely,
[wheakerd]

— Rob