[RFC] Make OPcache a non-optional part of PHP

Am 27.05.2025 um 18:47 schrieb Ben Ramsey:

A warning on startup: PHP Warning: Failed loading Zend extension 'opcache.so' (tried: ...)

On Tue, May 27, 2025 at 6:48 PM Ben Ramsey <ramsey@php.net> wrote:

For people installing PHP from .deb or .rpm sources this shouldn't be an issue either way as the package managers would take care of that (no more opcache extension, no opcache.ini). For the rest, and to avoid a lot of startup warnings we could consider to explicitly ignore loading of a zend_extension=opcache? Technically this should be easy but the question is if this is sensible. People *could* have an custom extension named opcache.so that does something else, but that feels very unlikely. Otherwise, massive fan of the RFC. Having opcache as a given (even if deactivated) will make it a lot easier to get people to use it and reduce friction. Kind Regards, Volker

Am 27.05.2025 um 20:07 schrieb Levi Morrison:

Part of this is, at least to me, that "turning off" OpCache is not a binary things: bytecode caching on/off, bytecode optimization on/off, JIT on/off, ...

Hi Am 2025-05-27 20:07, schrieb Levi Morrison:

Sebastian's response is quite accurate. While it is true that it will still be necessary to test the different code-paths, there is no single thing “OPcache”. It is rather a collection of assorted features that need to integrate into the engine by hooking into a small number of hooks (replacing some function pointers). By allowing a tighter integration with the engine, the OPcache-specific logic can be guarded by simple `if (caching_enabled)` or `if (optimizer_enabled)` statements, allowing a more direct data flow by means of local variables instead of being restricted to some kind of “middleware-style” wrapping of the original logic, possibly duplicating some of it by copy and paste. By having the entire logic in a single place it also becomes easier to see if it would be necessary to make some changes to the caching when modifying the compilation, this is also true for a code reviewer might be able to point out logic mistakes more easily. And of course in the future some of the `if()` statements might also be removed entirely when it turns out that the logic guarded by them does not have any drawbacks or the default values of INI settings can be updated. Long story short: By integrating OPcache directly into the engine, we can only gain some maintenance flexibility. In the worst case, we are in no worse situation than currently and it can only get better from there. And of course there's also the benefits to the users of PHP, since less configuration will be required for a production set-up. If OPcache is always loaded, it means that it will also be enabled by default for FPM set-ups, since `opcache.enable` defaults to `1`. Best regards Tim Düsterhus PS: Did you know that OPcache can optionally replace (opcache.enable_file_override) the implementation for the `file_exists()` function, amongst others? I did not until recently.