| Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
| rfc:jit [2019/02/13 09:27] – Minor fixes to State&compatibility zeev | rfc:jit [2019/03/15 09:33] – dmitry |
|---|
| When enabled, native code of PHP files is stored in an additional region of the OPcache shared memory and op_array->opcodes[].handler(s) keep pointers to the entry points of JIT-ed code. This approach doesn't require engine modification at all. | When enabled, native code of PHP files is stored in an additional region of the OPcache shared memory and op_array->opcodes[].handler(s) keep pointers to the entry points of JIT-ed code. This approach doesn't require engine modification at all. |
| |
| We use DynAsm (developed for LuaJIT project) for generation of native code. It's a very lightweight and advanced tool, but does assume good, and very low-level development knowledge of target assembler languages. In the past we tried LLVM, but its code generation speed was almost 100 times slower, making it prohibitively expensive to use. Currently we support only x86 and x86_64 on POSIX platforms. Windows support should be relatively straightforward, but was (and still is) a low priority for us. DynAsm also supports ARM. ARM64, MIPS, MIPS64 and PPC, so in theory we should be able to support all of the platforms that are popular for PHP deployments (given enough efforts). | We use DynAsm (developed for LuaJIT project) for generation of native code. It's a very lightweight and advanced tool, but does assume good, and very low-level development knowledge of target assembler languages. In the past we tried LLVM, but its code generation speed was almost 100 times slower, making it prohibitively expensive to use. Currently we support x86 and x86_64 CPUs on POSIX platforms and Windows. DynAsm also supports ARM. ARM64, MIPS, MIPS64 and PPC, so in theory we should be able to support all of the platforms that are popular for PHP deployments (given enough efforts). |
| |
| PHP JIT doesn't introduce any additional IR (Intermediate Representation) form. It generates native code directly from PHP byte-code and information collected by SSA static analyses framework (a part of opcache optimizer). Code is usually generated separately for each PHP byte-code instruction. Only few combinations are considered together (e.g. compare + conditional jump). | PHP JIT doesn't introduce any additional IR (Intermediate Representation) form. It generates native code directly from PHP byte-code and information collected by SSA static analyses framework (a part of opcache optimizer). Code is usually generated separately for each PHP byte-code instruction. Only few combinations are considered together (e.g. compare + conditional jump). |
| |
| ===== State and compatibility ===== | ===== State and compatibility ===== |
| Currently we only support x86 and x86_64 non-ZTS builds on POSIX platforms (tested on Linux). | Currently we support x86 and x86_64 on POSIX platforms (tested on Linux with GCC and LVVM) and Windows (both non-ZTS and ZTS builds). We support "Hybrid" and "Call" VM with and without GCC explicit global register variables extension. |
| We support only "Hybrid VM" that requires C compiler with GCC extensions (labels as values and explicit global register variables). Unfortunately, LLVM doesn't support the second feature and MSVC - both. | There are no any restrictions on C compiler and OS any more. |
| | |
| ZTS support is doable and shouldn't be very difficult, but should be implemented once the ZTS improvements described at [[https://wiki.php.net/zts-improvement|https://wiki.php.net/zts-improvement]] are done. | |
| | |
| LLVM and MSVC are not currently supported. Without JIT, bench.php is about 2 times faster on PHP built with GCC, compared to with LLVM or MSVC. LLVM and MSVC require support for "Call VM" (which was already implemented, but wasn't tested for a while) and additional code for opcode handlers argument passing and FP/IP register reloading (to emulate register variables and reuse existing code-generator). Windows support might also require adopting a different calling convention. | |
| | |
| An alternative way to support all platforms and C compilers is generating a low-level VM (using the same JIT framework). This VM won't depend on C compiler extensions, and going to be compatible with JIT out of the box. As a side effect, interpretation should also become faster. This approach is used in the JVM template VM, the low level WebKit interpreter, the V8 ignition interpreter and the LuaJIT interpreter. Low-level VM may be implemented in PHP 8, in addition to existing interpreter written in C. | |
| |
| ===== Open Issues ===== | ===== Open Issues ===== |