Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127493
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 28 May 2025 09:30:18 +0200
To: Levi Morrison <levim@php.net>
Cc: php internals <internals@lists.php.net>, Ilija Tovilo
 <tovilo.ilija@gmail.com>, Arnaud Le Blanc <arnaud.lb@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Make OPcache a non-optional part of PHP
In-Reply-To: <CAFMT4Np48UUb6B7AF8tJW4FZOGFQ=HOYJ5L9Ys4W7eF8GzE66Q@mail.gmail.com>
References: <7bdbd839b20d233e26e7901ae093ce1b@bastelstu.be>
 <CAFMT4Np48UUb6B7AF8tJW4FZOGFQ=HOYJ5L9Ys4W7eF8GzE66Q@mail.gmail.com>
Message-ID: <5155aaaaee5dcb91b6eac20db9ea8275@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

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.