標(biāo)簽： PHP

本篇文章旨在提供一個對PHP7版本中Zend虛擬機的概述，不會做到面面俱到的詳細敘述椭更，但盡力包含大多數(shù)重要的部分哪审，以及更精細的細節(jié)。

這篇文章描述的主要背景是PHP版本7.2（當(dāng)前正在開發(fā)版本）虑瀑，但幾乎同樣適用于PHP7.0/7.1版本中湿滓。然而滴须，PHP5.x系列版本的虛擬機之間差別比較顯著，筆者不會去比較叽奥。

本文的大部分內(nèi)容將在指令列表級別進行考慮扔水，最后只有幾節(jié)討論VM的實際C語言實現(xiàn)。但是朝氓，我確實想提供一些組成VM前端的主要文件：

• zend_vm_def.h：VM定義文件
• zend_vm_execute.h：生成的虛擬機文件
• zend_vm_gen.php：生成腳本
• zend_execute.c：大多數(shù)直接支持文件

操作碼 （Opcodes）

首先我們來談一下操作碼魔市，“操作碼”是指完整的VM指令(包括操作數(shù))，但也可以只指定“實際”操作代碼--一個決定指令類型的小整數(shù)赵哲。從上下文來看待德，指令的意圖應(yīng)該是清晰的。在文件源碼中枫夺，完整的指令通常被稱為Opline将宪。

一個獨立的指令遵循如下zend_op結(jié)構(gòu)體：

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;
};

如上，操作碼實質(zhì)上是“三地址”指令格式橡庞。其中‘opcode’決定指令類型涧偷，還有兩個輸入的操作數(shù)‘op1’和‘op2’以及一個輸出操作數(shù)‘result’。

并不是所有的指令都會用到所有的操作數(shù)毙死。ADD指令（代表+操作符）會用到三個操作數(shù)燎潮。BOOL_NOT指令（代表！操作符）只用到op1和result扼倘。ECHO指令只會用到op1操作符确封。有些指令甚至可以使用或者不使用操作符。例如再菊，DO_FCALL可以使用或者不使用result操作符爪喘，具體取決于是否使用函數(shù)調(diào)用的返回值。有些指令需要兩個以上輸入操作數(shù)纠拔，在這種情況下秉剑，只需要使用第二個虛擬指令/偽指令（OP_DATA）來攜帶額外的操作數(shù)。

除了這三個標(biāo)準(zhǔn)操作數(shù)之外稠诲，還有一個附加的數(shù)值extended_value 字段侦鹏，可以用來保存附加的指令修飾符。例如臀叙，對于強制轉(zhuǎn)換（CAST）略水，它可能包含要強制轉(zhuǎn)換的目標(biāo)類型。

每個操作數(shù)都有對應(yīng)的一個類型劝萤，分別存儲在op1_type, op2_type和result_type中渊涝。可能的類型有IS_UNUSED, IS_CONST, IS_TMPVAR, IS_VAR and IS_CV。

后三種類型指定變量操作數(shù)(有三種不同類型的VM變量)跨释，IS_CONST表示常量操作數(shù)(5或“String”或偶數(shù)[1胸私，2，3])鳖谈，而IS_UNUSED表示實際未使用的操作數(shù)岁疼，或作為32位數(shù)值(匯編術(shù)語中的“立即”)使用的操作數(shù)。例如蚯姆，跳轉(zhuǎn)指令將跳轉(zhuǎn)目標(biāo)存儲在未使用的操作數(shù)中五续。

獲取操作指令（Obtaining opcode dumps)

接下來，筆者將經(jīng)常列出PHP代碼生成的操作碼序列龄恋。目前有三種方法可以將這些操作碼轉(zhuǎn)儲：

# 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提供了最高質(zhì)量的輸出。本文中使用的清單基于opcache轉(zhuǎn)儲郭毕，并進行了一些語法調(diào)整它碎。魔術(shù)數(shù)字0x10000是“優(yōu)化前”的縮寫，因此我們看到PHP編譯器生成的操作碼显押。0x20000會給你優(yōu)化的操作碼扳肛。Opcache還可以生成更多的信息，例如0x40000將生成一個CFG乘碑，而0x200000將生成類型和范圍推斷的SSA表單挖息。但這已經(jīng)超越了我們想要的：普通的、原本的線性化操作碼轉(zhuǎn)儲對我們來說就足夠了兽肤。

變量類型（Variable types）

在研究虛擬機時套腹，可能需要理解的最重要的一點在于它使用的三種不同的變量類型：
CV是“compiled variable”的縮寫，而且指向一個“真正的”PHP變量资铡。如果函數(shù)使用變量$a电禀，就會有$a對應(yīng)的CV。

CV可以有UNDEF類型笤休，用來指向未定義變量尖飞。如果UNDEF CV在一個指令中用到，在大多數(shù)情況下會拋出“未定義變量（undefined variable）”提示店雅。在函數(shù)入口處所有非參數(shù)CV會被初始化為UNDEF政基。

CV不會被指令消耗(consumed)，例如底洗，指令A(yù)DD $a,$b 不會銷毀存儲在CV中的變量$a和$b腋么。然而所有的CV都會在事務(wù)(scope)退出時一起銷毀。這也暗示所有的CV在整個函數(shù)的域內(nèi)都將‘live’--包含一個有效值亥揖。

TMPVARS和VARS是虛擬機的臨時變量。它們通常被用作一些操作指令的結(jié)果操作數(shù)。例如$a = $b + $c + $d會輸出如下類似指令序列：

T0 = ADD $b,$c
T1 = ADD T0,$d
ASSIGN $a,T1

TMP/VAR是在使用前定義的费变，因此不能保存UNDEF值摧扇。與CV不同，這些變量類型是由它們所使用的指令所消耗的挚歧。在上面的示例中扛稽，第二個ADD將破壞T0操作數(shù)的值，在此之后不能使用T0(除非事先寫入)滑负。類似地在张，ASSIGN將消耗T1的值，使T1無效矮慕。

因此帮匾，TMP/VAR通常壽命很短。在許多情況下痴鳄，一個臨時變量只存在一個指令的空間瘟斜。在這個短暫的活動之外，臨時變量就成了垃圾痪寻。

那么TMP和VAR有什么區(qū)別呢螺句？不多。這種區(qū)別是從PHP5繼承的橡类，TMP是分配在VM棧中的蛇尚，而VAR是分配在堆中的。在PHP7中顾画，所有變量都是分配在棧中取劫。因此，現(xiàn)在TMP和VAR的主要區(qū)別是只允許后者包含引用(REFERENCEs)(這允許我們在TMP上刪除DEREF)亲雪。此外勇凭，VAR可能包含兩種特殊值，即類條目(class entries)和間接值(INDIRECT values)义辕。后者用于處理特殊的任務(wù)虾标。

下方圖表分析了主要的區(qū)別：

指令數(shù)組（Op arrays）

所有PHP函數(shù)都表示為具有公共Zend_Function的 Header結(jié)構(gòu)。這里的“函數(shù)”應(yīng)該有一些廣義的理解灌砖，包括從“真正的”函數(shù)到方法璧函，到獨立的“偽主(pseudo-main)”代碼和“eval”代碼。

用戶級函數(shù)使用zend_op_Array結(jié)構(gòu)基显。它有30多個成員蘸吓，所以我現(xiàn)在先從一個簡化版本開始：

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;
    /* ... */
};

最重要的部分當(dāng)然是opcodes，它是一個包含操作指令的數(shù)組撩幽】饧蹋‘last’是數(shù)組中操作指令的數(shù)量箩艺，注意這里的術(shù)語可能令人感到困惑，‘last’看起來像是最后一個操作指令的索引宪萄，但是這里實際上是操作數(shù)的數(shù)量（比最后一個操作數(shù)的索引大一）艺谆。這同樣適用于op數(shù)組結(jié)構(gòu)中的所有其他‘last_ *’值。

‘last_var’是CV的數(shù)量拜英，‘T’是TMP和VAR的數(shù)量（在大多數(shù)情況下兩者沒有明顯的區(qū)別）静汤。‘vars’是CV的命名居凶。
‘literals’是出現(xiàn)在代碼中字面值的數(shù)組虫给，這個數(shù)組是CONST操作數(shù)引用。根據(jù)ABI①侠碧，每個CONST操作數(shù)要么儲存指向次文本表的引用抹估，要么存儲相對于其開始的偏移量。

關(guān)于op數(shù)組（op array）的內(nèi)容不止于此舆床。

椘灏觯框架布局（Stack frame layout）

除了一些全局指令EG(excutor globals)，所有的執(zhí)行狀態(tài)都存儲在虛擬機棧中挨队。虛擬機棧以大小為256KB的page分配谷暮，通過鏈表進行連接。

每一個函數(shù)調(diào)用時盛垦，將在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結(jié)構(gòu)開始，接著是一個變量槽（variable slots）的數(shù)組腾夯。這些變量槽都相同（simple zvals）颊埃，但是用作不同的用途。第一個‘last_var’槽中內(nèi)容是CV蝶俱，其中第一個num_args存放函數(shù)參數(shù)班利。CV插槽之后是TMP/ VAR的‘T’插槽。最后榨呆，有時可以在幀的末尾存儲“額外”參數(shù)罗标。這些用于處理func_get_args()。

指令中的CV和TMP/VAR操作數(shù)被編碼為相對于堆棧起始位置的偏移量积蜻，因此讀取某個變量只是從execute_data位置讀取的偏移量闯割。

幀開始處的執(zhí)行數(shù)據(jù)定義如下：

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       */
};

最重要的是，這個結(jié)構(gòu)包含opline（當(dāng)前執(zhí)行的指令）和func（它是當(dāng)前執(zhí)行的函數(shù)）竿拆。此外：

• return_value是一個指向?qū)⒋鎯Ψ祷刂档膠val的指針宙拉。
• ‘This’是$this對象，但也會編碼一些未使用的zval空間中函數(shù)參數(shù)的數(shù)目和一些調(diào)用元數(shù)據(jù)標(biāo)志丙笋。
• called_scope是static ::在PHP代碼中引用的范圍谢澈。
• prev_execute_data指向前一個棧幀煌贴，在此函數(shù)完成運行后，執(zhí)行將返回到該幀澳化。
• symbol_table是一個通常未使用的符號表崔步，用于某些瘋狂的人實際使用變量變量或類似功能的情況稳吮。（$$a）
• run_time_cache緩存op數(shù)組運行時緩存缎谷，以便在訪問此結(jié)構(gòu)時避免一個指針間接尋址（稍后討論）。
• 由于相同的原因灶似，literals緩存op數(shù)組字面量表列林。

函數(shù)調(diào)用（Function calls）

筆者跳過了execute_data結(jié)構(gòu)中的一個字段--‘call'，因為它需要關(guān)于函數(shù)調(diào)用如何工作的更多上下文酪惭。所有調(diào)用都使用相同指令序列的變體希痴。全局作用域中的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指令春感，取決于它是什么類型的調(diào)用砌创。INIT_FCALL與調(diào)用相關(guān)，用來釋放我們在編譯時識別的函數(shù)鲫懒。同樣嫩实，根據(jù)參數(shù)和函數(shù)的類型，有十個不同的SEND操作碼窥岩。只有數(shù)量較少的四個DO_CALL操作碼甲献，其中ICALL用于調(diào)用內(nèi)部函數(shù)。

雖然具體指令可能不同颂翼，但結(jié)構(gòu)總是相同的：INIT晃洒，SEND，DO朦乏。調(diào)用序列必須解決的主要問題是嵌套函數(shù)調(diào)用球及，它們編譯如下所示：

# 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操作碼在堆棧上壓入一個調(diào)用幀，該幀包含了函數(shù)中所有變量的足夠空間以及我們所知道的參數(shù)的數(shù)量（如果涉及參數(shù)解包呻疹，我們可能會以更多參數(shù)結(jié)束）吃引。

指向新幀的指針存儲到execute_data-> call中，其中execute_data是調(diào)用函數(shù)的幀诲宇。在下面际歼，我們將把這些訪問表示為EX（call）。值得注意的是姑蓝，新幀的prev_execute_data被設(shè)置為舊的EX（call）值鹅心。例如，調(diào)用foo的INIT_FCALL會將prev_execute_data設(shè)置為va_dump的堆棧幀（而不是周邊函數(shù)的棧幀）纺荧。因此旭愧，在這種情況下颅筋，prev_execute_data形成一個“未完成”調(diào)用的鏈表，而通常它會提供回溯鏈(雙向鏈表)输枯。

SEND操作碼然后繼續(xù)將參數(shù)推送到EX（call）的變量槽中议泵。在這一點上，參數(shù)都是連續(xù)的桃熄，并且可以從為參數(shù)指定的部分溢出到其他CV或TMP中先口。這將在稍后修復(fù)。

最后DO_FCALL執(zhí)行實際的調(diào)用瞳收。EX（call）成為當(dāng)前函數(shù)碉京，prev_execute_data被重新鏈接到調(diào)用函數(shù)。除此之外螟深，調(diào)用過程取決于它是什么類型的功能谐宙。內(nèi)部函數(shù)只需要調(diào)用處理函數(shù)，而用戶級函數(shù)需要完成棧幀的初始化界弧。

這個初始化涉及修復(fù)參數(shù)棧凡蜻。PHP允許傳遞比函數(shù)期望更多的參數(shù)（func_get_args依賴于這個功能）。但是垢箕，只有實際聲明的參數(shù)才具有相應(yīng)的CV划栓。除此以外的任何參數(shù)都會寫入為其他CV和TMP保留的內(nèi)存。因此舰讹，這些參數(shù)將在TMP之后移動茅姜，最終將參數(shù)分成兩個不連續(xù)的塊。

為了清楚地說明月匣，用戶級函數(shù)調(diào)用不涉及虛擬機級別的遞歸钻洒。它們只涉及從一個execute_data切換到另一個execute_data，但虛擬機繼續(xù)以線性循環(huán)運行锄开。遞歸虛擬機調(diào)用僅在內(nèi)部函數(shù)調(diào)用用戶空間回調(diào)（例如通過array_map）時才會發(fā)生素标。這就是為什么PHP中的無限遞歸通常會導(dǎo)致內(nèi)存限制或OOM錯誤的原因，通過遞歸使用回調(diào)函數(shù)或魔術(shù)方法可能引發(fā)棧溢出萍悴。

參數(shù)傳遞（Argument sending）

PHP使用大量不同的參數(shù)發(fā)送操作碼头遭，這些操作碼的區(qū)別可能會造成混淆。
SEND_VAL和SEND_VAR是最簡單的變體癣诱，它處理在編譯時已知是按值傳遞時進行的按值傳遞參數(shù)计维。SEND_VAL用于CONST和TMP操作數(shù)，而SEND_VAR用于VAR和CV。

相反，SEND_REF用于在編譯期間已知為引用傳遞的參數(shù)傳遞支子。由于只有變量可以通過引用發(fā)送兴垦，這個操作碼只接受VAR和CV。

SEND_VAL_EX和SEND_VAR_EX是SEND_VAL / SEND_VAR的變體爬早，用于無法靜態(tài)確定參數(shù)是按值還是按引用傳遞的情況黄鳍。這些操作碼將根據(jù)arginfo檢查參數(shù)的種類并相應(yīng)地執(zhí)行操作关串。在大多數(shù)情況下赏淌，不使用實際的arginfo結(jié)構(gòu)踩寇，而是直接在函數(shù)結(jié)構(gòu)中使用緊湊的位向量表示。

然后是SEND_VAR_NO_REF_EX六水。不要試圖名稱上了解這個指令俺孙。這個操作碼用于傳遞一些不是真正的“變量”，但是會返回一個VAR到一個靜態(tài)未知參數(shù)的東西缩擂。使用它的兩個特定示例是將函數(shù)調(diào)用的結(jié)果作為參數(shù)傳遞鼠冕，或者傳遞賦值的結(jié)果。②

這種情況需要一個獨立的操作碼胯盯，原因有兩個：首先，如果嘗試通過ref傳遞類似于賦值的內(nèi)容它會生成熟悉的“只能通過引用傳遞變量”通知（如果使用SEND_VAR_EX计露，則會被默許）博脑。其次，這個操作碼處理的情況是票罐，你可能想要將引用返回函數(shù)的結(jié)果傳遞給一個引用參數(shù)（它不應(yīng)該拋出任何東西）叉趣。該操作碼的SEND_VAR_NO_REF變體（不帶_EX）是一種特殊的變體，用于靜態(tài)地知道引用是預(yù)期的情況（但我們不知道該變量是否為一個）该押。

SEND_UNPACK和SEND_ARRAY操作碼分別處理參數(shù)解包和內(nèi)聯(lián)call_user_func_array調(diào)用疗杉。它們都將數(shù)組中的元素推入?yún)?shù)棧，并在各種細節(jié)上有所不同（例如蚕礼，解包支持Traversables烟具，而call_user_func_array則不支持）。如果使用unpacking/cufa奠蹬，則可能需要將棾框架擴展超出其以前的大小（因為函數(shù)參數(shù)的實數(shù)在初始化時是未知的）囤躁。在大多數(shù)情況下冀痕，只需移動堆棧頂部指針就可以進行擴展。但是狸演，如果這會跨越堆棧頁面邊界言蛇，則必須分配新頁面，并且需要將整個調(diào)用幀（包括已經(jīng)推入的參數(shù)）復(fù)制到新頁面（我們無法處理穿過頁面的調(diào)用幀邊界）宵距。

最后一個操作碼是SEND_USER腊尚，用于內(nèi)聯(lián)調(diào)用call_user_func并處理它的一些特性。

雖然我們尚未討論不同的變量獲取模式消玄，但這似乎是介紹FUNC_ARG獲取模式的好地方跟伏《撸考慮一個簡單的調(diào)用func($a[0][1][2])，在編譯時我們不知道這個參數(shù)是通過值還是通過引用傳遞的受扳。在這兩種情況下携龟，行為將會大不相同。如果傳遞是按值并且$a以前是空的勘高，則可能必須生成一堆“未定義索引”通知峡蟋。如果傳遞是通過引用的話，我們必須默默地初始化嵌套數(shù)組华望。

FUNC_ARG獲取模式將通過檢查當(dāng)前EX(call)函數(shù)的arginfo來動態(tài)選擇兩種行為之一（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

我們已經(jīng)知道，_FUNC_ARG根據(jù)函數(shù)參數(shù)是按值還是按引用來選擇_R和_W宾抓。讓我們嘗試創(chuàng)建一些我們期望不同的獲取類型出現(xiàn)的情況：

// $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)

不幸的是子漩，這個產(chǎn)生的唯一真正的提取是FETCH_DIM_R：其他的東西都是通過特殊的操作碼處理的。請注意石洗，ASSIGN_DIM和ASSIGN_ADD都使用額外的OP_DATA幢泼，因為它們需要兩個以上的輸入操作數(shù)。使用特殊操作碼（如ASSIGN_DIM）而不是像FETCH_DIM_W + ASSIGN之類的原因是（除了性能）讲衫，這些操作可能被重載缕棵，例如，在ASSIGN_DIM情況下涉兽，通過實現(xiàn)ArrayAccess::offsetSet()的對象實現(xiàn)招驴。要實際生成不同的提取類型，我們需要增加嵌套的級別：

// $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)

在這里我們看到花椭，盡管最外層的訪問使用專用的操作碼忽匈，嵌套的索引將使用具有適當(dāng)獲取模式的FETCH進行處理。fetch模式的基本區(qū)別在于a）如果索引不存在矿辽，它們是否生成“未定義偏移量”通知丹允，以及它們是否獲取寫入值：

UNSET的情況有點奇怪，因為它只能讀取現(xiàn)有的偏移量以便寫入袋倔，并且保留單獨的未定義的偏移量雕蔽。正常的寫取操作會初始化未定義的偏移量。

寫和內(nèi)存安全（Writes and memory safety）

Write獲取可能包含正常zval或指向另一個zval的INDIRECT指針的返回VAR宾娜。當(dāng)然批狐，在前一種情況下，應(yīng)用于zval的任何更改都將不可見，因為該值只能通過虛擬機暫時訪問嚣艇。雖然PHP禁止表達[][0] = 42承冰，但我們?nèi)匀恍枰幚磉@種情況 call()[0] = 42。取決于是call()按值還是按引用返回食零，此表達式可能會或可能不會有顯著效果困乒。

更典型的情況是當(dāng)提取返回一個INDIRECT時，它包含一個指向正在被修改的存儲位置的指針贰谣，例如哈希表數(shù)據(jù)數(shù)組中的某個位置娜搂。不幸的是，這樣的指針是脆弱的東西吱抚，容易失效：任何并發(fā)寫入數(shù)組可能會觸發(fā)重新分配百宇，留下一個懸掛指針。因此秘豹，防止在創(chuàng)建INDIRECT值的位置與消耗的位置之間執(zhí)行用戶代碼至關(guān)重要携御。

考慮這個例子：
$arr[a()][b()] = c();
其中產(chǎn)生：

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

值得注意的是，這個序列首先執(zhí)行從左到右的所有內(nèi)嵌函數(shù)憋肖，然后才執(zhí)行任何必要的寫入讀纫蛲础（我們在此將FETCH_DIM_W稱為“延遲opline”）。這確保了寫訪存和消費指令直接相鄰岸更。

考慮另一個例子：

$arr[0] =& $arr[1];

這里我們遇到了一些問題：兩邊的復(fù)制必須提取值才能寫入。但是膊升，如果我們抓取$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]先取得寫入廓译，然后轉(zhuǎn)換成使用MAKE_REF的引用评肆。MAKE_REF的結(jié)果不再是間接的并且不會失效，因為這樣的獲取$arr[0]可以安全地執(zhí)行非区。

異常處理（Exception handling）

異常是萬惡之源瓜挽。

異常是通過將異常寫入EG(異常)來生成的，其中EG指的是執(zhí)行者全局(Executor Globals)征绸。C代碼中拋出異常不涉及堆棧展開久橙，相反，執(zhí)行退出（abortion）將通過返回值失敗代碼或檢查EG(異常)向上傳播管怠。只有當(dāng)控制器重新進入虛擬機代碼時淆衷，才會實際處理異常。

在某些情況下渤弛，幾乎所有的VM指令都可能直接或間接導(dǎo)致異常祝拯。例如，如果使用自定義錯誤處理程序她肯，則任何“未定義的變量”通知都可能導(dǎo)致異常佳头。我們希望避免檢查EG(exception)每個VM指令后設(shè)置鹰贵。相反，使用一個小竅門：

當(dāng)拋出一個異常時康嘉，當(dāng)前執(zhí)行數(shù)據(jù)的當(dāng)前選擇行被替換為虛擬HANDLE_EXCEPTION opline（這顯然不會修改op數(shù)組碉输，它只是重定向一個指針）。備份發(fā)生異常的對象EG(opline_before_exception)凄鼻。

這意味著當(dāng)控制返回到主虛擬機調(diào)度循環(huán)時腊瑟，將調(diào)用HANDLE_EXCEPTION操作碼。這個方案存在一個小問題：它要求 a)存儲在執(zhí)行數(shù)據(jù)中的opline實際上是當(dāng)前執(zhí)行的opline（否則opline_before_exception將會是錯誤的）并且 b)虛擬機使用來自執(zhí)行數(shù)據(jù)的opline來繼續(xù)執(zhí)行（否則HANDLE_EXCEPTION不會被調(diào)用）块蚌。

雖然這些要求可能聽起來微不足道闰非，但它們不是。原因是虛擬機可能正在處理與執(zhí)行數(shù)據(jù)中存儲的opline不同步opline變量峭范。在PHP 7之前财松，這只發(fā)生在很少使用的GOTO和SWITCH虛擬機中，而在PHP 7中纱控，這實際上是默認的操作模式：如果編譯器支持它辆毡，則opline存儲在全局寄存器中。

因此甜害，在執(zhí)行任何可能會拋出的操作之前舶掖，必須將本地對齊線寫回執(zhí)行數(shù)據(jù)（SAVE_OPLINE操作）。同樣尔店，在任何可能的拋出操作之后眨攘，必須從執(zhí)行數(shù)據(jù)填充本地對象（主要是CHECK_EXCEPTION操作）。

現(xiàn)在嚣州，這個機制是在引發(fā)異常之后導(dǎo)致HANDLE_EXCEPTION操作碼執(zhí)行的原因鲫售。但它有什么作用？首先该肴，它確定是否在try塊內(nèi)引發(fā)異常情竹。為此，op數(shù)組包含一個try_catch_elements數(shù)組匀哄，用于跟蹤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;

現(xiàn)在我們會假裝最后的塊不存在，因為它們是一個完全不同的拱雏。假設(shè)我們確實在try塊內(nèi)棉安，VM需要清理在拋出opline之前開始的所有未完成的操作，并且不會跨越try塊的末尾铸抑。

這涉及釋放當(dāng)前在使用中的所有調(diào)用的棧幀和相關(guān)數(shù)據(jù)贡耽，以及釋放臨時變量。在大多數(shù)情況下，臨時變量存在時間很短蒲赂，甚至達到消費指令直接跟隨著生成指令阱冶。然而，它可能發(fā)生在跨越多個指令的現(xiàn)場：

# (array)[] + throwing()
L0:   T0 = CAST (array) []
L1:   INIT_FCALL (0 args) "throwing"
L2:   V1 = DO_FCALL
L3:   T2 = ADD T0, V1

在這種情況下滥嘴，T0變量在指令L1和L2中是活動的木蹬，因此如果函數(shù)調(diào)用拋出時需要銷毀T0變量。一種特定的臨時類型往往具有特別長的活動范圍：循環(huán)變量若皱。例如：

# 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

這里“循環(huán)變量”V0從L1到L3（通衬魅總是跨越整個循環(huán)體）。實時范圍使用以下結(jié)構(gòu)存儲在操作數(shù)組中：

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是范圍適用的（操作數(shù)編碼的）變量走触，start是開始選擇線偏移量（不包括生成指令）晦譬，而end如果結(jié)束選擇線偏移量（包括消耗指令）。當(dāng)然互广，如果暫時沒有立即消耗敛腌，則僅存儲活動范圍。

低位var用于存儲變量的類型惫皱，可以是以下之一：

• ZEND_LIVE_TMPVAR：這是一個“正诚穹”變量。它擁有一個普通的zval值旅敷。釋放這個變量的行為就像一個免費的操作碼生棍。
• ZEND_LIVE_LOOP：這是一個foreach循環(huán)變量，它不僅包含簡單的zval媳谁。這對應(yīng)于FE_FREE操作碼足绅。
• ZEND_LIVE_SILENCE：用于實現(xiàn)錯誤抑制運算符。舊的錯誤報告級別備份到臨時數(shù)據(jù)庫中韩脑，稍后恢復(fù)。如果拋出異常粹污，我們顯然希望恢復(fù)它段多。這對應(yīng)于END_SILENCE。
  ZEND_LIVE_ROPE：用于繩索串連接壮吩，在這種情況下进苍，臨時數(shù)據(jù)是位于zend_string*堆棧上的固定大小的指針數(shù)組 。在這種情況下鸭叙，所有已經(jīng)被填充的字符串都必須被釋放觉啊。大致對應(yīng)于END_ROPE。
  在這種情況下要考慮的一個棘手問題是沈贝，如果它們的產(chǎn)生或消費指令拋出杠人，是否應(yīng)該釋放臨時對象。考慮下面的簡單代碼：

T2 = ADD T0, T1
ASSIGN $v, T2

如果ADD引發(fā)異常嗡善，T2臨時應(yīng)該自動釋放還是ADD指令對此負責(zé)辑莫？同樣，如果ASSIGN拋出罩引，T2應(yīng)該自動釋放各吨，還是ASSIGN必須自己處理？在后一種情況下袁铐，答案是明確的：即使拋出異常揭蜒，指令總是負責(zé)釋放其操作數(shù)。

結(jié)果操作數(shù)的情況比較棘手剔桨，因為這里的答案在PHP 7.1和7.2之間改變了：在PHP 7.1中屉更，指令負責(zé)在發(fā)生異常時釋放結(jié)果。在PHP7.2中领炫，它被自動釋放（并且該指令負責(zé)確迸伎澹總是填充結(jié)果）。這種變化的動機是很多基本指令（如ADD）的實施方式帝洪。他們通常的結(jié)構(gòu)大致如下：

1. read input operands
2. perform operation, write it into result operand
3. free input operands (if necessary)

這是有問題的似舵，因為PHP處于非常不幸的位置，不僅支持異常和析構(gòu)函數(shù)葱峡，而且還支持拋出析構(gòu)函數(shù)（這是編譯器工程師驚恐地哭泣的地步）砚哗。因此，第3步可以拋出砰奕，在這一點上結(jié)果已經(jīng)填充蛛芥。為避免這種邊緣情況下的內(nèi)存泄漏，釋放結(jié)果操作數(shù)的責(zé)任已從指令轉(zhuǎn)移到異常處理機制军援。

一旦我們執(zhí)行了這些清理操作仅淑，我們就可以繼續(xù)執(zhí)行catch塊。如果沒有catch（最后也沒有）胸哥，我們展開堆棧涯竟，也就是銷毀當(dāng)前的堆棧幀并在處理異常時給父幀一個shot。

因此空厌，您可以充分理解整個異常處理業(yè)務(wù)的丑陋程度庐船，我將介紹與拋出析構(gòu)函數(shù)相關(guān)的另一個小技巧。這在實踐中并不是很相關(guān)嘲更，但我們?nèi)匀恍枰幚硭源_保正確性筐钟。考慮這個代碼：

foreach (new Dtor as $value) {
    try {
        echo "Return";
        return;
    } catch (Exception $e) {
        echo "Catch";
    }
}

現(xiàn)在想象這Dtor是一個帶有析構(gòu)函數(shù)的Traversable類赋朦。此代碼將導(dǎo)致以下操作碼序列篓冲，并且為了可讀性而縮進循環(huán)主體：

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   # <- return
L6:       RETURN null                   # <- return
L7:       JMP ->L10
L8:       CATCH 'Exception' $e
L9:       ECHO 'Catch'
L10:  JMP ->L3
L11:  FE_FREE V2                        # <- the duplicated instr

重要的是李破，請注意“返回”被編譯為循環(huán)變量的FE_FREE和RETURN。現(xiàn)在纹因，如果FE_FREE拋出喷屋，會發(fā)生什么情況，因為Dtor拋出析構(gòu)函數(shù)瞭恰？通常屯曹，我們會說這個指令在try塊內(nèi)，所以我們應(yīng)該調(diào)用catch惊畏。但是恶耽，在這一點上，循環(huán)變量已經(jīng)被破壞颜启！該catch拋棄異常偷俭，我們將嘗試?yán)^續(xù)迭代已經(jīng)死循環(huán)變量。

造成這個問題的原因是缰盏，當(dāng)引發(fā)FE_FREE在try塊內(nèi)時涌萤，它是L11中FE_FREE的副本。從邏輯上講口猜，這是發(fā)生異常的地方负溪。這就是為什么中斷生成的FE_FREE被注釋為FREE_ON_RETURN的原因。這指示異常處理機制將異常源移至原始釋放指令济炎。因此川抡，上面的代碼不會運行catch塊，它會生成一個未捕獲的異常须尚。

Finally處理（Finally handling）

PHP與finally塊相關(guān)的歷史有點麻煩崖堤。PHP 5.5首先引入了最終塊，或者更確切地說：最終塊的一個非常錯誤的實現(xiàn)耐床。PHP 5.6,7.0和7.1中的每一個都隨著最終實現(xiàn)的重寫而發(fā)布密幔，每個都修復(fù)了大量錯誤，但未能完全實現(xiàn)完全正確的實現(xiàn)撩轰。

在編寫本節(jié)時老玛，我很驚訝地發(fā)現(xiàn)，從當(dāng)前的實施和我目前的理解來看钧敞，最終處理實際上并不復(fù)雜。事實上麸粮，在許多方面溉苛，通過不同的迭代實現(xiàn)變得更簡單，而不是更復(fù)雜弄诲。這表明對問題的理解不足可能會導(dǎo)致過于復(fù)雜和錯誤的實現(xiàn)（雖然公平地說愚战，PHP 5實現(xiàn)的復(fù)雜性的一部分直接源于AST的缺乏）娇唯。

通常只要控件退出try塊，正常（例如使用返回）或異常（通過拋出）就會運行Finally塊寂玲。有幾個有趣的邊緣案例需要考慮塔插，我將在進入實施之前快速闡述。請考慮：

try {
    throw new Exception();
} finally {
    return 42;
}

怎么了拓哟？最后獲勝并且函數(shù)返回42想许。請考慮：

try {
    return 24;
} finally {
    return 42;
}

finally再次贏了，函數(shù)返回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塊茸炒，例如執(zhí)行來自finally外部的goto跳轉(zhuǎn)到finally內(nèi)標(biāo)簽是被禁止的。

使用這個方式阵苇，我們可以初步的看看finally如何工作壁公。該實現(xiàn)使用兩個操作碼FAST_CALL和FAST_RET。粗略地說慎玖，F(xiàn)AST_CALL用于跳到finally塊贮尖，F(xiàn)AST_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中趁怔，并跳轉(zhuǎn)到L3處的finally塊中湿硝。當(dāng)達到FAST_RET時，它跳回到T0中存儲的位置（之后）润努。在這種情況下关斜，L2圍繞finally塊跳轉(zhuǎn)。這是沒有特殊控制流程（返回或異常）發(fā)生的基本情況∑探剑現(xiàn)在我們來看一下這個特例：

try {
    throw new Exception("try");
} catch (Exception $e) {
    throw new Exception("catch");
} finally {
    throw new Exception("finally");
}

處理異常時痢畜，我們必須考慮拋出的異常相對于最接近的周圍try / catch / finally塊的位置：

1. 從try中拋出，并匹配catch：填充$e并跳入catch鳍侣。
2. 從try或catch中拋出丁稀，如果存在finally塊：跳轉(zhuǎn)到finally塊，并且這次將異常備份到FAST_CALL臨時變量（而不是在那里存儲返回地址）倚聚。
3. 從finally拋出：如果備份異常存在臨時FAST_CALL中的线衫，則將其作為先前拋出異常的異常鏈接。繼續(xù)將異常冒泡到下一個try / catch / finally惑折。
4. 否則：繼續(xù)將異常冒泡到下一個try / catch / finally授账。

在這個例子中枯跑，我們將通過前三個步驟：首先嘗試拋出，引發(fā)跳入catch白热。Catch也會拋出敛助，觸發(fā)到finally塊的跳轉(zhuǎn)，除非在FAST_CALL臨時中備份屋确。然后finally塊也會拋出纳击，這樣，“finally”異常將會像之前的異常一樣被設(shè)置為“catch”異常乍恐。

前面例子中的一個小變化是以下代碼：

try {
    try {
        throw new Exception("try");
    } finally {}
} catch (Exception $e) {
    try {
        throw new Exception("catch");
    } finally {}
} finally {
    try {
        throw new Exception("finally");
    } finally {}
}

這里的所有內(nèi)部最終塊都是異常輸入评疗，但通常保持不變（通過FAST_RET）。在這種情況下茵烈，先前描述的異常處理過程從父try / catch / finally塊開始繼續(xù)百匆。這個父try / catch存儲在FAST_RET操作碼中（這里是“try-catch（0）”）。

這基本上涵蓋finally和exceptions的關(guān)系呜投。但finaly的返回呢加匈？

try {
    throw new Exception("try");
} finally {
    return 42;
}

操作碼序列的相關(guān)部分是這樣的：

L4:   T0 = FAST_CALL ->L6
L5:   JMP ->L9
L6:   DISCARD_EXCEPTION T0
L7:   RETURN 42
L8:   FAST_RET T0

額外的DISCARD_EXCEPTION操作碼負責(zé)放棄在try塊中拋出的異常（記住：finally獲勝的返回）仑荐。那么try的返回呢雕拼？

try {
    $a = 42;
    return $a;
} finally {
    ++$a;
}

這里的例外返回值是42，而不是43.返回值由return$a行確定粘招，任何進一步的修改$a都不重要啥寇。代碼結(jié)果：

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

其中兩個操作碼無法訪問，因為它們在返回后發(fā)生洒扎。這些將在優(yōu)化期間被刪除辑甜，但我在這里顯示未優(yōu)化的操作碼。這里有兩件有趣的事情：首先袍冷，
$a使用QM_ASSIGN（基本上是“復(fù)制到臨時變量”指令）復(fù)制到T3中磷醋。這是防止后來修改$a 影響返回值的原因。其次胡诗，T3也傳遞給FAST_CALL邓线，它將備份T1中的值。如果try塊的返回值稍后被丟棄（例如煌恢，因為最后拋出或返回）骇陈，則此機制將用于釋放未使用的返回值。

所有這些單獨的機制都很簡單瑰抵，但是在組成時需要謹(jǐn)慎缩歪。考慮下面的例子谍憔，其中又Dtor是一些帶有拋出析構(gòu)函數(shù)的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

第一次返回的序列（來自內(nèi)部try）是FAST_CALL L10匪蝙，F(xiàn)E_FREE V4，F(xiàn)AST_CALL L19习贫，RETURN逛球。這將首先調(diào)用內(nèi)部finally塊，然后釋放foreach循環(huán)變量苫昌，然后調(diào)用外部finally塊并返回颤绕。第二次返回的序列（最終來自內(nèi)部）是DISCARD_EXCEPTION T5，F(xiàn)E_FREE V4祟身，F(xiàn)AST_CALL L19奥务。首先放棄內(nèi)部try塊的異常（或這里：返回值），然后釋放foreach循環(huán)變量并最終調(diào)用外部finally塊袜硫。請注意氯葬，在這兩種情況下，這些指令的順序是源代碼中相關(guān)塊的反向順序婉陷。

生成器（Generators）

發(fā)生器功能可能會暫停和恢復(fù)帚称，因此需要特殊的VM棧管理。這是一個簡單的生成器：

function gen($x) {
    foo(yield $x);
}

這會產(chǎn)生以下操作碼：

$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堆棧上作為普通函數(shù)執(zhí)行的闯睹。GENERATOR_CREATE然后創(chuàng)建一個Generator對象，以及一個堆分配的execute_data結(jié)構(gòu)（像往常一樣包括變量和參數(shù)的槽）担神，VM棧上的execute_data被復(fù)制到其中楼吃。

當(dāng)生成器再次恢復(fù)時，執(zhí)行器將使用堆分配的execute_data妄讯，但將繼續(xù)使用主VM堆棧來推送調(diào)用幀孩锡。一個明顯的問題是，如前面的例子所示捞挥，在調(diào)用過程中可能會中斷發(fā)生器浮创。這里YIELD是在調(diào)用foo()的調(diào)用幀已經(jīng)被壓入VM棧的時候執(zhí)行的。

這種相對不常見的情況是通過在產(chǎn)生控制時將調(diào)用幀復(fù)制到發(fā)生器結(jié)構(gòu)中并在發(fā)生器恢復(fù)時恢復(fù)它們來處理砌函。

這個設(shè)計自PHP 7.1起使用斩披。以前，每個發(fā)生器都有自己的4KiB虛擬機頁面讹俊，當(dāng)發(fā)生器恢復(fù)時它將被交換到執(zhí)行器垦沉。這樣可以避免復(fù)制調(diào)用幀，但會增加內(nèi)存使用量仍劈。

智能分支（Smart branches）

比較指令直接跟隨條件跳轉(zhuǎn)是很常見的厕倍。例如：

L0:   T2 = IS_EQUAL $a, $b
L1:   JMPZ T2 ->L3
L2:   ECHO "equal"

由于這種模式非常普遍，所有比較操作碼（如IS_EQUAL）都實現(xiàn)了智能分支機制：它們檢查下一條指令是JMPZ還是JMPNZ指令贩疙，如果是讹弯，則自行執(zhí)行相應(yīng)的跳轉(zhuǎn)操作况既。

智能分支機制只檢查下一條指令是否是JMPZ/JMPNZ，但實際上并不檢查其操作數(shù)是否實際上是比較的結(jié)果或其他组民。在比較和隨后的跳躍不相關(guān)的情況下棒仍，這需要特別小心。例如臭胜，代碼($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結(jié)果乱陡，而不是JMPZ操作數(shù)。

運行時緩存（Runtime cache）

由于操作碼數(shù)組在多個進程之間共享（無鎖）仪壮，因此它們是不可變的憨颠。但是，運行時值可以緩存在單獨的“運行時緩存”中睛驳，該緩存基本上是一個指針數(shù)組烙心。Literals可能有一個關(guān)聯(lián)的運行時緩存條目（或多個），它存儲在它們的u2插槽中乏沸。

運行時高速緩存條目有兩種類型：第一種是普通高速緩存條目淫茵，例如INIT_FCALL使用的條目。INIT_FCALL查找一次被調(diào)用的函數(shù)（根據(jù)其名稱）后，函數(shù)指針將被緩存在關(guān)聯(lián)的運行時緩存槽中。

第二種類型是多態(tài)高速緩存條目纳鼎，它們只是兩個連續(xù)的高速緩存槽，其中第一個存儲類條目丹喻，第二個存儲實際數(shù)據(jù)。這些用于像FETCH_OBJ_R這樣的操作翁都，其中某個類的屬性表中屬性的偏移量被緩存碍论。如果下一次訪問發(fā)生在同一個類上（很有可能），則將使用緩存的值柄慰。否則鳍悠，將執(zhí)行更昂貴的查找操作，并將結(jié)果緩存到新的類條目中坐搔。

VM中斷（VM interrupts）

在PHP 7.0之前藏研，執(zhí)行超時用于直接從信號處理程序通過longjump處理關(guān)閉序列。如你所想概行，這引起了各種不愉快的事情蠢挡。由于PHP 7.0超時被延遲，直到控制權(quán)返回到虛擬機。如果它在特定的寬限期內(nèi)沒有返回业踏，則該過程被中止禽炬。由于PHP 7.1 pcntl信號處理程序使用與執(zhí)行超時相同的機制。

當(dāng)一個信號掛起時勤家，VM中斷標(biāo)志被設(shè)置瞎抛，并且這個標(biāo)志由虛擬機在某些點檢查。檢查不是在每條指令上執(zhí)行却紧，而是僅在跳轉(zhuǎn)和調(diào)用時執(zhí)行。因此胎撤，在返回到VM時不會立即處理中斷晓殊，而是在線性控制流的當(dāng)前部分結(jié)束時處理。

特殊化（Specialization）

如果查看VM定義文件伤提，會發(fā)現(xiàn)操作碼處理程序定義如下：

ZEND_VM_HANDLER(1, ZEND_ADD, CONST|TMPVAR|CV, CONST|TMPVAR|CV)

1在這里是操作碼數(shù)巫俺，ZEND_ADD它的名字，而另外兩個參數(shù)指定指令接受哪些類型的操作肿男。所述生成的虛擬機代碼（由生成zend_vm_gen.php然后）將包含為每個可能的操作數(shù)類型的組合的專門處理程序介汹。生成有像ZEND_ADD_SPEC_CONST_CONST_HANDLER這樣的名稱。

專用處理程序是通過替換處理程序主體中的某些宏來生成的舶沛。比較容易看出的是OP1_TYPE和OP2_TYPE嘹承，但諸如GET_OP1_ZVAL_PTR（）和FREE_OP1（）等操作也是專用的。

ADD的處理程序指定它接受CONST|TMPVAR|CV操作數(shù)如庭。這里的TMPVAR意味著操作碼同時接受TMP和VAR叹卷，但要求這些不是單獨專用的。請記住坪它，對于大多數(shù)用途而言骤竹，TMP和VAR之間的唯一區(qū)別是后者可以包含引用。對于像ADD這樣的操作碼（無論如何往毡，引用都在慢速路徑（slow-path）上）蒙揣，單獨進行特殊化并不值得。一些其他操作碼確實可以區(qū)分TMP|VAR它們的操作數(shù)列表开瞭。

除了基于操作數(shù)類型的特殊化之外懒震，處理程序還可以專門處理其他因素，例如是否使用其返回值惩阶。ASSIGN_DIM基于以下OP_DATA操作碼的操作數(shù)類型進行特殊化：

ZEND_VM_HANDLER(147, ZEND_ASSIGN_DIM,
    VAR|CV, CONST|TMPVAR|UNUSED|NEXT|CV, SPEC(OP_DATA=CONST|TMP|VAR|CV))

根據(jù)此簽名挎狸，將生成244=32個不同的ASSIGN_DIM變體。第二個操作數(shù)的規(guī)范也包含一個條目NEXT断楷。這與特殊化無關(guān)锨匆，而是指定了UNUSED操作數(shù)在此上下文中的含義：它表示這是一個附加操作（$arr[]）。另一個例子：

ZEND_VM_HANDLER(23, ZEND_ASSIGN_ADD,
    VAR|UNUSED|THIS|CV, CONST|TMPVAR|UNUSED|NEXT|CV, DIM_OBJ, SPEC(DIM_OBJ))

在這里我們已經(jīng)知道第一個操作數(shù)是UNUSED意味著一個訪問$this。這是與對象有關(guān)的操作碼的一般慣例恐锣，例如FETCH_OBJ_R UNUSED,'prop'對應(yīng)于$this->prop茅主。未使用的第二個操作數(shù)也意味著附加操作。這里的第三個參數(shù)指定的extended_value數(shù)的含義：它包含區(qū)分的標(biāo)志$a += 1土榴，$a[$b] += 1和$a->b += 1诀姚。最后，SPEC(DIM_OBJ)指示應(yīng)該為每一個生成一個專門的處理程序玷禽。（在這種情況下赫段，將生成的總處理程序數(shù)量并不重要，因為VM生成器知道某些組合是不可能的矢赁，例如UNUSED op1只與OBJ情況相關(guān)糯笙，等等）

最后，虛擬機生成器還支持更復(fù)雜的特殊化機制撩银。在定義文件的末尾给涕，你會發(fā)現(xiàn)一些這種形式的處理程序：

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操作數(shù)類型，還基于操作數(shù)在運行時可能采用的可能類型额获。確定可能的操作數(shù)類型的機制是opcache優(yōu)化基礎(chǔ)結(jié)構(gòu)的一部分够庙，這超出了本文的范圍。但是抄邀，假設(shè)這些信息可用耘眨，應(yīng)該清楚這是int + int -> int一個附加的形式。此外撤摸，SPEC注釋告訴specilizer毅桃，不應(yīng)該生成兩個const操作數(shù)的變體，并且操作是可交換的准夷，所以如果我們已經(jīng)有了CONST + TMPVARCV特殊化钥飞，我們也不需要生成TMPVARCV + CONST。

快速路徑/慢速路徑分割（Fast-path / slow-path split）

許多操作碼處理程序都是使用快速路徑/慢速路徑分割來實現(xiàn)的衫嵌，其中首先處理幾個常見情況读宙，然后再回到通用實現(xiàn)。這是關(guān)于我們查看一些實際代碼的時間了楔绞，所以我將在這里粘貼整個SL（左移）實現(xiàn)：

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();
}

該實現(xiàn)通過GET_OPn_ZVAL_PTR_UNDEF以BP_VAR_R模式獲取操作數(shù)開始结闸。UNDEF這里的部分意味著在CV情況下不執(zhí)行未定義變量的檢查，而只是按照原樣返回UNDEF值酒朵。一旦我們有操作數(shù)桦锄，我們檢查兩者是否都是整數(shù)，并且移位寬度在范圍內(nèi)蔫耽，在這種情況下结耀，結(jié)果可以直接計算出來，并且我們前進到下一個操作碼。值得注意的是图甜，這里的類型檢查并不關(guān)心操作數(shù)是否為UNDEF碍粥，所以使用GET_OPN_ZVAL_PTR_UNDEF是合理的。

如果操作數(shù)不能滿足快速路徑黑毅，我們回到通用實現(xiàn)嚼摩，該實現(xiàn)以SAVE_OPLINE（）開始。這是我們的信號“潛在的投擲操作”矿瘦。在繼續(xù)之前枕面，處理未定義變量的情況。在這種情況下缚去，GET_OPn_UNDEF_CV將發(fā)出未定義的變量通知并返回NULL值膊畴。

接下來，調(diào)用通用shift_left_function并將其結(jié)果寫入EX_VAR(opline->result.var)病游。最后，輸入操作數(shù)被釋放（如果需要）稠通，并且我們前進到具有異常檢查的下一個操作碼（這意味著在前進之前重新裝入操作數(shù)）衬衬。

因此，這里的快速路徑保存了未定義變量的兩個檢查改橘，對通用運算符函數(shù)的調(diào)用滋尉，釋放操作數(shù)，以及保存和重新加載opline以進行異常處理飞主。大部分性能敏感的操作碼都以相似的方式排列狮惜。

VM宏（VM macros）

從前面的代碼清單可以看出，虛擬機實現(xiàn)可以自由使用宏碌识。其中一些是普通的C宏碾篡，而另一些則是在生成虛擬機時解決的。特別是筏餐，這包括許多用于獲取和釋放指令操作數(shù)的宏：

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_*參數(shù)指定的提取模式并支持相同的模式作為FETCH_ *（與FUNC_ARG除外）的說明魁瞪。

GET_OPn_ZVAL_PTR()是基本的操作數(shù)獲取穆律。它會在未定義的CV上發(fā)出通知，并且不會取消操作數(shù)的取消引用导俘。GET_OPn_ZVAL_PTR_UNDEF()正如我們已經(jīng)知道的那樣峦耘，它是一種不檢查未定義的CV的變體。 GET_OPn_ZVAL_PTR_DEREF()包括zval的DEREF旅薄。這是專門的GET操作的一部分辅髓，因為解引用僅對于CV和VAR是必需的，但對于CONST和TMP不是必需的。因為這個宏需要區(qū)分TMP和VAR利朵，它只能用于TMP|VAR專業(yè)化（但不能TMPVAR）律想。

這些GET_OPn_OBJ_ZVAL_PTR*()變體還處理UNUSED操作數(shù)的情況。如前所述绍弟，通過約定$this訪問使用UNUSED操作數(shù)技即，所以GET_OPn_OBJ_ZVAL_PTR*()宏將返回EX(This)對UNUSED操作的引用。

最后樟遣，還有一些PTR_PTR變體而叼。這里的命名是來自PHP5，其中這實際上使用了雙向的zval指針豹悬。這些宏用于寫操作葵陵，因此僅支持CV和VAR類型（其他任何返回NULL）。它們與正常的PTR提取不同瞻佛，因為它們?nèi)∠薞AR操作數(shù)脱篙。

這些FREE_OP*()宏然后用來釋放取出的操作數(shù)。要進行操作伤柄，它們需要定義一個zend_free_op free_opN變量绊困，GET操作將該 變量存儲到該變量中以釋放∈实叮基線FREE_OPn()操作將釋放TMP和VAR秤朗，但不會釋放CV和CONST。FREE_OPn_IF_VAR()完全按照它的說法：只有當(dāng)它是VAR時才釋放操作數(shù)笔喉。

該FREE_OP*_VAR_PTR()變體與PTR_PTR提取結(jié)合使用取视。它只會釋放VAR操作數(shù)，并且只有在它們不是INDIRECTed的時候常挚。

FREE_UNFETCHED_OP*()在使用GET獲取操作數(shù)之前必須釋放操作數(shù)的情況下使用這些變體作谭。如果在操作數(shù)提取之前拋出異常，通常會發(fā)生這種情況奄毡。

除了這些特殊的宏之外丢早，還有一些比較普通的宏。虛擬機定義了三個宏來控制操作碼處理程序運行后發(fā)生的情況：

ZEND_VM_CONTINUE()
ZEND_VM_ENTER()
ZEND_VM_LEAVE()
ZEND_VM_RETURN()

CONTINUE將繼續(xù)正常執(zhí)行操作碼秧倾，而ENTER和LEAVE則用于進入/離開嵌套函數(shù)調(diào)用怨酝。這些操作的具體細節(jié)取決于VM編譯的精確程度（例如，是否使用全局寄存器那先，如果是农猬，使用哪一個）。從廣義上講售淡，這些將在繼續(xù)之前同步一些狀態(tài)斤葱。RETURN用于實際退出主VM環(huán)路慷垮。

ZEND_VM_CONTINUE（）期望事先更新opline。當(dāng)然揍堕，還有更多的宏相關(guān)：

該表顯示宏是否包含隱式ZEND_VM_CONTINUE（）料身，是否會檢查異常以及是否檢查VM中斷。

除此之外衩茸，還有SAVE_OPLINE()芹血，LOAD_OPLINE()和HANDLE_EXCEPTION()。正如在異常處理一節(jié)中所提到的楞慈，SAVE_OPLINE（）在操作碼處理程序中的第一個可能的拋出操作之前使用幔烛。如有必要，它將VM（可能位于全局寄存器中）使用的opline寫回到執(zhí)行數(shù)據(jù)中囊蓝。LOAD_OPLINE（）是相反的操作饿悬，但現(xiàn)在它幾乎沒有用處，因為它已被有效地轉(zhuǎn)入ZEND_VM_NEXT_OPCODE_CHECK_EXCEPTION（）和ZEND_VM_JMP（）聚霜。

HANDLE_EXCEPTION（）用于在已經(jīng)知道引發(fā)異常后從操作碼處理程序返回狡恬。它執(zhí)行LOAD_OPLINE和CONTINUE的組合，這將有效地分派到HANDLE_EXCEPTION操作碼蝎宇。

當(dāng)然傲宜，還有更多的宏，但以上應(yīng)該已經(jīng)包含了最重要的部分夫啊。

譯自：PHP 7 Virtual Machine