RFC: execution opcode file without php source code file


hi

This patch addresses the following issues:

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)

2. Extend compilation only online to compile anywhere. You can avoid problems caused by cold starts by publishing more code

Explanation of some questions:
This patch simply changes OpCache's process of detecting the opcode cache against the requested file, allowing it to treat the current file as an Opcode file. .
This means that files compiled using the opcache_complie_file function are still cache files that can be moved anywhere, so it is up to the developer to ensure that the compilation is consistent with the version of the interpreter that is running.
When a developer compiles with the opcache_complie_file function and enables the relevant configuration in the running container, they should be aware of these limitations and some of the functionality failures.
I will add PHP version information when writing labels, and give a hint when the runtime does not match the current version.

In addition, the Phar file does not skip the compilation of Opcache, so it also supports packaging opcode files into the Phar file

---

发件人: Nikita Popov nikita.ppv@gmail.com
发送时间: 2020年10月1日 20:30
收件人: Rowan Tommins rowan.collins@gmail.com
抄送: PHP internals internals@lists.php.net
主题: Re: [PHP-DEV] RFC: execution opcode file without php source code file

On Thu, Oct 1, 2020 at 1:44 PM Rowan Tommins rowan.collins@gmail.com
wrote:

Hi,

I commit a new request path, the request is about execution opcode file
without php source code file
this RFC provides similar to class file of java and pyo file of python.
patch is: https://github.com/php/php-src/pull/6146

I'm sure someone who knows the internals better can clarify, but my
understanding is that PHP OpCodes don't currently have any stability
guarantee, so you can't rely on a binary taken from one version will run on
another, even within a release.

In order to be useful, this will therefore need two things:

• a header in the file identifying the engine version it was compiled for,
  with an error raised on any mismatch
• a policy of how to manage that version number, and how users can know
  which versions their binary files will work on

There's probably a limit to how stable we can (or want to) make the VM, so
these files will never be as portable as a Java class file or .Net assembly.

This is correct. PHP uses the "system ID" to determine whether it is
possible to reuse compiled opcodes. This system ID is used by the existing
file cache.

The linked pull request however explicitly disables this check, which is
not safe. And with that check enabled, this feature would probably have
limited usefulness, as the cached file would be bound to a specific PHP
patch release (and to some degree to which extensions are loaded).

It would be good to know what the actual use-case for this is. If the goal
here is to distribute pre-compiled PHP code without the source code, then
this is not going to work without making the opcode format stable (which, I
think, is pretty unlikely.) If the goal is improving cold startup
performance, then I wonder what the benefit over the existing file cache is.

Regards,
Nikita