PHP RFC: Make OPcache a non-optional part of PHP

• Version: 1.0
• Date: 2025-05-19
• Author: Tim Düsterhus (timwolla@php.net), Ilija Tovilo (tovilo.ilija@gmail.com)
• Status: Draft
• First Published at: https://wiki.php.net/rfc/make_opcache_required

Since OPcache’s integration into the Open Source PHP project with PHP 5.5, OPcache has become an essential part of PHP, running PHP in production without OPcache is generally considered a mistake and any new features are expected to be compatible with OPcache. However despite OPcache being an essential part of PHP in practice, it is technically still an optional part of PHP.

As an example, OPcache needs to explicitly be compiled and loaded when using the PHP “Docker Official Image”, making it easy for users to accidentally run without OPcache when using Docker. Furthermore OPcache being optional and just “hooking” into the engine also means that there are two entirely separate code-paths for core PHP functionality (such as loading and compiling a PHP script), which can easily result in OPcache-specific bugs (such as #17422) that are hard to detect during testing.

This RFC proposes making OPcache a non-optional part of PHP. The OPcache extension will become statically compiled into PHP, like ext/date, ext/hash, ext/pcre, ext/random, ext/standard and others.

The main goal of this RFC is simplifying maintenance of PHP by allowing a tighter integration of OPcache and the Zend Engine, avoiding the need to maintain two separate (“non-OPcache” and “OPcache”) implementations of core engine functionality. As of today, the Zend Engine already includes some functionality (namely the “Optimizer”) that only becomes active when OPcache is active. Thus the lines between the Zend Engine and OPcache are already blurry.

This RFC intentionally leaves the technical details of this tighter integration to informal decisions of the core developers, as with any other internal refactoring that is already happening all the time. Specifically core developers may move functionality around between Zend Engine and OPcache as necessary for maintenance. As always, the changes need to follow the regular backwards compatibility promises of PHP.

OPcache being a non-optional part of PHP and always being loaded does not mean that OPcache functionality is always active. This RFC specifically does not propose the removal of the existing INI settings, such as opcache.enable or opcache.enable_cli. A tighter integration of the Zend Engine and OPcache however might imply that checking the INI settings could be a simple if() statement in the Zend Engine, rather than an entirely separate OPcache-specific code path, where OPcache needs to hook into a coarse-grained hook provided by the Zend Engine. Furthermore OPcache always being available means that the Optimizer is always available, possibly allowing core developers to remove redundant logic to emit optimized OPcodes from the engine when the Optimizer is able to perform the same optimizations, simplifying the engine and keeping complex optimizations localized to the Optimizer. Additional INI settings may be added to enable OPcache features on a more granular basis (e.g. allowing to enable the Optimizer without also enabling the actual (useless) caching when using the CLI).

Users will no longer be able to use PHP without OPcache loaded. This is the entire point of the proposal and thus the justification is given above. The --disable-opcache flag for the ./configure script will be removed and zend_extension=opcache will need to be removed from a user’s php.ini configuration.

Next PHP 8.x (8.5).

OPcache contains a SAPI-allowlist to “disable” OPcache on unsupported APIs at runtime. This RFC only proposes that OPcache becomes a non-optional part (i.e. making it always loaded). It does not propose any changes to the runtime-checks, such as INI settings or the SAPI-allowlist.

Extensions can rely on OPcache always being loaded. As part of the continuous refactoring of PHP, the internal API of OPcache might change to allow for a tighter integration with the engine. This RFC leaves it to the core developers to decide whether or not these changes require another RFC or not.

OPcache will become a non-optional extension. A long-term goal of this RFC is making the “OPcache” section of the “RFC impact” section irrelevant for future RFCs, because OPcache becomes an integral component of the engine rather than just hooking into it.

None.

None.

None.

Only OPcache is affected.

This RFC only decides whether or not making OPcache non-optional is desired as a policy. How exactly that is going to be implemented and possible follow-up refactoring for a tighter integration with the engine is left to the PHP core developers.

n/a

After the project is implemented, this section should contain

1. the version(s) it was merged into
2. a link to the git commit(s)
3. a link to the PHP manual entry for the feature
4. a link to the language specification section (if any)

• Opcache optimization without any caching: The RFC proposed an INI setting to enable the Optimizer without also enabling the OPcode caching. A majority of voters indicated that they would be interested in making the Optimizer a core part of PHP and indicated this as the reason to reject the RFC.
• https://en.wikipedia.org/wiki/List_of_PHP_accelerators: OPcache is the only remaining maintained “PHP accelerator” (Wikipedia indicates WinCache is maintained, but it does not support PHP 8.x), which is not surprising given its existing tight integration in PHP’s development process.

None.