# [RFC] Make OPcache a non-optional part of PHP - Thread: https://externals.io/message/127459 - Original archive: https://news-web.php.net/php.internals/127459 - Started by tim@bastelstu.be on 2025-05-26T10:47:00+00:00 - Messages: 11 - RFC: Make OPcache a non-optional part of PHP (Implemented (PHP 8.5)) — https://externals.io/rfc/make_opcache_required.md - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #127459 — tim@bastelstu.be — 2025-05-26T10:47:00+00:00 URL: https://externals.io/message/127459#127459 Hi Arnaud, Ilija and I would like to propose making OPcache a non-optional part of PHP starting with PHP 8.5. Please find the RFC including more details at: https://wiki.php.net/rfc/make_opcache_required As of now OPcache cannot be statically compiled into the PHP binary at all, which is the direct opposite from what we are proposing. This is due to an incompatibility between JIT and ZTS builds. Arnaud has prepared a proof-of-concept implementation fixing this issue at: https://github.com/php/php-src/pull/18660. The changes in that PR would also allow building static PHP binaries with OPcache enabled in the first place (e.g. for use with FrankenPHP). Best regards Tim Düsterhus --- ## #127462 — Michael Maroszek — 2025-05-26T14:49:52+00:00 URL: https://externals.io/message/127459#127462 · In reply to: #127459 I really like the idea. We use the Embed SAPI statically linked and at the moment we need to take great care to bundle the OPcache extension. This will make it a lot easier for us. A big +1 from my point of view! Regards, Michael Tim Düsterhus schrieb am Mo. 26. Mai 2025 um 12:49: > Hi > > Arnaud, Ilija and I would like to propose making OPcache a non-optional > part of PHP starting with PHP 8.5. > > Please find the RFC including more details at: > https://wiki.php.net/rfc/make_opcache_required > > As of now OPcache cannot be statically compiled into the PHP binary at > all, which is the direct opposite from what we are proposing. This is > due to an incompatibility between JIT and ZTS builds. Arnaud has > prepared a proof-of-concept implementation fixing this issue at: > https://github.com/php/php-src/pull/18660. The changes in that PR would > also allow building static PHP binaries with OPcache enabled in the > first place (e.g. for use with FrankenPHP). > > Best regards > Tim Düsterhus --- ## #127472 — Larry Garfield — 2025-05-27T00:04:38+00:00 URL: https://externals.io/message/127459#127472 · In reply to: #127459 > Hi > > Arnaud, Ilija and I would like to propose making OPcache a non-optional > part of PHP starting with PHP 8.5. > > Please find the RFC including more details at: > https://wiki.php.net/rfc/make_opcache_required > > As of now OPcache cannot be statically compiled into the PHP binary at > all, which is the direct opposite from what we are proposing. This is > due to an incompatibility between JIT and ZTS builds. Arnaud has > prepared a proof-of-concept implementation fixing this issue at: > https://github.com/php/php-src/pull/18660. The changes in that PR would > also allow building static PHP binaries with OPcache enabled in the > first place (e.g. for use with FrankenPHP). > > Best regards > Tim Düsterhus I cannot speak to the implementation details, but I am fully on board with the intent and goal here. +1. --Larry Garfield --- ## #127481 — Ben Ramsey — 2025-05-27T16:47:25+00:00 URL: https://externals.io/message/127459#127481 · In reply to: #127459 > Hi > > Arnaud, Ilija and I would like to propose making OPcache a non-optional > part of PHP starting with PHP 8.5. > > Please find the RFC including more details at: https://wiki.php.net/rfc/ > make_opcache_required > > As of now OPcache cannot be statically compiled into the PHP binary at > all, which is the direct opposite from what we are proposing. This is > due to an incompatibility between JIT and ZTS builds. Arnaud has > prepared a proof-of-concept implementation fixing this issue at: > https://github.com/php/php-src/pull/18660. The changes in that PR would > also allow building static PHP binaries with OPcache enabled in the > first place (e.g. for use with FrankenPHP). > > Best regards > Tim Düsterhus The RFC states: > `zend_extension=opcache` will need to be removed from a user’s php.ini > configuration Is this really a *need*, or is it more of a recommendation? If it's left in a user's configuration, what is the impact? Cheers, Ben --- ## #127484 — Levi Morrison — 2025-05-27T18:07:37+00:00 URL: https://externals.io/message/127459#127484 · In reply to: #127459 > > Please find the RFC including more details at: > https://wiki.php.net/rfc/make_opcache_required Quoting from the RFC: > 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. To me, being able to turn off opcache defeats the purpose of putting it into core. In fact, take this part of the RFC's introduction: > 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. If opcache can still be disabled, and isn't enabled by default in CLI, then in practice we still have all of these issues. The engine may not have to care about "is opcache around?" but it still has to care "is opcache enabled?" Dropping the first part isn't that helpful if the second part still has to be asked. --- ## #127488 — Sebastian Bergmann — 2025-05-28T04:02:17+00:00 URL: https://externals.io/message/127459#127488 · In reply to: #127481 Am 27.05.2025 um 18:47 schrieb Ben Ramsey: > Is this really a *need*, or is it more of a recommendation? If it's left > in a user's configuration, what is the impact? A warning on startup: PHP Warning: Failed loading Zend extension 'opcache.so' (tried: ...) --- ## #127489 — Sebastian Bergmann — 2025-05-28T04:04:08+00:00 URL: https://externals.io/message/127459#127489 · In reply to: #127484 Am 27.05.2025 um 20:07 schrieb Levi Morrison: > To me, being able to turn off opcache defeats the purpose of putting it into > core. In fact, take this part of the RFC's introduction: 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, ... --- ## #127492 — tim@bastelstu.be — 2025-05-28T07:05:29+00:00 URL: https://externals.io/message/127459#127492 · In reply to: #127488 Hi Am 2025-05-28 06:02, schrieb Sebastian Bergmann: > > […] > > A warning on startup: > > PHP Warning: Failed loading Zend extension 'opcache.so' (tried: ...) Indeed. To explain further: The `opcache.so` will no longer exist, thus the behavior is as with any other non-existent extension you are trying to load. You can already try yourself with `php -dzend_extension=does-not-exist.so` Best regards Tim Düsterhus --- ## #127493 — tim@bastelstu.be — 2025-05-28T07:30:18+00:00 URL: https://externals.io/message/127459#127493 · In reply to: #127484 Hi Am 2025-05-27 20:07, schrieb Levi Morrison: > If opcache can still be disabled, and isn't enabled by default in CLI, > then > in practice we still have all of these issues. The engine may not have > to > care about "is opcache around?" but it still has to care "is opcache > enabled?" Dropping the first part isn't that helpful if the second part > still > has to be asked. 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. --- ## #127497 — Volker Dusch — 2025-05-28T14:25:57+00:00 URL: https://externals.io/message/127459#127497 · In reply to: #127481 > > […] > > Is this really a *need*, or is it more of a recommendation? If it's left > in a user's configuration, what is the impact? > 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 -- Volker Dusch Head of Engineering Tideways GmbH Königswinterer Str. 116 53227 Bonn https://tideways.io/imprint Sitz der Gesellschaft: Bonn Geschäftsführer: Benjamin Außenhofer (geb. Eberlei) Registergericht: Amtsgericht Bonn, HRB 22127 --- ## #127630 — tim@bastelstu.be — 2025-06-09T14:09:37+00:00 URL: https://externals.io/message/127459#127630 · In reply to: #127459 Hi Am 2025-05-26 12:47, schrieb Tim Düsterhus: > Arnaud, Ilija and I would like to propose making OPcache a non-optional > part of PHP starting with PHP 8.5. > > Please find the RFC including more details at: > https://wiki.php.net/rfc/make_opcache_required > Since there was not much of a discussion and the feedback we received was super positive overall, we would like to proceed with voting later this week, unless someone speaks up with major concerns :-) Best regards Tim Düsterhus