php 虚拟机速度慢,[译]PHP虚拟机（PHP Virtual Machine）
標簽： PHP
本篇文章旨在提供一個對PHP7版本中Zend虛擬機的概述，不會做到面面俱到的詳細敘述，但盡力包含大多數重要的部分，以及更精細的細節。
這篇文章描述的主要背景是PHP版本7.2(當前正在開發版本)，但幾乎同樣適用于PHP7.0/7.1版本中。然而，PHP5.x系列版本的虛擬機之間差別比較顯著，筆者不會去比較。
本文的大部分內容將在指令列表級別進行考慮，最后只有幾節討論VM的實際C語言實現。但是，我確實想提供一些組成VM前端的主要文件：
zend_vm_def.h：VM定義文件
zend_vm_execute.h：生成的虛擬機文件
zend_vm_gen.php：生成腳本
zend_execute.c：大多數直接支持文件
操作碼 (Opcodes)
首先我們來談一下操作碼，“操作碼”是指完整的VM指令(包括操作數)，但也可以只指定“實際”操作代碼--一個決定指令類型的小整數。從上下文來看，指令的意圖應該是清晰的。在文件源碼中，完整的指令通常被稱為Opline。
一個獨立的指令遵循如下zend_op結構體：
struct _zend_op {
const void *handler;
znode_op op1;
znode_op op2;
znode_op result;
uint32_t extended_value;
uint32_t lineno;
zend_uchar opcode;
zend_uchar op1_type;
zend_uchar op2_type;
zend_uchar result_type;
};
如上，操作碼實質上是“三地址”指令格式。其中‘opcode’決定指令類型，還有兩個輸入的操作數‘op1’和‘op2’以及一個輸出操作數‘result’。
并不是所有的指令都會用到所有的操作數。ADD指令(代表+操作符)會用到三個操作數。BOOL_NOT指令(代表！操作符)只用到op1和result。ECHO指令只會用到op1操作符。有些指令甚至可以使用或者不使用操作符。例如，DO_FCALL可以使用或者不使用result操作符，具體取決于是否使用函數調用的返回值。有些指令需要兩個以上輸入操作數，在這種情況下，只需要使用第二個虛擬指令/偽指令(OP_DATA)來攜帶額外的操作數。
除了這三個標準操作數之外，還有一個附加的數值extended_value 字段，可以用來保存附加的指令修飾符。例如，對于強制轉換(CAST)，它可能包含要強制轉換的目標類型。
每個操作數都有對應的一個類型，分別存儲在op1_type, op2_type和result_type中。可能的類型有IS_UNUSED, IS_CONST, IS_TMPVAR, IS_VAR and IS_CV。
后三種類型指定變量操作數(有三種不同類型的VM變量)，IS_CONST表示常量操作數(5或“String”或偶數[1，2，3])，而IS_UNUSED表示實際未使用的操作數，或作為32位數值(匯編術語中的“立即”)使用的操作數。例如，跳轉指令將跳轉目標存儲在未使用的操作數中。
獲取操作指令(Obtaining opcode dumps)
接下來，筆者將經常列出PHP代碼生成的操作碼序列。目前有三種方法可以將這些操作碼轉儲：
# Opcache, since PHP 7.1
php -d opcache.opt_debug_level=0x10000 test.php
# phpdbg, since PHP 5.6
phpdbg -p* test.php
# vld, third-party extension
php -d vld.active=1 test.php
其中，Opcache提供了最高質量的輸出。本文中使用的清單基于opcache轉儲，并進行了一些語法調整。魔術數字0x10000是“優化前”的縮寫，因此我們看到PHP編譯器生成的操作碼。0x20000會給你優化的操作碼。Opcache還可以生成更多的信息，例如0x40000將生成一個CFG，而0x200000將生成類型和范圍推斷的SSA表單。但這已經超越了我們想要的：普通的、原本的線性化操作碼轉儲對我們來說就足夠了。
變量類型(Variable types)
在研究虛擬機時，可能需要理解的最重要的一點在于它使用的三種不同的變量類型：
CV是“compiled variable”的縮寫，而且指向一個“真正的”PHP變量。如果函數使用變量$a，就會有$a對應的CV。
CV可以有UNDEF類型，用來指向未定義變量。如果UNDEF CV在一個指令中用到，在大多數情況下會拋出“未定義變量(undefined variable)”提示。在函數入口處所有非參數CV會被初始化為UNDEF。
CV不會被指令消耗(consumed)，例如，指令ADD $a,$b 不會銷毀存儲在CV中的變量$a和$b。然而所有的CV都會在事務(scope)退出時一起銷毀。這也暗示所有的CV在整個函數的域內都將‘live’--包含一個有效值。
TMPVARS和VARS是虛擬機的臨時變量。它們通常被用作一些操作指令的結果操作數。例如$a = $b + $c + $d會輸出如下類似指令序列：
T0 = ADD $b,$c
T1 = ADD T0,$d
ASSIGN $a,T1
TMP/VAR是在使用前定義的，因此不能保存UNDEF值。與CV不同，這些變量類型是由它們所使用的指令所消耗的。在上面的示例中，第二個ADD將破壞T0操作數的值，在此之后不能使用T0(除非事先寫入)。類似地，ASSIGN將消耗T1的值，使T1無效。
因此，TMP/VAR通常壽命很短。在許多情況下，一個臨時變量只存在一個指令的空間。在這個短暫的活動之外，臨時變量就成了垃圾。
那么TMP和VAR有什么區別呢？不多。這種區別是從PHP5繼承的，TMP是分配在VM棧中的，而VAR是分配在堆中的。在PHP7中，所有變量都是分配在棧中。因此，現在TMP和VAR的主要區別是只允許后者包含引用(REFERENCEs)(這允許我們在TMP上刪除DEREF)。此外，VAR可能包含兩種特殊值，即類條目(class entries)和間接值(INDIRECT values)。后者用于處理特殊的任務。
-
UNDEF
REF
INDIRECT
Consumed?
Named?
CV
yes
yes
no
no
yes
TMPVAR
no
no
no
yes
no
VAR
no
yes
yes
yes
no
下方圖表分析了主要的區別：
-
UNDEF
REF
INDIRECT
Consumed?
Named?
CV
yes
yes
no
no
yes
TMPVAR
no
no
no
yes
no
VAR
no
yes
yes
yes
no
指令數組(Op arrays)
所有PHP函數都表示為具有公共Zend_Function的 Header結構。這里的“函數”應該有一些廣義的理解，包括從“真正的”函數到方法，到獨立的“偽主(pseudo-main)”代碼和“eval”代碼。
用戶級函數使用zend_op_Array結構。它有30多個成員，所以我現在先從一個簡化版本開始：
struct _zend_op_array {
/* Common zend_function header here */
/* ... */
uint32_t last;
zend_op *opcodes;
int last_var;
uint32_t T;
zend_string **vars;
/* ... */
int last_literal;
zval *literals;
/* ... */
};
最重要的部分當然是opcodes，它是一個包含操作指令的數組。‘last’是數組中操作指令的數量，注意這里的術語可能令人感到困惑，‘last’看起來像是最后一個操作指令的索引，但是這里實際上是操作數的數量(比最后一個操作數的索引大一)。這同樣適用于op數組結構中的所有其他‘last_ *’值。
‘last_var’是CV的數量，‘T’是TMP和VAR的數量(在大多數情況下兩者沒有明顯的區別)。‘vars’是CV的命名。
‘literals’是出現在代碼中字面值的數組，這個數組是CONST操作數引用。根據ABI①，每個CONST操作數要么儲存指向次文本表的引用，要么存儲相對于其開始的偏移量。
關于op數組(op array)的內容不止于此。
棧框架布局(Stack frame layout)
除了一些全局指令EG(excutor globals)，所有的執行狀態都存儲在虛擬機棧中。虛擬機棧以大小為256KB的page分配，通過鏈表進行連接。
每一個函數調用時，將在VM棧上分配一個新的棧幀，布局如下：
+----------------------------------------+
| zend_execute_data |
+----------------------------------------+
| VAR[0] = ARG[1] | arguments
| ... |
| VAR[num_args-1] = ARG[N] |
| VAR[num_args] = CV[num_args] | remaining CVs
| ... |
| VAR[last_var-1] = CV[last_var-1] |
| VAR[last_var] = TMP[0] | TMP/VARs
| ... |
| VAR[last_var+T-1] = TMP[T] |
| ARG[N+1] (extra_args) | extra arguments
| ... |
+----------------------------------------+
該框架以一個zend_execute_data結構開始，接著是一個變量槽(variable slots)的數組。這些變量槽都相同(simple zvals)，但是用作不同的用途。第一個‘last_var’槽中內容是CV，其中第一個num_args存放函數參數。CV插槽之后是TMP/ VAR的‘T’插槽。最后，有時可以在幀的末尾存儲“額外”參數。這些用于處理func_get_args()。
指令中的CV和TMP/VAR操作數被編碼為相對于堆棧起始位置的偏移量，因此讀取某個變量只是從execute_data位置讀取的偏移量。
幀開始處的執行數據定義如下：
struct _zend_execute_data {
const zend_op *opline;
zend_execute_data *call;
zval *return_value;
zend_function *func;
zval This; /* this + call_info + num_args */
zend_class_entry *called_scope;
zend_execute_data *prev_execute_data;
zend_array *symbol_table;
void **run_time_cache; /* cache op_array->run_time_cache */
zval *literals; /* cache op_array->literals */
};
最重要的是，這個結構包含opline(當前執行的指令)和func(它是當前執行的函數)。此外：
return_value是一個指向將存儲返回值的zval的指針。
‘This’是$this對象，但也會編碼一些未使用的zval空間中函數參數的數目和一些調用元數據標志。
called_scope是static ::在PHP代碼中引用的范圍。
prev_execute_data指向前一個棧幀，在此函數完成運行后，執行將返回到該幀。
symbol_table是一個通常未使用的符號表，用于某些瘋狂的人實際使用變量變量或類似功能的情況。($$a)
run_time_cache緩存op數組運行時緩存，以便在訪問此結構時避免一個指針間接尋址(稍后討論)。
由于相同的原因，literals緩存op數組字面量表。
函數調用(Function calls)
筆者跳過了execute_data結構中的一個字段--‘call'，因為它需要關于函數調用如何工作的更多上下文。所有調用都使用相同指令序列的變體。全局作用域中的var_dump($a，$b)將編譯為：
INIT_FCALL (2 args) "var_dump"
SEND_VAR $a
SEND_VAR $b
V0 = DO_ICALL # or just DO_ICALL if retval unused
有八種不同類型的INIT指令，取決于它是什么類型的調用。INIT_FCALL與調用相關，用來釋放我們在編譯時識別的函數。同樣，根據參數和函數的類型，有十個不同的SEND操作碼。只有數量較少的四個DO_CALL操作碼，其中ICALL用于調用內部函數。
雖然具體指令可能不同，但結構總是相同的：INIT，SEND，DO。調用序列必須解決的主要問題是嵌套函數調用，它們編譯如下所示：
# var_dump(foo($a), bar($b))
INIT_FCALL (2 args) "var_dump"
INIT_FCALL (1 arg) "foo"
SEND_VAR $a
V0 = DO_UCALL
SEND_VAR V0
INIT_FCALL (1 arg) "bar"
SEND_VAR $b
V1 = DO_UCALL
SEND_VAR V1
V2 = DO_ICALL
INIT操作碼在堆棧上壓入一個調用幀，該幀包含了函數中所有變量的足夠空間以及我們所知道的參數的數量(如果涉及參數解包，我們可能會以更多參數結束)。
指向新幀的指針存儲到execute_data-> call中，其中execute_data是調用函數的幀。在下面，我們將把這些訪問表示為EX(call)。值得注意的是，新幀的prev_execute_data被設置為舊的EX(call)值。例如，調用foo的INIT_FCALL會將prev_execute_data設置為va_dump的堆棧幀(而不是周邊函數的棧幀)。因此，在這種情況下，prev_execute_data形成一個“未完成”調用的鏈表，而通常它會提供回溯鏈(雙向鏈表)。
SEND操作碼然后繼續將參數推送到EX(call)的變量槽中。在這一點上，參數都是連續的，并且可以從為參數指定的部分溢出到其他CV或TMP中。這將在稍后修復。
最后DO_FCALL執行實際的調用。EX(call)成為當前函數，prev_execute_data被重新鏈接到調用函數。除此之外，調用過程取決于它是什么類型的功能。內部函數只需要調用處理函數，而用戶級函數需要完成棧幀的初始化。
這個初始化涉及修復參數棧。PHP允許傳遞比函數期望更多的參數(func_get_args依賴于這個功能)。但是，只有實際聲明的參數才具有相應的CV。除此以外的任何參數都會寫入為其他CV和TMP保留的內存。因此，這些參數將在TMP之后移動，最終將參數分成兩個不連續的塊。
為了清楚地說明，用戶級函數調用不涉及虛擬機級別的遞歸。它們只涉及從一個execute_data切換到另一個execute_data，但虛擬機繼續以線性循環運行。遞歸虛擬機調用僅在內部函數調用用戶空間回調(例如通過array_map)時才會發生。這就是為什么PHP中的無限遞歸通常會導致內存限制或OOM錯誤的原因，通過遞歸使用回調函數或魔術方法可能引發棧溢出。
參數傳遞(Argument sending)
PHP使用大量不同的參數發送操作碼，這些操作碼的區別可能會造成混淆。
SEND_VAL和SEND_VAR是最簡單的變體，它處理在編譯時已知是按值傳遞時進行的按值傳遞參數。SEND_VAL用于CONST和TMP操作數，而SEND_VAR用于VAR和CV。
相反，SEND_REF用于在編譯期間已知為引用傳遞的參數傳遞。由于只有變量可以通過引用發送，這個操作碼只接受VAR和CV。
SEND_VAL_EX和SEND_VAR_EX是SEND_VAL / SEND_VAR的變體，用于無法靜態確定參數是按值還是按引用傳遞的情況。這些操作碼將根據arginfo檢查參數的種類并相應地執行操作。在大多數情況下，不使用實際的arginfo結構，而是直接在函數結構中使用緊湊的位向量表示。
然后是SEND_VAR_NO_REF_EX。不要試圖名稱上了解這個指令。這個操作碼用于傳遞一些不是真正的“變量”，但是會返回一個VAR到一個靜態未知參數的東西。使用它的兩個特定示例是將函數調用的結果作為參數傳遞，或者傳遞賦值的結果。②
這種情況需要一個獨立的操作碼，原因有兩個：首先，如果嘗試通過ref傳遞類似于賦值的內容它會生成熟悉的“只能通過引用傳遞變量”通知(如果使用SEND_VAR_EX，則會被默許)。其次，這個操作碼處理的情況是，你可能想要將引用返回函數的結果傳遞給一個引用參數(它不應該拋出任何東西)。該操作碼的SEND_VAR_NO_REF變體(不帶_EX)是一種特殊的變體，用于靜態地知道引用是預期的情況(但我們不知道該變量是否為一個)。
SEND_UNPACK和SEND_ARRAY操作碼分別處理參數解包和內聯call_user_func_array調用。它們都將數組中的元素推入參數棧，并在各種細節上有所不同(例如，解包支持Traversables，而call_user_func_array則不支持)。如果使用unpacking/cufa，則可能需要將棧框架擴展超出其以前的大小(因為函數參數的實數在初始化時是未知的)。在大多數情況下，只需移動堆棧頂部指針就可以進行擴展。但是，如果這會跨越堆棧頁面邊界，則必須分配新頁面，并且需要將整個調用幀(包括已經推入的參數)復制到新頁面(我們無法處理穿過頁面的調用幀邊界)。
最后一個操作碼是SEND_USER，用于內聯調用call_user_func并處理它的一些特性。
雖然我們尚未討論不同的變量獲取模式，但這似乎是介紹FUNC_ARG獲取模式的好地方。考慮一個簡單的調用func($a[0][1][2])，在編譯時我們不知道這個參數是通過值還是通過引用傳遞的。在這兩種情況下，行為將會大不相同。如果傳遞是按值并且$a以前是空的，則可能必須生成一堆“未定義索引”通知。如果傳遞是通過引用的話，我們必須默默地初始化嵌套數組。
FUNC_ARG獲取模式將通過檢查當前EX(call)函數的arginfo來動態選擇兩種行為之一(R或W)。對于func($a[0][1][2])的例子，操作碼序列可能是這個樣子：
INIT_FCALL_BY_NAME "func"
V0 = FETCH_DIM_FUNC_ARG (arg 1) $a, 0
V1 = FETCH_DIM_FUNC_ARG (arg 1) V0, 1
V2 = FETCH_DIM_FUNC_ARG (arg 1) V1, 2
SEND_VAR_EX V2
DO_FCALL
取參模式(Fetch modes)
PHP虛擬機有四類提取操作碼：
FETCH_* // $_GET, $$var
FETCH_DIM_* // $arr[0]
FETCH_OBJ_* // $obj->prop
FETCH_STATIC_PROP_* // A::$prop
這些完全符合人們期望它們做的事情，但要注意基本的FETCH_*變體僅用于訪問變量變量和超全局變量：正常變量訪問通過更快的CV機制來代替。
這些提取操作碼每個都有六種變體：
_R
_RW
_W
_IS
_UNSET
_FUNC_ARG
我們已經知道，_FUNC_ARG根據函數參數是按值還是按引用來選擇_R和_W。讓我們嘗試創建一些我們期望不同的獲取類型出現的情況：
// $arr[0];
V2 = FETCH_DIM_R $arr int(0)
FREE V2
// $arr[0] = $val;
ASSIGN_DIM $arr int(0)
OP_DATA $val
// $arr[0] += 1;
ASSIGN_ADD (dim) $arr int(0)
OP_DATA int(1)
// isset($arr[0]);
T5 = ISSET_ISEMPTY_DIM_OBJ (isset) $arr int(0)
FREE T5
// unset($arr[0]);
UNSET_DIM $arr int(0)
不幸的是，這個產生的唯一真正的提取是FETCH_DIM_R：其他的東西都是通過特殊的操作碼處理的。請注意，ASSIGN_DIM和ASSIGN_ADD都使用額外的OP_DATA，因為它們需要兩個以上的輸入操作數。使用特殊操作碼(如ASSIGN_DIM)而不是像FETCH_DIM_W + ASSIGN之類的原因是(除了性能)，這些操作可能被重載，例如，在ASSIGN_DIM情況下，通過實現ArrayAccess::offsetSet()的對象實現。要實際生成不同的提取類型，我們需要增加嵌套的級別：
// $arr[0][1];
V2 = FETCH_DIM_R $arr int(0)
V3 = FETCH_DIM_R V2 int(1)
FREE V3
// $arr[0][1] = $val;
V4 = FETCH_DIM_W $arr int(0)
ASSIGN_DIM V4 int(1)
OP_DATA $val
// $arr[0][1] += 1;
V6 = FETCH_DIM_RW $arr int(0)
ASSIGN_ADD (dim) V6 int(1)
OP_DATA int(1)
// isset($arr[0][1]);
V8 = FETCH_DIM_IS $arr int(0)
T9 = ISSET_ISEMPTY_DIM_OBJ (isset) V8 int(1)
FREE T9
// unset($arr[0][1]);
V10 = FETCH_DIM_UNSET $arr int(0)
UNSET_DIM V10 int(1)
在這里我們看到，盡管最外層的訪問使用專用的操作碼，嵌套的索引將使用具有適當獲取模式的FETCH進行處理。fetch模式的基本區別在于a)如果索引不存在，它們是否生成“未定義偏移量”通知，以及它們是否獲取寫入值：
Notice?
Write?
R
yes
no
W
no
yes
RW
yes
yes
IS
no
no
UNSET
no
yes-ish
UNSET的情況有點奇怪，因為它只能讀取現有的偏移量以便寫入，并且保留單獨的未定義的偏移量。正常的寫取操作會初始化未定義的偏移量。
寫和內存安全(Writes and memory safety)
Write獲取可能包含正常zval或指向另一個zval的INDIRECT指針的返回VAR。當然，在前一種情況下，應用于zval的任何更改都將不可見，因為該值只能通過虛擬機暫時訪問。雖然PHP禁止表達[][0] = 42，但我們仍然需要處理這種情況 call()[0] = 42。取決于是call()按值還是按引用返回，此表達式可能會或可能不會有顯著效果。
更典型的情況是當提取返回一個INDIRECT時，它包含一個指向正在被修改的存儲位置的指針，例如哈希表數據數組中的某個位置。不幸的是，這樣的指針是脆弱的東西，容易失效：任何并發寫入數組可能會觸發重新分配，留下一個懸掛指針。因此，防止在創建INDIRECT值的位置與消耗的位置之間執行用戶代碼至關重要。
考慮這個例子：
$arr[a()][b()] = c();
其中產生：
INIT_FCALL_BY_NAME (0 args) "a"
V1 = DO_FCALL_BY_NAME
INIT_FCALL_BY_NAME (0 args) "b"
V3 = DO_FCALL_BY_NAME
INIT_FCALL_BY_NAME (0 args) "c"
V5 = DO_FCALL_BY_NAME
V2 = FETCH_DIM_W $arr V1
ASSIGN_DIM V2 V3
OP_DATA V5
值得注意的是，這個序列首先執行從左到右的所有內嵌函數，然后才執行任何必要的寫入讀取(我們在此將FETCH_DIM_W稱為“延遲opline”)。這確保了寫訪存和消費指令直接相鄰。
考慮另一個例子：
$arr[0] =& $arr[1];
這里我們遇到了一些問題：兩邊的復制必須提取值才能寫入。但是，如果我們抓取$arr[0] 寫入然后寫入$arr[1]，后者可能會使前者無效。這個問題解決如下：
V2 = FETCH_DIM_W $arr 1
V3 = MAKE_REF V2
V1 = FETCH_DIM_W $arr 0
ASSIGN_REF V1 V3
這里$arr[1]先取得寫入，然后轉換成使用MAKE_REF的引用。MAKE_REF的結果不再是間接的并且不會失效，因為這樣的獲取$arr[0]可以安全地執行。
異常處理(Exception handling)
異常是萬惡之源。
異常是通過將異常寫入EG(異常)來生成的，其中EG指的是執行者全局(Executor Globals)。C代碼中拋出異常不涉及堆棧展開，相反，執行退出(abortion)將通過返回值失敗代碼或檢查EG(異常)向上傳播。只有當控制器重新進入虛擬機代碼時，才會實際處理異常。
在某些情況下，幾乎所有的VM指令都可能直接或間接導致異常。例如，如果使用自定義錯誤處理程序，則任何“未定義的變量”通知都可能導致異常。我們希望避免檢查EG(exception)每個VM指令后設置。相反，使用一個小竅門：
當拋出一個異常時，當前執行數據的當前選擇行被替換為虛擬HANDLE_EXCEPTION opline(這顯然不會修改op數組，它只是重定向一個指針)。備份發生異常的對象EG(opline_before_exception)。
這意味著當控制返回到主虛擬機調度循環時，將調用HANDLE_EXCEPTION操作碼。這個方案存在一個小問題：它要求 a)存儲在執行數據中的opline實際上是當前執行的opline(否則opline_before_exception將會是錯誤的)并且 b)虛擬機使用來自執行數據的opline來繼續執行(否則HANDLE_EXCEPTION不會被調用)。
雖然這些要求可能聽起來微不足道，但它們不是。原因是虛擬機可能正在處理與執行數據中存儲的opline不同步opline變量。在PHP 7之前，這只發生在很少使用的GOTO和SWITCH虛擬機中，而在PHP 7中，這實際上是默認的操作模式：如果編譯器支持它，則opline存儲在全局寄存器中。
因此，在執行任何可能會拋出的操作之前，必須將本地對齊線寫回執行數據(SAVE_OPLINE操作)。同樣，在任何可能的拋出操作之后，必須從執行數據填充本地對象(主要是CHECK_EXCEPTION操作)。
現在，這個機制是在引發異常之后導致HANDLE_EXCEPTION操作碼執行的原因。但它有什么作用？首先，它確定是否在try塊內引發異常。為此，op數組包含一個try_catch_elements數組，用于跟蹤try，catch和finally塊的opline偏移量：
typedef struct _zend_try_catch_element {
uint32_t try_op;
uint32_t catch_op; /* ketchup! */
uint32_t finally_op;
uint32_t finally_end;
} zend_try_catch_element;
現在我們會假裝最后的塊不存在，因為它們是一個完全不同的。假設我們確實在try塊內，VM需要清理在拋出opline之前開始的所有未完成的操作，并且不會跨越try塊的末尾。
這涉及釋放當前在使用中的所有調用的棧幀和相關數據，以及釋放臨時變量。在大多數情況下，臨時變量存在時間很短，甚至達到消費指令直接跟隨著生成指令。然而，它可能發生在跨越多個指令的現場：
# (array)[] + throwing()
L0: T0 = CAST (array) []
L1: INIT_FCALL (0 args) "throwing"
L2: V1 = DO_FCALL
L3: T2 = ADD T0, V1
在這種情況下，T0變量在指令L1和L2中是活動的，因此如果函數調用拋出時需要銷毀T0變量。一種特定的臨時類型往往具有特別長的活動范圍：循環變量。例如：
# foreach ($array as $value) throw $ex;
L0: V0 = FE_RESET_R $array, ->L4
L1: FE_FETCH_R V0, $value, ->L4
L2: THROW $ex
L3: JMP ->L1
L4: FE_FREE V0
這里“循環變量”V0從L1到L3(通常總是跨越整個循環體)。實時范圍使用以下結構存儲在操作數組中：
typedef struct _zend_live_range {
uint32_t var; /* low bits are used for variable type (ZEND_LIVE_* macros) */
uint32_t start;
uint32_t end;
} zend_live_range;
這里var是范圍適用的(操作數編碼的)變量，start是開始選擇線偏移量(不包括生成指令)，而end如果結束選擇線偏移量(包括消耗指令)。當然，如果暫時沒有立即消耗，則僅存儲活動范圍。
低位var用于存儲變量的類型，可以是以下之一：
ZEND_LIVE_TMPVAR：這是一個“正常”變量。它擁有一個普通的zval值。釋放這個變量的行為就像一個免費的操作碼。
ZEND_LIVE_LOOP：這是一個foreach循環變量，它不僅包含簡單的zval。這對應于FE_FREE操作碼。
ZEND_LIVE_SILENCE：用于實現錯誤抑制運算符。舊的錯誤報告級別備份到臨時數據庫中，稍后恢復。如果拋出異常，我們顯然希望恢復它。這對應于END_SILENCE。
ZEND_LIVE_ROPE：用于繩索串連接，在這種情況下，臨時數據是位于zend_string*堆棧上的固定大小的指針數組 。在這種情況下，所有已經被填充的字符串都必須被釋放。大致對應于END_ROPE。
在這種情況下要考慮的一個棘手問題是，如果它們的產生或消費指令拋出，是否應該釋放臨時對象。考慮下面的簡單代碼：
T2 = ADD T0, T1
ASSIGN $v, T2
如果ADD引發異常，T2臨時應該自動釋放還是ADD指令對此負責？同樣，如果ASSIGN拋出，T2應該自動釋放，還是ASSIGN必須自己處理？在后一種情況下，答案是明確的：即使拋出異常，指令總是負責釋放其操作數。
結果操作數的情況比較棘手，因為這里的答案在PHP 7.1和7.2之間改變了：在PHP 7.1中，指令負責在發生異常時釋放結果。在PHP7.2中，它被自動釋放(并且該指令負責確保總是填充結果)。這種變化的動機是很多基本指令(如ADD)的實施方式。他們通常的結構大致如下：
1. read input operands
2. perform operation, write it into result operand
3. free input operands (if necessary)
這是有問題的，因為PHP處于非常不幸的位置，不僅支持異常和析構函數，而且還支持拋出析構函數(這是編譯器工程師驚恐地哭泣的地步)。因此，第3步可以拋出，在這一點上結果已經填充。為避免這種邊緣情況下的內存泄漏，釋放結果操作數的責任已從指令轉移到異常處理機制。
一旦我們執行了這些清理操作，我們就可以繼續執行catch塊。如果沒有catch(最后也沒有)，我們展開堆棧，也就是銷毀當前的堆棧幀并在處理異常時給父幀一個shot。
因此，您可以充分理解整個異常處理業務的丑陋程度，我將介紹與拋出析構函數相關的另一個小技巧。這在實踐中并不是很相關，但我們仍然需要處理它以確保正確性。考慮這個代碼：
foreach (new Dtor as $value) {
try {
echo "Return";
return;
} catch (Exception $e) {
echo "Catch";
}
}
現在想象這Dtor是一個帶有析構函數的Traversable類。此代碼將導致以下操作碼序列，并且為了可讀性而縮進循環主體：
L0: V0 = NEW 'Dtor', ->L2
L1: DO_FCALL
L2: V2 = FE_RESET_R V0, ->L11
L3: FE_FETCH_R V2, $value
L4: ECHO 'Return'
L5: FE_FREE (free on return) V2 #
L6: RETURN null #
L7: JMP ->L10
L8: CATCH 'Exception' $e
L9: ECHO 'Catch'
L10: JMP ->L3
L11: FE_FREE V2 #
重要的是，請注意“返回”被編譯為循環變量的FE_FREE和RETURN。現在，如果FE_FREE拋出，會發生什么情況，因為Dtor拋出析構函數？通常，我們會說這個指令在try塊內，所以我們應該調用catch。但是，在這一點上，循環變量已經被破壞！該catch拋棄異常，我們將嘗試繼續迭代已經死循環變量。
造成這個問題的原因是，當引發FE_FREE在try塊內時，它是L11中FE_FREE的副本。從邏輯上講，這是發生異常的地方。這就是為什么中斷生成的FE_FREE被注釋為FREE_ON_RETURN的原因。這指示異常處理機制將異常源移至原始釋放指令。因此，上面的代碼不會運行catch塊，它會生成一個未捕獲的異常。
Finally處理(Finally handling)
PHP與finally塊相關的歷史有點麻煩。PHP 5.5首先引入了最終塊，或者更確切地說：最終塊的一個非常錯誤的實現。PHP 5.6,7.0和7.1中的每一個都隨著最終實現的重寫而發布，每個都修復了大量錯誤，但未能完全實現完全正確的實現。
在編寫本節時，我很驚訝地發現，從當前的實施和我目前的理解來看，最終處理實際上并不復雜。事實上，在許多方面，通過不同的迭代實現變得更簡單，而不是更復雜。這表明對問題的理解不足可能會導致過于復雜和錯誤的實現(雖然公平地說，PHP 5實現的復雜性的一部分直接源于AST的缺乏)。
通常只要控件退出try塊，正常(例如使用返回)或異常(通過拋出)就會運行Finally塊。有幾個有趣的邊緣案例需要考慮，我將在進入實施之前快速闡述。請考慮：
try {
throw new Exception();
} finally {
return 42;
}
怎么了？最后獲勝并且函數返回42。請考慮：
try {
return 24;
} finally {
return 42;
}
finally再次贏了，函數返回42。finally總是贏。
PHP禁止跳出finally塊。例如以下是禁止的：
foreach ($array as $value) {
try {
return 42;
} finally {
continue;
}
}
上面的代碼示例中的“continue”將生成一個編譯錯誤。重要的是要明白，這個限制是純粹示例代碼(cosmetic)，并可以通過使用“眾所周知的”catch控制委托模式輕松解決：
foreach ($array as $value) {
try {
try {
return 42;
} finally {
throw new JumpException;
}
} catch (JumpException $e) {
continue;
}
}
存在的唯一真正的限制是，它是不可能跳躍到 finally塊，例如執行來自finally外部的goto跳轉到finally內標簽是被禁止的。
使用這個方式，我們可以初步的看看finally如何工作。該實現使用兩個操作碼FAST_CALL和FAST_RET。粗略地說，FAST_CALL用于跳到finally塊，FAST_RET用于跳出它。讓我們考慮最簡單的情況：
try {
echo "try";
} finally {
echo "finally";
}
echo "finished";
此代碼編譯到以下操作碼序列：
L0: ECHO string("try")
L1: T0 = FAST_CALL ->L3
L2: JMP ->L5
L3: ECHO string("finally")
L4: FAST_RET T0
L5: ECHO string("finished")
L6: RETURN int(1)
FAST_CALL將自己的位置存儲到T0中，并跳轉到L3處的finally塊中。當達到FAST_RET時，它跳回到T0中存儲的位置(之后)。在這種情況下，L2圍繞finally塊跳轉。這是沒有特殊控制流程(返回或異常)發生的基本情況。現在我們來看一下這個特例：
try {
throw new Exception("try");
} catch (Exception $e) {
throw new Exception("catch");
} finally {
throw new Exception("finally");
}
處理異常時，我們必須考慮拋出的異常相對于最接近的周圍try / catch / finally塊的位置：
從try中拋出，并匹配catch：填充$e并跳入catch。
從try或catch中拋出，如果存在finally塊：跳轉到finally塊，并且這次將異常備份到FAST_CALL臨時變量(而不是在那里存儲返回地址)。
從finally拋出：如果備份異常存在臨時FAST_CALL中的，則將其作為先前拋出異常的異常鏈接。繼續將異常冒泡到下一個try / catch / finally。
否則：繼續將異常冒泡到下一個try / catch / finally。
在這個例子中，我們將通過前三個步驟：首先嘗試拋出，引發跳入catch。Catch也會拋出，觸發到finally塊的跳轉，除非在FAST_CALL臨時中備份。然后finally塊也會拋出，這樣，“finally”異常將會像之前的異常一樣被設置為“catch”異常。
前面例子中的一個小變化是以下代碼：
try {
try {
throw new Exception("try");
} finally {}
} catch (Exception $e) {
try {
throw new Exception("catch");
} finally {}
} finally {
try {
throw new Exception("finally");
} finally {}
}
這里的所有內部最終塊都是異常輸入，但通常保持不變(通過FAST_RET)。在這種情況下，先前描述的異常處理過程從父try / catch / finally塊開始繼續。這個父try / catch存儲在FAST_RET操作碼中(這里是“try-catch(0)”)。
這基本上涵蓋finally和exceptions的關系。但finaly的返回呢？
try {
throw new Exception("try");
} finally {
return 42;
}
操作碼序列的相關部分是這樣的：
L4: T0 = FAST_CALL ->L6
L5: JMP ->L9
L6: DISCARD_EXCEPTION T0
L7: RETURN 42
L8: FAST_RET T0
額外的DISCARD_EXCEPTION操作碼負責放棄在try塊中拋出的異常(記住：finally獲勝的返回)。那么try的返回呢？
try {
$a = 42;
return $a;
} finally {
++$a;
}
這里的例外返回值是42，而不是43.返回值由return$a行確定，任何進一步的修改$a都不重要。代碼結果：
L0: ASSIGN $a, 42
L1: T3 = QM_ASSIGN $a
L2: T1 = FAST_CALL ->L6, T3
L3: RETURN T3
L4: T1 = FAST_CALL ->L6 # unreachable
L5: JMP ->L8 # unreachable
L6: PRE_INC $a
L7: FAST_RET T1
L8: RETURN null
其中兩個操作碼無法訪問，因為它們在返回后發生。這些將在優化期間被刪除，但我在這里顯示未優化的操作碼。這里有兩件有趣的事情：首先，
$a使用QM_ASSIGN(基本上是“復制到臨時變量”指令)復制到T3中。這是防止后來修改$a 影響返回值的原因。其次，T3也傳遞給FAST_CALL，它將備份T1中的值。如果try塊的返回值稍后被丟棄(例如，因為最后拋出或返回)，則此機制將用于釋放未使用的返回值。
所有這些單獨的機制都很簡單，但是在組成時需要謹慎。考慮下面的例子，其中又Dtor是一些帶有拋出析構函數的Traversable類：
try {
foreach (new Dtor as $v) {
try {
return 1;
} finally {
return 2;
}
}
} finally {
echo "finally";
}
該代碼生成以下操作碼：
L0: V2 = NEW (0 args) "Dtor"
L1: DO_FCALL
L2: V4 = FE_RESET_R V2 ->L16
L3: FE_FETCH_R V4 $v ->L16
L4: T5 = FAST_CALL ->L10 # inner try
L5: FE_FREE (free on return) V4
L6: T1 = FAST_CALL ->L19
L7: RETURN 1
L8: T5 = FAST_CALL ->L10 # unreachable
L9: JMP ->L15
L10: DISCARD_EXCEPTION T5 # inner finally
L11: FE_FREE (free on return) V4
L12: T1 = FAST_CALL ->L19
L13: RETURN 2
L14: FAST_RET T5 try-catch(0)
L15: JMP ->L3
L16: FE_FREE V4
L17: T1 = FAST_CALL ->L19
L18: JMP ->L21
L19: ECHO "finally" # outer finally
L20: FAST_RET T1
第一次返回的序列(來自內部try)是FAST_CALL L10，FE_FREE V4，FAST_CALL L19，RETURN。這將首先調用內部finally塊，然后釋放foreach循環變量，然后調用外部finally塊并返回。第二次返回的序列(最終來自內部)是DISCARD_EXCEPTION T5，FE_FREE V4，FAST_CALL L19。首先放棄內部try塊的異常(或這里：返回值)，然后釋放foreach循環變量并最終調用外部finally塊。請注意，在這兩種情況下，這些指令的順序是源代碼中相關塊的反向順序。
生成器(Generators)
發生器功能可能會暫停和恢復，因此需要特殊的VM棧管理。這是一個簡單的生成器：
function gen($x) {
foo(yield $x);
}
這會產生以下操作碼：
$x = RECV 1
GENERATOR_CREATE
INIT_FCALL_BY_NAME (1 args) string("foo")
V1 = YIELD $x
SEND_VAR_NO_REF_EX V1 1
DO_FCALL_BY_NAME
GENERATOR_RETURN null
在到達GENERATOR_CREATE之前，這是在普通VM堆棧上作為普通函數執行的。GENERATOR_CREATE然后創建一個Generator對象，以及一個堆分配的execute_data結構(像往常一樣包括變量和參數的槽)，VM棧上的execute_data被復制到其中。
當生成器再次恢復時，執行器將使用堆分配的execute_data，但將繼續使用主VM堆棧來推送調用幀。一個明顯的問題是，如前面的例子所示，在調用過程中可能會中斷發生器。這里YIELD是在調用foo()的調用幀已經被壓入VM棧的時候執行的。
這種相對不常見的情況是通過在產生控制時將調用幀復制到發生器結構中并在發生器恢復時恢復它們來處理。
這個設計自PHP 7.1起使用。以前，每個發生器都有自己的4KiB虛擬機頁面，當發生器恢復時它將被交換到執行器。這樣可以避免復制調用幀，但會增加內存使用量。
智能分支(Smart branches)
比較指令直接跟隨條件跳轉是很常見的。例如：
L0: T2 = IS_EQUAL $a, $b
L1: JMPZ T2 ->L3
L2: ECHO "equal"
由于這種模式非常普遍，所有比較操作碼(如IS_EQUAL)都實現了智能分支機制：它們檢查下一條指令是JMPZ還是JMPNZ指令，如果是，則自行執行相應的跳轉操作。
智能分支機制只檢查下一條指令是否是JMPZ/JMPNZ，但實際上并不檢查其操作數是否實際上是比較的結果或其他。在比較和隨后的跳躍不相關的情況下，這需要特別小心。例如，代碼($a == $b) + ($d ? $e : $f)生成：
L0: T5 = IS_EQUAL $a, $b
L1: NOP
L2: JMPZ $d ->L5
L3: T6 = QM_ASSIGN $e
L4: JMP ->L6
L5: T6 = QM_ASSIGN $f
L6: T7 = ADD T5 T6
L7: FREE T7
請注意，在IS_EQUAL和JMPZ之間插入了NOP。如果這個NOP不存在，分支將最終使用IS_EQUAL結果，而不是JMPZ操作數。
運行時緩存(Runtime cache)
由于操作碼數組在多個進程之間共享(無鎖)，因此它們是不可變的。但是，運行時值可以緩存在單獨的“運行時緩存”中，該緩存基本上是一個指針數組。Literals可能有一個關聯的運行時緩存條目(或多個)，它存儲在它們的u2插槽中。
運行時高速緩存條目有兩種類型：第一種是普通高速緩存條目，例如INIT_FCALL使用的條目。INIT_FCALL查找一次被調用的函數(根據其名稱)后，函數指針將被緩存在關聯的運行時緩存槽中。
第二種類型是多態高速緩存條目，它們只是兩個連續的高速緩存槽，其中第一個存儲類條目，第二個存儲實際數據。這些用于像FETCH_OBJ_R這樣的操作，其中某個類的屬性表中屬性的偏移量被緩存。如果下一次訪問發生在同一個類上(很有可能)，則將使用緩存的值。否則，將執行更昂貴的查找操作，并將結果緩存到新的類條目中。
VM中斷(VM interrupts)
在PHP 7.0之前，執行超時用于直接從信號處理程序通過longjump處理關閉序列。如你所想，這引起了各種不愉快的事情。由于PHP 7.0超時被延遲，直到控制權返回到虛擬機。如果它在特定的寬限期內沒有返回，則該過程被中止。由于PHP 7.1 pcntl信號處理程序使用與執行超時相同的機制。
當一個信號掛起時，VM中斷標志被設置，并且這個標志由虛擬機在某些點檢查。檢查不是在每條指令上執行，而是僅在跳轉和調用時執行。因此，在返回到VM時不會立即處理中斷，而是在線性控制流的當前部分結束時處理。
特殊化(Specialization)
如果查看VM定義文件，會發現操作碼處理程序定義如下：
ZEND_VM_HANDLER(1, ZEND_ADD, CONST|TMPVAR|CV, CONST|TMPVAR|CV)
1在這里是操作碼數，ZEND_ADD它的名字，而另外兩個參數指定指令接受哪些類型的操作。所述生成的虛擬機代碼(由生成zend_vm_gen.php然后)將包含為每個可能的操作數類型的組合的專門處理程序。生成有像ZEND_ADD_SPEC_CONST_CONST_HANDLER這樣的名稱。
專用處理程序是通過替換處理程序主體中的某些宏來生成的。比較容易看出的是OP1_TYPE和OP2_TYPE，但諸如GET_OP1_ZVAL_PTR()和FREE_OP1()等操作也是專用的。
ADD的處理程序指定它接受CONST|TMPVAR|CV操作數。這里的TMPVAR意味著操作碼同時接受TMP和VAR，但要求這些不是單獨專用的。請記住，對于大多數用途而言，TMP和VAR之間的唯一區別是后者可以包含引用。對于像ADD這樣的操作碼(無論如何，引用都在慢速路徑(slow-path)上)，單獨進行特殊化并不值得。一些其他操作碼確實可以區分TMP|VAR它們的操作數列表。
除了基于操作數類型的特殊化之外，處理程序還可以專門處理其他因素，例如是否使用其返回值。ASSIGN_DIM基于以下OP_DATA操作碼的操作數類型進行特殊化：
ZEND_VM_HANDLER(147, ZEND_ASSIGN_DIM,
VAR|CV, CONST|TMPVAR|UNUSED|NEXT|CV, SPEC(OP_DATA=CONST|TMP|VAR|CV))
根據此簽名，將生成244=32個不同的ASSIGN_DIM變體。第二個操作數的規范也包含一個條目NEXT。這與特殊化無關，而是指定了UNUSED操作數在此上下文中的含義：它表示這是一個附加操作($arr[])。另一個例子：
ZEND_VM_HANDLER(23, ZEND_ASSIGN_ADD,
VAR|UNUSED|THIS|CV, CONST|TMPVAR|UNUSED|NEXT|CV, DIM_OBJ, SPEC(DIM_OBJ))
在這里我們已經知道第一個操作數是UNUSED意味著一個訪問$this。這是與對象有關的操作碼的一般慣例，例如FETCH_OBJ_R UNUSED,'prop'對應于$this->prop。未使用的第二個操作數也意味著附加操作。這里的第三個參數指定的extended_value數的含義：它包含區分的標志$a += 1，$a[$b] += 1和$a->b += 1。最后，SPEC(DIM_OBJ)指示應該為每一個生成一個專門的處理程序。(在這種情況下，將生成的總處理程序數量并不重要，因為VM生成器知道某些組合是不可能的，例如UNUSED op1只與OBJ情況相關，等等)
最后，虛擬機生成器還支持更復雜的特殊化機制。在定義文件的末尾，你會發現一些這種形式的處理程序：
ZEND_VM_TYPE_SPEC_HANDLER(
ZEND_ADD,
(res_info == MAY_BE_LONG && op1_info == MAY_BE_LONG && op2_info == MAY_BE_LONG),
ZEND_ADD_LONG_NO_OVERFLOW,
CONST|TMPVARCV, CONST|TMPVARCV, SPEC(NO_CONST_CONST,COMMUTATIVE)
)
這些處理程序不僅基于VM操作數類型，還基于操作數在運行時可能采用的可能類型。確定可能的操作數類型的機制是opcache優化基礎結構的一部分，這超出了本文的范圍。但是，假設這些信息可用，應該清楚這是int + int -> int一個附加的形式。此外，SPEC注釋告訴specilizer，不應該生成兩個const操作數的變體，并且操作是可交換的，所以如果我們已經有了CONST + TMPVARCV特殊化，我們也不需要生成TMPVARCV + CONST。
快速路徑/慢速路徑分割(Fast-path / slow-path split)
許多操作碼處理程序都是使用快速路徑/慢速路徑分割來實現的，其中首先處理幾個常見情況，然后再回到通用實現。這是關于我們查看一些實際代碼的時間了，所以我將在這里粘貼整個SL(左移)實現：
ZEND_VM_HANDLER(6, ZEND_SL, CONST|TMPVAR|CV, CONST|TMPVAR|CV)
{
USE_OPLINE
zend_free_op free_op1, free_op2;
zval *op1, *op2;
op1 = GET_OP1_ZVAL_PTR_UNDEF(BP_VAR_R);
op2 = GET_OP2_ZVAL_PTR_UNDEF(BP_VAR_R);
if (EXPECTED(Z_TYPE_INFO_P(op1) == IS_LONG)
&& EXPECTED(Z_TYPE_INFO_P(op2) == IS_LONG)
&& EXPECTED((zend_ulong)Z_LVAL_P(op2) < SIZEOF_ZEND_LONG * 8)) {
ZVAL_LONG(EX_VAR(opline->result.var), Z_LVAL_P(op1) << Z_LVAL_P(op2));
ZEND_VM_NEXT_OPCODE();
}
SAVE_OPLINE();
if (OP1_TYPE == IS_CV && UNEXPECTED(Z_TYPE_INFO_P(op1) == IS_UNDEF)) {
op1 = GET_OP1_UNDEF_CV(op1, BP_VAR_R);
}
if (OP2_TYPE == IS_CV && UNEXPECTED(Z_TYPE_INFO_P(op2) == IS_UNDEF)) {
op2 = GET_OP2_UNDEF_CV(op2, BP_VAR_R);
}
shift_left_function(EX_VAR(opline->result.var), op1, op2);
FREE_OP1();
FREE_OP2();
ZEND_VM_NEXT_OPCODE_CHECK_EXCEPTION();
}
該實現通過GET_OPn_ZVAL_PTR_UNDEF以BP_VAR_R模式獲取操作數開始。UNDEF這里的部分意味著在CV情況下不執行未定義變量的檢查，而只是按照原樣返回UNDEF值。一旦我們有操作數，我們檢查兩者是否都是整數，并且移位寬度在范圍內，在這種情況下，結果可以直接計算出來，并且我們前進到下一個操作碼。值得注意的是，這里的類型檢查并不關心操作數是否為UNDEF，所以使用GET_OPN_ZVAL_PTR_UNDEF是合理的。
如果操作數不能滿足快速路徑，我們回到通用實現，該實現以SAVE_OPLINE()開始。這是我們的信號“潛在的投擲操作”。在繼續之前，處理未定義變量的情況。在這種情況下，GET_OPn_UNDEF_CV將發出未定義的變量通知并返回NULL值。
接下來，調用通用shift_left_function并將其結果寫入EX_VAR(opline->result.var)。最后，輸入操作數被釋放(如果需要)，并且我們前進到具有異常檢查的下一個操作碼(這意味著在前進之前重新裝入操作數)。
因此，這里的快速路徑保存了未定義變量的兩個檢查，對通用運算符函數的調用，釋放操作數，以及保存和重新加載opline以進行異常處理。大部分性能敏感的操作碼都以相似的方式排列。
VM宏(VM macros)
從前面的代碼清單可以看出，虛擬機實現可以自由使用宏。其中一些是普通的C宏，而另一些則是在生成虛擬機時解決的。特別是，這包括許多用于獲取和釋放指令操作數的宏：
OPn_TYPE
OP_DATA_TYPE
GET_OPn_ZVAL_PTR(BP_VAR_*)
GET_OPn_ZVAL_PTR_DEREF(BP_VAR_*)
GET_OPn_ZVAL_PTR_UNDEF(BP_VAR_*)
GET_OPn_ZVAL_PTR_PTR(BP_VAR_*)
GET_OPn_ZVAL_PTR_PTR_UNDEF(BP_VAR_*)
GET_OPn_OBJ_ZVAL_PTR(BP_VAR_*)
GET_OPn_OBJ_ZVAL_PTR_UNDEF(BP_VAR_*)
GET_OPn_OBJ_ZVAL_PTR_DEREF(BP_VAR_*)
GET_OPn_OBJ_ZVAL_PTR_PTR(BP_VAR_*)
GET_OPn_OBJ_ZVAL_PTR_PTR_UNDEF(BP_VAR_*)
GET_OP_DATA_ZVAL_PTR()
GET_OP_DATA_ZVAL_PTR_DEREF()
FREE_OPn()
FREE_OPn_IF_VAR()
FREE_OPn_VAR_PTR()
FREE_UNFETCHED_OPn()
FREE_OP_DATA()
FREE_UNFETCHED_OP_DATA()
可以看到，這里有不少變化。該BP_VAR_*參數指定的提取模式并支持相同的模式作為FETCH_ *(與FUNC_ARG除外)的說明。
GET_OPn_ZVAL_PTR()是基本的操作數獲取。它會在未定義的CV上發出通知，并且不會取消操作數的取消引用。GET_OPn_ZVAL_PTR_UNDEF()正如我們已經知道的那樣，它是一種不檢查未定義的CV的變體。 GET_OPn_ZVAL_PTR_DEREF()包括zval的DEREF。這是專門的GET操作的一部分，因為解引用僅對于CV和VAR是必需的，但對于CONST和TMP不是必需的。因為這個宏需要區分TMP和VAR，它只能用于TMP|VAR專業化(但不能TMPVAR)。
這些GET_OPn_OBJ_ZVAL_PTR*()變體還處理UNUSED操作數的情況。如前所述，通過約定$this訪問使用UNUSED操作數，所以GET_OPn_OBJ_ZVAL_PTR*()宏將返回EX(This)對UNUSED操作的引用。
最后，還有一些PTR_PTR變體。這里的命名是來自PHP5，其中這實際上使用了雙向的zval指針。這些宏用于寫操作，因此僅支持CV和VAR類型(其他任何返回NULL)。它們與正常的PTR提取不同，因為它們取消了VAR操作數。
這些FREE_OP*()宏然后用來釋放取出的操作數。要進行操作，它們需要定義一個zend_free_op free_opN變量，GET操作將該 變量存儲到該變量中以釋放。基線FREE_OPn()操作將釋放TMP和VAR，但不會釋放CV和CONST。FREE_OPn_IF_VAR()完全按照它的說法：只有當它是VAR時才釋放操作數。
該FREE_OP*_VAR_PTR()變體與PTR_PTR提取結合使用。它只會釋放VAR操作數，并且只有在它們不是INDIRECTed的時候。
FREE_UNFETCHED_OP*()在使用GET獲取操作數之前必須釋放操作數的情況下使用這些變體。如果在操作數提取之前拋出異常，通常會發生這種情況。
除了這些特殊的宏之外，還有一些比較普通的宏。虛擬機定義了三個宏來控制操作碼處理程序運行后發生的情況：
ZEND_VM_CONTINUE()
ZEND_VM_ENTER()
ZEND_VM_LEAVE()
ZEND_VM_RETURN()
CONTINUE將繼續正常執行操作碼，而ENTER和LEAVE則用于進入/離開嵌套函數調用。這些操作的具體細節取決于VM編譯的精確程度(例如，是否使用全局寄存器，如果是，使用哪一個)。從廣義上講，這些將在繼續之前同步一些狀態。RETURN用于實際退出主VM環路。
ZEND_VM_CONTINUE()期望事先更新opline。當然，還有更多的宏相關：
-
Continue?
Check exception?
Check interrupt?
ZEND_VM_NEXT_OPCODE()
yes
no
no
ZEND_VM_NEXT_OPCODE_CHECK_EXCEPTION()
yes
yes
no
ZEND_VM_SET_NEXT_OPCODE(op)
no
no
no
ZEND_VM_SET_OPCODE(op)
no
no
yes
ZEND_VM_SET_RELATIVE_OPCODE(op, offset)
no
no
yes
ZEND_VM_JMP(op)
yes
yes
yes
該表顯示宏是否包含隱式ZEND_VM_CONTINUE()，是否會檢查異常以及是否檢查VM中斷。
除此之外，還有SAVE_OPLINE()，LOAD_OPLINE()和HANDLE_EXCEPTION()。正如在異常處理一節中所提到的，SAVE_OPLINE()在操作碼處理程序中的第一個可能的拋出操作之前使用。如有必要，它將VM(可能位于全局寄存器中)使用的opline寫回到執行數據中。LOAD_OPLINE()是相反的操作，但現在它幾乎沒有用處，因為它已被有效地轉入ZEND_VM_NEXT_OPCODE_CHECK_EXCEPTION()和ZEND_VM_JMP()。
HANDLE_EXCEPTION()用于在已經知道引發異常后從操作碼處理程序返回。它執行LOAD_OPLINE和CONTINUE的組合，這將有效地分派到HANDLE_EXCEPTION操作碼。
當然，還有更多的宏，但以上應該已經包含了最重要的部分。
總結
以上是生活随笔為你收集整理的php 虚拟机速度慢,[译]PHP虚拟机（PHP Virtual Machine）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： urllib库用POST请求模仿有道在线
- 下一篇： php 操作 腾讯企业邮箱设置发邮件,纯