For example, Java,.NET, etc., I mean that opcode compiled files can be bound to
fixed versions without considering the compatibility of different versions.
The current opcode file load in Opcache is as follows:
[request]---->[find OP cache]----->[load OP]---->[verify OP]---->[exec OP]
Patch changed to:
[request]---+--->[is-OP-file]-------->[load-the-file-to-OP]------------->
[verify-OP]---->[exec-OP]
|--->[not-OP-file---->[find-OP-cache]------>[load-OP]------> /
This prejudgement process can be closed with the php.ini configuration item
without affecting the existing system
So it's not divorced from the idea of Opcode as cached data.
If a different version of opcode is executed, the patch reports an E_STRICT
error.
________________________________
发件人: Rowan Tommins <rowan.coll...@gmail.com>
发送时间: 2020年10月2日 2:46
收件人: PHP internals <internals@lists.php.net>
主题: [PHP-DEV] RFC: execution opcode file without php source code file
On 01/10/2020 15:23, 肖 鑫鑫 wrote:
> 1. Opcode binaries can be published when binding to a PHP interpreter
> (version dependent) release product, rather than just the PHP source
> code(for example, JAVA and .NET is version-dependent)
Just to clarify the comparison with other languages:
- Both the .Net CLR and the JVM are designed to be backwards compatible,
so that an assembly / class compiled for version 1 should run without
re-compilation on version 2 (but not the other way around)
- Until recently, the .Net CLR was a very stable target, which had gone
through only 4 versions in nearly 20 years (confusingly numbered 1.0,
1.1, 2.0, and 4.0)
- The JVM is specified independently of the Java language, and has
multiple interoperable implementations
This is very different from PHP OpCodes, which are not documented
outside the engine's source, and have no provision for backwards
compatibility. Not only are they likely to change between annual
releases (e.g. 7.3 to 7.4) but a change in 7.4.23 could conceivably
change the VM in such a way that code compiled on 7.4.22 would no longer
run correctly.
The Python .pyc (and .pyo, which is just a .pyc created with
optimisation turned on) is a better comparison - like PHP, it is an
implementation-dependent bytecode, although it appears there is some
guarantee of stability between bugfix releases. Its primary use seems to
be accelerating runtime on a single machine, not distributing a binary
elsewhere, and OpCache already provides that for PHP.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
