PHP RFC: Direct execution opcode file without php source code file


The current OPCache cannot get rid of the source file to execute the opcode file. The path will allow OPCache direct execution opcode file without php source code file.

This function is similar to java, python, .net etc. performing bytecode functions. However, the existing execution and operation mechanism of PHP is not changed.


Copy use opcache_compile_file() function complie result file to special path. then prepend flag (<?phpo) and php_version_id to copy of file.

When executing, judge whether the loaded PHP file is an opcode file based on the flag. if no flag, will run as it is now.If is opcode file will direct execution without check php source file.

The includes() includes_once() and require() require_one() can load opcode file. So if you include opcode files, the source code must use the compiled file path instead of the source file path.

Change function to:

opcache_compile_file(string $file, string $opcode_file = null): bool

Implement a schematic flowchart

The PHP source code file is compiled into an opcode file flowchart:

1. current process:

[php-load-source] ---> [compile to opcode] --->  [store to cache system directory]

2. path change to process:

[php-load-source] ---> [compile to opcode] ---> [save to cache system directory] ---> [copy cache file to the specified path]

3. When specified path, the opcode file format change to like below:

<?phpo{phpversionid}OPCACHE575d367cc725713f6f170910d6e9ee5e-------BINARY CONTENT OF OPCODE----

The above code explains:

  1. <?phpo: is opcode file flag. when specified compile to file prepend
  2. {phpversionid}: is current php version id. when specified compile to file prepend
  3. OPCACHE575d367cc725713f6f170910d6e9ee5e: opcode file magic info and systemid. it's not change.
  4. -------BINARY CONTENT OF OPCODE----: opcode data, it's not change

OPCache extentsion exec flowchart:

1. current opcache exec process:

[php] ---> [find cache in cache system directory] --->x---> [found] -->[exec opcode]
                                                       \---> [not found] ---> [exec php source]

2. path added process:

[php/phpo] --->x---> [is phpo] ---> [load the phpo file] ---> [exec opcode]
               \--->[not phpo] ---> [find cache in cache system directory] --->x---> [found] ---> [exec opcode]
                                                                                \---> [not found] ---> [exec php source] ---> [auto cache opcode]

Backward Incompatible Changes

PHP's constant is similar to a C macro,their values are determined when compiled into opcode. Therefore, the value of the system-related constant depends on the compiler's system environment. So magic constant __FILE__ is set to the absolute path of the compiler's php source file, instead of the absolute path of the opcode file when executed. __DIR__ and __LINE__ also have this problem. Therefore, applications that rely on these constants are affected.

The file path obtained by error reporting, exceptions, reflections, will also be the path to the compiled file, not the current opcode file path.

Proposed PHP Version

PHP 8.x

RFC Impact



To Existing Extensions

not support direct execution opcode file in phar.

To Opcache

Opcache can direct execution opcode file without php source file. When direct execution opcode file, will remove verify accel_system_id and validate_timestamps. Other is compatible.

New Constants


php.ini Defaults

If there are any php.ini settings then list:

  • opcache.allow_direct_exec_opcode
    • if set 0, default value, same as the current state, can not direct exec any opcode file
    • if set 1, only when opcode file start is <?phpo, direct exec opcode file without php source file
  • opcache.prohibit_different_version_opcode
    • set 1, default value, different version opcode file exec are prohibited
    • set 0, different version opcode file will report E_WARNING message

Some scenarios

  1. This RFC will avoid cold start on the WEB service and avoid opcache expiration. For example, when deploying PHP applications through docker, cold starts are avoided when adding docker services.
  2. Desktop applications developed with PHP, but require some code protection to avoid being easily modified. For example, internal systems, but can avoid non-professional error modifications.
  3. Zend Guard can be simply replaced.
  4. The php project is compiled into a binary file instead of packaged into a file.
  5. To some extent, the security of code deployed on public servers is protected, such as shared hosts


Voting opens 2021-04-05 and 2021-04-20 at 00:00:00 UTC. 2/3 required to accept.

Add OPCache direct execution opcode without source file
Real name Yes No
alcaeus (alcaeus)  
alec (alec)  
ashnazg (ashnazg)  
brzuchal (brzuchal)  
crell (crell)  
cschneid (cschneid)  
galvao (galvao)  
gasolwu (gasolwu)  
girgias (girgias)  
jhdxr (jhdxr)  
kalle (kalle)  
kelunik (kelunik)  
kguest (kguest)  
kinncj (kinncj)  
krakjoe (krakjoe)  
laruence (laruence)  
lcobucci (lcobucci)  
levim (levim)  
lufei (lufei)  
marandall (marandall)  
nikic (nikic)  
ocramius (ocramius)  
patrickallaert (patrickallaert)  
pierrick (pierrick)  
pollita (pollita)  
reywob (reywob)  
santiagolizardo (santiagolizardo)  
sergey (sergey)  
stas (stas)  
svpernova09 (svpernova09)  
tandre (tandre)  
tiffany (tiffany)  
trowski (trowski)  
villfa (villfa)  
yunosh (yunosh)  
Final result: 0 35
This poll has been closed.

Patches and Tests



rfc/direct-execution-opcode.txt · Last modified: 2021/04/23 18:07 by imsop