當(dāng)前位置：首頁 > 编程语言 > php >内容正文

php

PHP7虚拟机（PHP 7 Virtual Machine）（转载）

發(fā)布時(shí)間：2024/3/12 php 32 豆豆

生活随笔收集整理的這篇文章主要介紹了 PHP7虚拟机（PHP 7 Virtual Machine）（转载）小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

2022年11月1日15:59:57
官方地址：https://www.npopov.com/2017/04/14/PHP-7-Virtual-machine.html
轉(zhuǎn)載：https://www.jianshu.com/p/878cf85e07c5

后續(xù)有時(shí)間，會翻譯更多nikic的文章，他是php重要的貢獻(xiàn)者

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

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

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

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

操作碼 (Opcodes)

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

一個(gè)獨(dú)立的指令遵循如下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; };

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

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

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

每個(gè)操作數(shù)都有對應(yīng)的一個(gè)類型，分別存儲在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í)際未使用的操作數(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)儲，并進(jìn)行了一些語法調(diào)整。魔術(shù)數(shù)字0x10000是“優(yōu)化前”的縮寫，因此我們看到PHP編譯器生成的操作碼。0x20000會給你優(yōu)化的操作碼。Opcache還可以生成更多的信息，例如0x40000將生成一個(gè)CFG，而0x200000將生成類型和范圍推斷的SSA表單。但這已經(jīng)超越了我們想要的：普通的、原本的線性化操作碼轉(zhuǎn)儲對我們來說就足夠了。

變量類型(Variable types)

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

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

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

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

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

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

因此，TMP/VAR通常壽命很短。在許多情況下，一個(gè)臨時(shí)變量只存在一個(gè)指令的空間。在這個(gè)短暫的活動之外，臨時(shí)變量就成了垃圾。

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

-UNDEFREFINDIRECTConsumed?Named?

CV	yes	yes	no	no	yes
TMPVAR	no	no	no	yes	no
VAR	no	yes	yes	yes	no

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

-UNDEFREFINDIRECTConsumed?Named?

CV	yes	yes	no	no	yes
TMPVAR	no	no	no	yes	no
VAR	no	yes	yes	yes	no

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

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

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

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，它是一個(gè)包含操作指令的數(shù)組。‘last’是數(shù)組中操作指令的數(shù)量，注意這里的術(shù)語可能令人感到困惑，‘last’看起來像是最后一個(gè)操作指令的索引，但是這里實(shí)際上是操作數(shù)的數(shù)量(比最后一個(gè)操作數(shù)的索引大一)。這同樣適用于op數(shù)組結(jié)構(gòu)中的所有其他‘last_ *’值。

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

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

棧框架布局(Stack frame layout)

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

每一個(gè)函數(shù)調(diào)用時(shí)，將在VM棧上分配一個(gè)新的棧幀，布局如下：

該框架以一個(gè)zend_execute_data結(jié)構(gòu)開始，接著是一個(gè)變量槽(variable slots)的數(shù)組。這些變量槽都相同(simple zvals)，但是用作不同的用途。第一個(gè)‘last_var’槽中內(nèi)容是CV，其中第一個(gè)num_args存放函數(shù)參數(shù)。CV插槽之后是TMP/ VAR的‘T’插槽。最后，有時(shí)可以在幀的末尾存儲“額外”參數(shù)。這些用于處理func_get_args()。

指令中的CV和TMP/VAR操作數(shù)被編碼為相對于堆棧起始位置的偏移量，因此讀取某個(gè)變量只是從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 */ };

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

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

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

筆者跳過了execute_data結(jié)構(gòu)中的一個(gè)字段--‘call'，因?yàn)樗枰P(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í)識別的函數(shù)。同樣，根據(jù)參數(shù)和函數(shù)的類型，有十個(gè)不同的SEND操作碼。只有數(shù)量較少的四個(gè)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 $aV0 = DO_UCALL SEND_VAR V0INIT_FCALL (1 arg) "bar"SEND_VAR $bV1 = DO_UCALL SEND_VAR V1 V2 = DO_ICALL

INIT操作碼在堆棧上壓入一個(gè)調(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形成一個(gè)“未完成”調(diào)用的鏈表，而通常它會提供回溯鏈(雙向鏈表)。

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

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

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

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

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

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

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

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

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

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

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

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

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

FUNC_ARG獲取模式將通過檢查當(dāng)前EX(call)函數(shù)的arginfo來動態(tài)選擇兩種行為之一(R或W)。對于func($a[0][1][2])的例子，操作碼序列可能是這個(gè)樣子：

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虛擬機(jī)有四類提取操作碼：

FETCH_* // $_GET, $$var FETCH_DIM_* // $arr[0] FETCH_OBJ_* // $obj->prop FETCH_STATIC_PROP_* // A::$prop

這些完全符合人們期望它們做的事情，但要注意基本的FETCH_*變體僅用于訪問變量變量和超全局變量：正常變量訪問通過更快的CV機(jī)制來代替。

這些提取操作碼每個(gè)都有六種變體：

_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)

不幸的是，這個(gè)產(chǎn)生的唯一真正的提取是FETCH_DIM_R：其他的東西都是通過特殊的操作碼處理的。請注意，ASSIGN_DIM和ASSIGN_ADD都使用額外的OP_DATA，因?yàn)樗鼈冃枰獌蓚€(gè)以上的輸入操作數(shù)。使用特殊操作碼(如ASSIGN_DIM)而不是像FETCH_DIM_W + ASSIGN之類的原因是(除了性能)，這些操作可能被重載，例如，在ASSIGN_DIM情況下，通過實(shí)現(xiàn)ArrayAccess::offsetSet()的對象實(shí)現(xiàn)。要實(shí)際生成不同的提取類型，我們需要增加嵌套的級別：

// $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進(jìn)行處理。fetch模式的基本區(qū)別在于a)如果索引不存在，它們是否生成“未定義偏移量”通知，以及它們是否獲取寫入值：

?Notice?Write?

R	yes	no
W	no	yes
RW	yes	yes
IS	no	no
UNSET	no	yes-ish

UNSET的情況有點(diǎn)奇怪，因?yàn)樗荒茏x取現(xiàn)有的偏移量以便寫入，并且保留單獨(dú)的未定義的偏移量。正常的寫取操作會初始化未定義的偏移量。

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

Write獲取可能包含正常zval或指向另一個(gè)zval的INDIRECT指針的返回VAR。當(dāng)然，在前一種情況下，應(yīng)用于zval的任何更改都將不可見，因?yàn)樵撝抵荒芡ㄟ^虛擬機(jī)暫時(shí)訪問。雖然PHP禁止表達(dá)[][0] = 42，但我們?nèi)匀恍枰幚磉@種情況 call()[0] = 42。取決于是call()按值還是按引用返回，此表達(dá)式可能會或可能不會有顯著效果。

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

考慮這個(gè)例子：$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

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

考慮另一個(gè)例子：

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

這里我們遇到了一些問題：兩邊的復(fù)制必須提取值才能寫入。但是，如果我們抓取$arr[0] 寫入然后寫入$arr[1]，后者可能會使前者無效。這個(gè)問題解決如下：

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é)果不再是間接的并且不會失效，因?yàn)檫@樣的獲取$arr[0]可以安全地執(zhí)行。

異常處理(Exception handling)

異常是萬惡之源。

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

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

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

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

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

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

現(xiàn)在，這個(gè)機(jī)制是在引發(fā)異常之后導(dǎo)致HANDLE_EXCEPTION操作碼執(zhí)行的原因。但它有什么作用？首先，它確定是否在try塊內(nèi)引發(fā)異常。為此，op數(shù)組包含一個(gè)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)在我們會假裝最后的塊不存在，因?yàn)樗鼈兪且粋€(gè)完全不同的。假設(shè)我們確實(shí)在try塊內(nèi)，VM需要清理在拋出opline之前開始的所有未完成的操作，并且不會跨越try塊的末尾。

這涉及釋放當(dāng)前在使用中的所有調(diào)用的棧幀和相關(guān)數(shù)據(jù)，以及釋放臨時(shí)變量。在大多數(shù)情況下，臨時(shí)變量存在時(shí)間很短，甚至達(dá)到消費(fèi)指令直接跟隨著生成指令。然而，它可能發(fā)生在跨越多個(gè)指令的現(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)用拋出時(shí)需要銷毀T0變量。一種特定的臨時(shí)類型往往具有特別長的活動范圍：循環(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(通常總是跨越整個(gè)循環(huán)體)。實(shí)時(shí)范圍使用以下結(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)然，如果暫時(shí)沒有立即消耗，則僅存儲活動范圍。

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

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

T2 = ADD T0, T1 ASSIGN $v, T2

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

結(jié)果操作數(shù)的情況比較棘手，因?yàn)檫@里的答案在PHP 7.1和7.2之間改變了：在PHP 7.1中，指令負(fù)責(zé)在發(fā)生異常時(shí)釋放結(jié)果。在PHP7.2中，它被自動釋放(并且該指令負(fù)責(zé)確保總是填充結(jié)果)。這種變化的動機(jī)是很多基本指令(如ADD)的實(shí)施方式。他們通常的結(jié)構(gòu)大致如下：

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

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

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

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

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

現(xiàn)在想象這Dtor是一個(gè)帶有析構(gòu)函數(shù)的Traversable類。此代碼將導(dǎo)致以下操作碼序列，并且為了可讀性而縮進(jìn)循環(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ā)生什么情況，因?yàn)镈tor拋出析構(gòu)函數(shù)？通常，我們會說這個(gè)指令在try塊內(nèi)，所以我們應(yīng)該調(diào)用catch。但是，在這一點(diǎn)上，循環(huán)變量已經(jīng)被破壞！該catch拋棄異常，我們將嘗試?yán)^續(xù)迭代已經(jīng)死循環(huán)變量。

造成這個(gè)問題的原因是，當(dāng)引發(fā)FE_FREE在try塊內(nèi)時(shí)，它是L11中FE_FREE的副本。從邏輯上講，這是發(fā)生異常的地方。這就是為什么中斷生成的FE_FREE被注釋為FREE_ON_RETURN的原因。這指示異常處理機(jī)制將異常源移至原始釋放指令。因此，上面的代碼不會運(yùn)行catch塊，它會生成一個(gè)未捕獲的異常。

Finally處理(Finally handling)

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

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

通常只要控件退出try塊，正常(例如使用返回)或異常(通過拋出)就會運(yùn)行Finally塊。有幾個(gè)有趣的邊緣案例需要考慮，我將在進(jìn)入實(shí)施之前快速闡述。請考慮：

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”將生成一個(gè)編譯錯(cuò)誤。重要的是要明白，這個(gè)限制是純粹示例代碼(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)簽是被禁止的。

使用這個(gè)方式，我們可以初步的看看finally如何工作。該實(shí)現(xiàn)使用兩個(gè)操作碼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中，并跳轉(zhuǎn)到L3處的finally塊中。當(dāng)達(dá)到FAST_RET時(shí)，它跳回到T0中存儲的位置(之后)。在這種情況下，L2圍繞finally塊跳轉(zhuǎn)。這是沒有特殊控制流程(返回或異常)發(fā)生的基本情況。現(xiàn)在我們來看一下這個(gè)特例：

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

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

從try中拋出，并匹配catch：填充$e并跳入catch。

從try或catch中拋出，如果存在finally塊：跳轉(zhuǎn)到finally塊，并且這次將異常備份到FAST_CALL臨時(shí)變量(而不是在那里存儲返回地址)。

從finally拋出：如果備份異常存在臨時(shí)FAST_CALL中的，則將其作為先前拋出異常的異常鏈接。繼續(xù)將異常冒泡到下一個(gè)try / catch / finally。

否則：繼續(xù)將異常冒泡到下一個(gè)try / catch / finally。

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

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

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ù)。這個(gè)父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操作碼負(fù)責(zé)放棄在try塊中拋出的異常(記住：finally獲勝的返回)。那么try的返回呢？

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

這里的例外返回值是42，而不是43.返回值由return$a行確定，任何進(jìn)一步的修改$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

其中兩個(gè)操作碼無法訪問，因?yàn)樗鼈冊诜祷睾蟀l(fā)生。這些將在優(yōu)化期間被刪除，但我在這里顯示未優(yōu)化的操作碼。這里有兩件有趣的事情：首先，
$a使用QM_ASSIGN(基本上是“復(fù)制到臨時(shí)變量”指令)復(fù)制到T3中。這是防止后來修改$a 影響返回值的原因。其次，T3也傳遞給FAST_CALL，它將備份T1中的值。如果try塊的返回值稍后被丟棄(例如，因?yàn)樽詈髵伋龌蚍祷?，則此機(jī)制將用于釋放未使用的返回值。

所有這些單獨(dú)的機(jī)制都很簡單，但是在組成時(shí)需要謹(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，FE_FREE V4，FAST_CALL L19，RETURN。這將首先調(diào)用內(nèi)部finally塊，然后釋放foreach循環(huán)變量，然后調(diào)用外部finally塊并返回。第二次返回的序列(最終來自內(nèi)部)是DISCARD_EXCEPTION T5，FE_FREE V4，FAST_CALL L19。首先放棄內(nèi)部try塊的異常(或這里：返回值)，然后釋放foreach循環(huán)變量并最終調(diào)用外部finally塊。請注意，在這兩種情況下，這些指令的順序是源代碼中相關(guān)塊的反向順序。

生成器(Generators)

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

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

在到達(dá)GENERATOR_CREATE之前，這是在普通VM堆棧上作為普通函數(shù)執(zhí)行的。GENERATOR_CREATE然后創(chuàng)建一個(gè)Generator對象，以及一個(gè)堆分配的execute_data結(jié)構(gòu)(像往常一樣包括變量和參數(shù)的槽)，VM棧上的execute_data被復(fù)制到其中。

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

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

這個(gè)設(shè)計(jì)自PHP 7.1起使用。以前，每個(gè)發(fā)生器都有自己的4KiB虛擬機(jī)頁面，當(dāng)發(fā)生器恢復(fù)時(shí)它將被交換到執(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)都實(shí)現(xiàn)了智能分支機(jī)制：它們檢查下一條指令是JMPZ還是JMPNZ指令，如果是，則自行執(zhí)行相應(yīng)的跳轉(zhuǎn)操作。

智能分支機(jī)制只檢查下一條指令是否是JMPZ/JMPNZ，但實(shí)際上并不檢查其操作數(shù)是否實(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。如果這個(gè)NOP不存在，分支將最終使用IS_EQUAL結(jié)果，而不是JMPZ操作數(shù)。

運(yùn)行時(shí)緩存(Runtime cache)

由于操作碼數(shù)組在多個(gè)進(jìn)程之間共享(無鎖)，因此它們是不可變的。但是，運(yùn)行時(shí)值可以緩存在單獨(dú)的“運(yùn)行時(shí)緩存”中，該緩存基本上是一個(gè)指針數(shù)組。Literals可能有一個(gè)關(guān)聯(lián)的運(yùn)行時(shí)緩存條目(或多個(gè))，它存儲在它們的u2插槽中。

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

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

VM中斷(VM interrupts)

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

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

特殊化(Specialization)

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

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

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

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

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

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

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

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

最后，虛擬機(jī)生成器還支持更復(fù)雜的特殊化機(jī)制。在定義文件的末尾，你會發(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ù)在運(yùn)行時(shí)可能采用的可能類型。確定可能的操作數(shù)類型的機(jī)制是opcache優(yōu)化基礎(chǔ)結(jié)構(gòu)的一部分，這超出了本文的范圍。但是，假設(shè)這些信息可用，應(yīng)該清楚這是int + int -> int一個(gè)附加的形式。此外，SPEC注釋告訴specilizer，不應(yīng)該生成兩個(gè)const操作數(shù)的變體，并且操作是可交換的，所以如果我們已經(jīng)有了CONST + TMPVARCV特殊化，我們也不需要生成TMPVARCV + CONST。

快速路徑/慢速路徑分割(Fast-path / slow-path split)

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

ZEND_VM_HANDLER(6, ZEND_SL, CONST|TMPVAR|CV, CONST|TMPVAR|CV) {USE_OPLINEzend_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(); }

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

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

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

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

VM宏(VM macros)

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

OPn_TYPE OP_DATA_TYPEGET_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操作的一部分，因?yàn)榻庖脙H對于CV和VAR是必需的，但對于CONST和TMP不是必需的。因?yàn)檫@個(gè)宏需要區(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，其中這實(shí)際上使用了雙向的zval指針。這些宏用于寫操作，因此僅支持CV和VAR類型(其他任何返回NULL)。它們與正常的PTR提取不同，因?yàn)樗鼈內(nèi)∠薞AR操作數(shù)。

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

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

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

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

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

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

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

-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()。正如在異常處理一節(jié)中所提到的，SAVE_OPLINE()在操作碼處理程序中的第一個(gè)可能的拋出操作之前使用。如有必要，它將VM(可能位于全局寄存器中)使用的opline寫回到執(zhí)行數(shù)據(jù)中。LOAD_OPLINE()是相反的操作，但現(xiàn)在它幾乎沒有用處，因?yàn)樗驯挥行У剞D(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)包含了最重要的部分。

總結(jié)

以上是生活随笔為你收集整理的PHP7虚拟机（PHP 7 Virtual Machine）（转载）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。

上一篇：中国图形图象学报和计算机科学,lbrac
下一篇：电脑打不开html网页,电脑网页打不开怎