JIT是一種編譯器策略，它將程式碼表述為一種中間狀態，在運行時將其轉換為依賴體系結構的機器碼，並即時執行，在PHP8中，Zend VM不需要解釋某些操作碼，並且這些指令將直接作為CPU級指令執行。
PHP 8 的JIT
PHP 8 Just In Time (JIT) 編譯器帶來的影響是毋庸置疑的。但到目前為止，我發現關於 JIT 應該做什麼卻知之甚少。
推薦影片教學：《PHP程式設計從入門到精通》
經過多次研究和放棄，我決定親自檢查 PHP 原始碼。結合我對 C 語言的一些知識和我目前收集到的所有零散信息，我提出了這篇文章，我希望它能幫助您更好地理解 PHP 的 JIT。
簡單一點來說 ： 當 JIT 按預期工作時，您的程式碼不會透過 Zend VM 執行，而是作為一組 CPU 層級指令直接執行。
這就是全部的想法。
但為了更好地理解它，我們需要考慮 php 如何在內部運作。不是很複雜，但需要一些介紹。
PHP 的程式碼是怎麼執行的？
總所周知， PHP 是解釋型語言，但這句話本身又是什麼意思呢？
每次執行 PHP 程式碼（命令列腳本或 WEB 應用程式）時，都要經過 PHP 解譯器。最常用的是 PHP-FPM 和 CLI 解譯器。
解釋器的工作很簡單：接收 PHP 程式碼，對其進行解釋，然後傳回結果。
一般的解釋型語言都是這個流程。有些語言可能會減少幾個步驟，但總體的思路相同。在 PHP 中，這個流程如下：
讀取 PHP 程式碼並將其解釋為一組稱為 Tokens 的關鍵字。這個過程讓解釋器知道各個程式都寫了哪些程式碼。這一步稱為 Lexing 或 Tokenizing 。
拿到 Tokens 集合以後，PHP 解譯器會嘗試解析他們。透過稱為 Parsing 的過程產生抽象語法樹（AST）。這裡 AST 是一個節點集表示要執行哪些動作。例如，「 echo 1 1 」實際意義是 「印 1 1 的結果」 或者更詳細的說 「印出一個動作，這個動作是 1 1」。
有了 AST ，可以更輕鬆地理解操作和優先順序。將抽象語法樹轉換成可以被 CPU 執行的操作需要一個用於過渡的表達式 (IR)，在 PHP 中我們稱為 Opcodes 。將 AST 轉換為 Opcodes 的過程稱為 compilation 。
有了 Opcodes ，有趣的部分就來了： executing 程式碼！ PHP 有一個稱為 Zend VM 的引擎，該引擎能夠接收一系列 Opcodes 並執行它們。執行所有 Opcodes 後， Zend VM 就會將程式終止。
這是包含 Opcache 擴充功能的流程示意圖：
#JIT 編譯有什麼效果？
聽了 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 是處理「小於或等於」(
使用機器碼執行類型推斷邏輯是不可行的，並且可能變得更慢。
先求值再編譯也不是個好選擇，因為編譯成機器碼就是 CPU 密集型任務。因此，在運行時編譯所有內容也不好。
#
以上是PHP8 的 JIT 是什麼？的詳細內容。更多資訊請關注PHP中文網其他相關文章！
