理解 PHP 8 的 JIT

 

 

TL;DR

PHP 8 的 JIT（Just In Time）編譯器將做爲擴展集成到 php 中 Opcache 擴展 用於運行時將某些操做碼直接轉換爲從 cpu 指令。

這意味着使用 JIT 後，Zend VM 不須要解釋某些操做碼，而且這些指令將直接做爲 CPU 級指令執行。

PHP 8 的 JIT

PHP 8 Just In Time (JIT) 編譯器帶來的影響是毋庸置疑的。可是到目前爲止，我發現關於 JIT 應該作什麼卻知之甚少。

通過屢次研究和放棄，我決定親自檢查 PHP 源代碼。結合我對 C 語言的一些知識和我目前收集到的全部零散信息，我提出了這篇文章，我但願它能幫助您更好地理解 PHP 的 JIT。

簡單一點來講 ： 當 JIT 按預期工做時，您的代碼不會經過 Zend VM 執行，而是做爲一組 CPU 級指令直接執行。

這就是所有的想法。

可是爲了更好地理解它，咱們須要考慮 php 如何在內部工做。不是很複雜，但須要一些介紹。

PHP 的代碼是怎麼執行的？

總所周知， PHP 是解釋型語言，但這句話自己是什麼意思呢？

每次執行 PHP 代碼（命令行腳本或者 WEB 應用）時，都要通過 PHP 解釋器。最經常使用的是 PHP-FPM 和 CLI 解釋器。

 

解釋器的工做很簡單：接收 PHP 代碼，對其進行解釋，而後返回結果。

通常的解釋型語言都是這個流程。有些語言可能會減小几個步驟，但整體的思路相同。在 PHP 中，這個流程以下：

1. 讀取 PHP 代碼並將其解釋爲一組稱爲 Tokens 的關鍵字。這個過程讓解釋器知道各個程序都寫了哪些代碼。 這一步稱爲 Lexing 或 Tokenizing 。
2. 拿到 Tokens 集合之後，PHP 解釋器將嘗試解析他們。經過稱之爲 Parsing 的過程生成抽象語法樹（AST）。這裏 AST 是一個節點集表示要執行哪些操做。好比，「 echo 1 + 1 」實際含義是 「打印 1 + 1 的結果」 或者更詳細的說 「打印一個操做，這個操做是 1 + 1」。
3. 有了 AST ，能夠更輕鬆地理解操做和優先級。將抽象語法樹轉換成能夠被 CPU 執行的操做須要一個用於過渡的表達式 (IR)，在 PHP 中咱們稱之爲 Opcodes 。將 AST 轉換爲 Opcodes 的過程稱爲 compilation 。
4. 有了 Opcodes ，有趣的部分就來了： executing 代碼！ PHP 有一個稱爲 Zend VM 的引擎，該引擎可以接收一系列 Opcodes 並執行它們。執行全部 Opcodes 後， Zend VM 就會將該程序終止。

這個圖可讓你更清楚：

 

一個簡化版的 PHP 解釋流程概述。

如你所見。這裏有個問題：即便 PHP 代碼沒改變，每次執行仍是會走此流程嗎？

讓咱們看回 Opcodes 。對了！這就是 Opcache 擴展 存在的緣由。

 

Opcache 擴展

Opcache 擴展是 PHP 附帶的，一般不必停用它。使用 PHP 最好打開 Opcache 。

 

它的做用是爲 Opcodes 添加一個內存共享緩存層。它的工做是從 AST 中提取新生成的 Opcodes 並緩存它們，以便執行時

能夠跳過 Lexing/Tokenizing 和 Parsing 步驟。

這是包含 Opcache 擴展的流程示意圖：

 

 

PHP 使用 Opcache 的解釋流程。若是文件已經被解析，則 PHP 會爲其獲取緩存的 Opcodes ，而不是再次解析。

 

完美的跳過了 Lexing/Tokenizing 、 Parsing 和 Compiling 步驟 。

 

旁註： 這是超讚的 PHP 7.4 預加載功能 RFC ! 容許你告訴 PHP FPM 解析代碼庫，將其轉換爲 Opcodes 而且在執行以前就將其緩存。

你想知道 JIT 是怎麼參與這個解釋流程的嗎？這篇文章的將說明。

 

Just In Time 編譯有什麼效果？

聽了 Zeev 在 PHP Internals News 發表的 PHP 和 JIT 廣播 以後，我弄清了 JIT 實際作了什麼事情。

若是說 Opcache 擴展能夠更快的獲取 Opcodes 將其直接轉到 Zend VM，則 JIT 讓它們徹底不使用 Zend VM 便可運行。

 

Zend VM 是用 C 編寫的程序，充當 Opcodes 和 CPU 之間的一層。 JIT 在運行時直接生成編譯後的代碼，所以 PHP 能夠

 

跳過 Zend VM 並直接被 CPU 執行。 從理論上說，性能會更好。

這聽起來很奇怪，由於在編譯成機器碼以前，須要爲每種類型的結構體編寫一個具體的實現。但實際上這也是合理的。

PHP 的 JIT 使用了名爲 DynASM (Dynamic Assembler) 的庫，該庫將一種特定格式的一組 CPU 指令映射爲許多不一樣 CPU 類型的彙編代碼。所以，編譯器只須要使用 DynASM 就能夠將 Opcodes 轉換爲特定結構體的機器碼。

可是，有一個問題困擾了我好久。

若是預加載可以在執行以前將 PHP 代碼解析爲 Opcodes，而且 DynASM 能夠將 Opcodes 編譯爲機器碼 (Just In Time 編譯) ，爲何咱們不當即使用運行前編譯 (Ahead of Time 編譯) 當即編譯 PHP 呢？

經過收聽 Zeev 的廣播，我找到的緣由之一就是 PHP 是弱類型語言，這意味着在 Zend VM 嘗試執行某個操做碼以前， PHP 一般不知道變量的類型。

能夠查看 Zend_value 聯合類型 得知，不少指針指向不一樣類型的變量。每當 Zend VM 嘗試從 Zend_value 獲取值時，它都會使用像 ZSTR_VAL 這樣的宏，獲取聯合類型中字符串的指針。

例如，這個 Zend VM handler 是處理「小於或等於」(<=) 表達式。看看它編碼這麼多的 if else 分支，只是爲了類型推斷。

使用機器碼執行類型推斷邏輯是不可行的，而且可能變得更慢。

先求值再編譯也不是一個好選擇，由於編譯爲機器碼是 CPU 密集型任務。所以，在運行時編譯全部內容也很差。

那麼 Just In Time 編譯是怎麼作的？

如今咱們知道沒法很好的推斷類型來提早編譯。咱們也知道在運行時進行編譯的運算成本很高。那麼 JIT 對 PHP 有何好處呢？

 

爲了尋求平衡， PHP 的 JIT 嘗試只編譯有價值的 Opcodes 。爲此， JIT 會分析 Zend VM 要執行的 Opcodes 並檢查可能編譯的地方。（根據配置文件）

當某個 Opcode 編譯後，它將把執行交給該編譯後的代碼，而不是交給 Zend VM 。看起來以下：

 

PHP 的 JIT 解釋流程。若是已編譯，則 Opcodes 不會經過 Zend VM 執行。

 

所以，在 Opcache 擴展中，有兩條檢測指令判斷要不要編譯 Opcode 。若是要，編譯器將使用 DynASM 將此 Opcode 轉換爲機器碼，並執行此機器碼。

有趣的是，因爲當前接口中編譯的代碼有 MB 的限制 (也是可配置的)，因此代碼執行必須可以在 JIT 和解釋代碼之間無縫切換。

順便說一句，Benoit Jacquemont 在 php 的 JIT 上的這篇演講幫助我理解了這整件事。

我仍然不肯定編譯部分何時有效進行，但我想如今我真的不想知道。

因此你的性能收益可能不會很大

我但願如今你們都很清楚爲何大多數 php 應用程序不會由於使用即時編譯器而得到很大的性能收益。這也是爲何 Zeev 建議爲你的應用程序分析和試驗不一樣的 JIT 配置是最好的方法。

若是您使用的是 PHP FPM，則一般會在多個請求之間共享已編譯的操做碼，但這仍然不能改變遊戲規則。

這是由於 JIT 優化了計算密集型的操做，而現在大多數 php 應用程序比其餘任何東西都更受 I/O 約束。若是您不管如何都要訪問磁盤或網絡，則處理操做是否已編譯則可有可無。時間上將很是類似。

除非…

你正在作一些不受 I/O 約束的事情， 像圖像處理或機器學習。 任何不接觸 I/O 的東西都將受益於 JIT 編譯器。

這也是爲何如今人們說咱們更願意用 PHP 編寫原生功能而不是 C 編寫的緣由。 若是仍然要編譯此功能，則開銷將毫無表現力。

 

有趣的時光成爲一個 PHP 程序員…

---

但願本文對您有所幫助，使您能更好的理解 PHP8 的 JIT。

 

更多PHP內容請訪問：

騰訊T3-T4標準精品PHP架構師教程目錄大全，只要你看完保證薪資上升一個臺階（持續更新）​