Enable opcache by default

[TimWolla]

OPcache is an essential part of modern PHP and will always be included in PHP starting with 8.5 (https://wiki.php.net/rfc/make_opcache_required). Enable OPcache by default in Docker to simplify the set-up.

---

I've verified that running docker-php-ext-install opcache and docker-php-ext-enable opcache in a custom Docker image based on the PHP image will not cause issues.

[tianon]

Can you elaborate on this (seemingly unrelated) change? The .so vs not-.so is already handled in docker-php-ext-enable unless I've missed something.

[TimWolla]

Without this change, this would call docker-php-ext-enable opcache.so. If the INI already has zend_extension=opcache then for the docker-php-ext-enable opcache.so call neither this:

php/docker-php-ext-enable

Lines 96 to 103 in 85abdb7

	if php -d 'display_errors=stderr' -r 'exit(extension_loaded("'"$ext"'") ? 0 : 1);'; then
	# this isn't perfect, but it's better than nothing
	# (for example, 'opcache.so' presents inside PHP as 'Zend OPcache', not 'opcache')
	echo >&2
	echo >&2 "warning: $ext ($module) is already loaded!"
	echo >&2
	continue
	fi

nor this:

php/docker-php-ext-enable

Line 114 in 85abdb7

if ! grep -qFx -e "$line" -e "$line.so" "$ini" 2>/dev/null; then

check trigger and as a result the the INI will be updated to:

zend_extension=opcache
zend_extension=opcache.so

[tianon]

My personal experience with opcache has been primarily negative, so this certainly causes me some pause, but that experience is admittedly really outdated now and this is probably sane (especially as it'll be the effective state in 8.5).

[tianon]

Gah, if without else isn't supported until jq 1.7 (https://github.com/jqlang/jq/releases/tag/jq-1.7), which we don't have on our primary infra (Debian-based, thus still jq 1.6). I've fixed it in a follow-up commit, but that's something we'll need to be aware of and watching for now (or will have to update CI across all our repos to deal with somehow). 😞

(If only GHA let us provide our own VM images without having to manage the VMs ourselves too 😭)

[AlexWinder]

Since this has been updated we've found that we need to disable OpCache within our Dockerfile to avoid some addition/division failures:

• Float addition/division issues #1588
• Float addition/division issues php/php-src#18947

[Girgias]

Since this has been updated we've found that we need to disable OpCache within our Dockerfile to avoid some addition/division failures:

* [Float addition/division issues #1588](https://github.com/docker-library/php/issues/1588)

* [Float addition/division issues php/php-src#18947](https://github.com/php/php-src/issues/18947)

As said on the php-src report, I doubt this is a general opcache issue but a JIT issue.

[tianon]

As noted in #1589 (comment), I think #1589 (comment) makes me think we probably merged this a bit prematurely (we should've waited until it was at least merged/enabled in upstream's development branch), but it is what it is at this point and we're probably better off just riding it through now to avoid too much churn (just recording this here for posterity / to make it easier to find).

[TimWolla]

@tianon Yeah, I had seen the comment over in the other PR and agree that the process was not ideal. Given that the RFC already had a working PoC implementation, I had anticipated it being merged more quickly.

It will probably happen for Alpha 3, php/php-src#18939 - the main part of the implementation is now already reviewed, but due to a vacation it will likely be merged after Alpha 2.

[TimWolla]

Now merged for Alpha 3 (to be released on Thursday): php/php-src@7b4c14d

[robincee]

Flame off / helicopter view on

I do love the times when -rc variants are added - and the noise increases (also due to strategy that is guarded / changelog / occational blog post / etc)

I've been using opcache with d-l/php for years without problems. I do object to the change in this way, because it should only impact the 'Target Version: PHP 8.5' as stated on the php.net site. I expected a check for 8.5 (-rc) (and maintainers that guard that), but now all prior versions are also affected, including my build infra that builds 32 images on top of d-l/php (have been doing that for years, faced similar issues before).

Expectations: As soon as i saw the 8.5-rc variant - i knew - here we go again - and here we are. Issues like this are a magnet for noise / undesired changes, have been for some time. To prevent similar situations, limit changes to the new major, set up some change log where you can point people to, etc. Then we all know what to expect in the -rc that will become the next new major even before it is released - and prep our setups accordingly.

I had some fun with these issues, we have a strict naming policy for .ini files and we store a list of installed extensions d-l/php provides + a count before our docker setup runs docker build and adds more extensions, so we spotted this change right away, while it did break (we do not allow loading .ini files that do not respect our naming policy, yes a lil over the top, but it sure work great), it was quickly identified and remedied. The Float addition/division issue is obviously related (but might expose a bug in user code), we compile opcache and xdebug on top of FPM, disable opcache for local development by default, can't remember any issues like this since 2018. The lacking default config is the real problem i guess (with enable and enable_cli set to 0 - by default, then people would have been able to change them if they need opcache - and the rest would have been unaffected). These images we build are mostly for Symfony/Laravel and similar, so opcache is included by default with our setup (but disabled on dev images). If something like this is premature: well, i got a git log to show you. :) (while i do agree that this still needs some work)

I would not roll this back, just add the default config with opcache disabled will do, or rollback < 8.5 - up to you folks (Or document that you can mount an empty file to /usr/local/etc/php/conf.d/docker-php-ext-opcache.ini to prevent opcache from loading at all). But i expect the enable opcache by default will bite some folks once 8.5 is released anyway.

Lots to learn / to do i guess, see you on the next one! Thanks for the hard work all. /helicopter down

ps. some ideas on the floating points issue with opcache enabled: read everything related to IEEE 754, check == vs ===, roundings, etc. And what the php-folks said, check JIT config/changes. And if everything fails: look up opcache.blacklist_filename or brute force opcache_invalidate(FILE, true); so you can ID the real problem/file. (it has to be something)