Le 01/10/2020 à 18:32, Levi Morrison via internals a écrit : > Note that for PHP 8.0 we made the system ID change even more than it > used to because doing so fixes sigsegvs when switching what extensions > are loaded (common when trialing an APM product, or loading and > unloading xdebug) when file cache is used. This means that it is even > more important to have sources than in the past, and necessarily so > because of real segmentation faults. > > So I second Nikita's opinion: this is not going to work well without > stabilizing the opcode format. This may be possible, but it would be a > lot of work; it's not happening soon. If you do it anyway be prepared > for plenty of crash complaints. > Hello,
I know this may sound naive, but would it be a bad idea to stabilize opcodes (which probably is much harder than it looks), having the VM being built following a thorough specification ? I could open the door to many things, such as third party compilers or optimizers ? I don't know much Zend VM internals, but having the possibility to have PHP binaries other than phar sound compelling to me, I wish I could deliver upgrades using a single binary instead of a 100k PHP files delivery, especially in docker environments. It may also open the door to autoload-less execution, link time-like optimizations, and even open a slight door toward reflection around modules/packages ? Regards, Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
