@dstogov do you remember what kind troubles it caused? Was it related to code size, memory usage, or something else? Note that the RFC forces opcache to be built and linked into the binary, but it doesn't set opcache.enable.

@dstogov do you remember what kind troubles it caused? Was it related to code size, memory usage, or something else? Note that the RFC forces opcache to be built and linked into the binary, but it doesn't set opcache.enable.

No. I wrote - "this may add troubles". In the best case this will just waste ~1MB of RAM.

🥳

hi @arnaud-lb
I compiled PHP 8.5 ff810d5 on Win MSVC vs17 x64 avx2 on tested with my actual php.ini

[opcache]
zend_extension=php_opcache.dll

⚠️ It produces an error

>php -v
Warning: Module "Zend OPcache" is already loaded in Unknown on line 0
Warning: Zend OPcache: module registration failed! in Unknown on line 0

🔴 and a segfault

Unhandled exception at 0x00007FFAECF70E60 in php.exe_250728_083323.dmp: 0xC0000005: Access violation executing location 0x00007FFAECF70E60.
[Inline Frame] php8ts.dll!ts_free_resources(_tsrm_tls_entry *) Line 170
	at C:\sdk\src\php-sdk\phpmaster\vs17\x64\php-src\TSRM\TSRM.c(170)
php8ts.dll!tsrm_shutdown() Line 204
	at C:\sdk\src\php-sdk\phpmaster\vs17\x64\php-src\TSRM\TSRM.c(204)
php.exe!main(int argc=2, char * * argv=0x000001fb2aebc3a0) Line 1386
	at C:\sdk\src\php-sdk\phpmaster\vs17\x64\php-src\sapi\cli\php_cli.c(1386)
[Inline Frame] php.exe!invoke_main() Line 78
	at D:\a\_work1円\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(288)
php.exe!__scrt_common_main_seh() Line 288
	at D:\a\_work1円\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(288)

Just removing zend_extension=php_opcache.dll entry fix the crash

@nono303 thank you for testing. php_opcache.dll comes from a previous build, right? This outcome is expected: As the extension is built-in and already loaded, loading a dll containing conflicting symbols will likely cause corruptions and crashes. Removing zend_extension=php_opcache.dll is the right thing to do.

php_opcache.dll comes from a previous build, right?

Ah ben oui...

Removing zend_extension=php_opcache.dll is the right thing to do.

Of course & sorry for my previous comment @arnaud-lb

Oh wow, this PR just made my day, this is going to save me so much work 🎉 🎉 🎉 🎉 🎉

Since the mechanism for loading builtin extensions supports PHP modules, not Zend extensions: Reversed the roles of the Zend extension and PHP module so that the PHP module loads the Zend extension.

Does that mean that we could now load zend_extensions like xdebug through extension=xdebug? I have not looked at the ini parsing code to see how extension= and zend_extension= differ, but it seems like the logical conclusion given that each zend_extension I know has a corresponding php module for its ini settings.

This is only a change in opcache itself. Opcache is both a PHP module and a Zend extension, the Zend extension used to load the PHP module. Now it's the inverse, so that when PHP initializes the builtin opcache module, it also initializes the opcache zend extension.

opcache.huge_code_pages=1 doesn't work any more.
It leads to crash during start-up in accel_move_code_to_huge_pages().
I don't remember the implementation details, but this worked because accel_move_code_to_huge_pages() wasn't in .text segment.
Fixing would require re-implementing accel_move_code_to_huge_pages() in DSO or using JIT.

@dstogov Here is my attempt at fixing opcache.huge_code_pages: #19388. Using JIT was actually tempting, but it would fix opcache.huge_code_pages only for systems with JIT, so I've tried something else.