PHP는 해석형 언어입니다. Java, Python, Ruby, Javascript 등의 해석 언어의 경우 우리가 작성한 코드는 기계어 코드로 컴파일되어 실행되지 않고 중간 코드로 컴파일되어 실행됩니다. 가상 머신(VM)이 켜져 있습니다. PHP를 실행하는 가상 머신을 Zend 가상 머신이라고 합니다. 오늘은 커널에 대해 자세히 알아보고 Zend 가상 머신의 작동 원리를 살펴보겠습니다.
OPCODE란 무엇인가요? 가상 머신이 인식하고 처리할 수 있는 명령입니다. Zend 가상 머신에는 일련의 OPCODE가 포함되어 있습니다. OPCODE 가상 머신은 다양한 작업을 수행할 수 있습니다. 다음은 OPCODE의 몇 가지 예입니다.
ZEND_ADD 두 개의 피연산자를 추가합니다.
ZEND_NEW PHP 개체를 만듭니다.
ZEND_ECHO 콘텐츠를 표준 출력으로 출력합니다.
ZEND_EXIT PHP를 종료합니다. 파일 (이 파일의 내용은 네이티브 C 코드가 아니고 템플릿인데, 이유는 나중에 설명하겠습니다).
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의 데이터 구조를 잘 살펴보고 어셈블리 언어의 느낌을 찾을 수 있는지 살펴보세요. 각 OPCODE에는 zend/zend_vm_def.h과
포인터는 OPCODE 연산을 수행하는
함수를 가리킵니다. 함수 처리 결과는 op1 매체에 저장됩니다. op2handler간단한 예를 들어보겠습니다. vld 확장을 통해 컴파일 후 위 코드가 ZEND_ADD 명령의 OPCODE를 생성한다는 것을 알 수 있습니다. <?php
$b = 1;
$a = $b + 2;
로그인 후 복사result
compiled vars: !0 = $b, !1 = $a
line #* E I O op
fetch
ext
return
operands
-------------------------------------------------------------------------------------
2 0 E > ASSIGN !0, 1
3 1 ADD ~3 !0, 2
2 ASSIGN !1, ~3
8 3 > RETURN 1명령의 OPCODE이다. 2개의 피연산자를 받는 것을 볼 수 있습니다.
은변수이고,
은 숫자 상수 1이며, 반환된 결과는 임시 변수에 저장됩니다. 파일에서 ZEND_ADD 명령에 해당하는 함수 구현을 찾을 수 있습니다. ZEND_ADD
ZEND_VM_HANDLER(1, ZEND_ADD, CONST|TMPVAR|CV, CONST|TMPVAR|CV)
{
USE_OPLINE
zend_free_op free_op1, free_op2;
zval *op1, *op2, *result;
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)) {
if (EXPECTED(Z_TYPE_INFO_P(op2) == IS_LONG)) {
result = EX_VAR(opline->result.var);
fast_long_add_function(result, op1, op2);
ZEND_VM_NEXT_OPCODE();
} else if (EXPECTED(Z_TYPE_INFO_P(op2) == IS_DOUBLE)) {
result = EX_VAR(opline->result.var);
ZVAL_DOUBLE(result, ((double)Z_LVAL_P(op1)) + Z_DVAL_P(op2));
ZEND_VM_NEXT_OPCODE();
}
} else if (EXPECTED(Z_TYPE_INFO_P(op1) == IS_DOUBLE)) {
...
}op1위 코드는 네이티브 C 코드가 아니라 템플릿입니다. $bop2왜 이러는 걸까요? PHP는 약한 유형의 언어이고, PHP에 구현된 C는 강력한 유형의 언어이기 때문입니다. 약한 유형의 언어는 자동 유형 일치를 지원하며, 자동 유형 일치의 구현은 위 코드와 마찬가지로 판단을 통해 다양한 유형의 매개변수를 처리합니다. 각 OPCODE가 처리 시 수신 매개변수의 유형을 결정해야 한다면 성능은 필연적으로 큰 문제가 될 것입니다(한 요청에서 처리해야 하는 OPCODE 수가 수천 개에 달할 수 있음). zend/zend_vm_def.h방법이 없을까요? 우리는 컴파일 타임에 각 피연산자의 유형(상수 또는 변수일 수 있음)을 이미 결정할 수 있다는 것을 발견했습니다. 따라서 PHP가 실제로 C 코드를 실행할 때 다양한 유형의 피연산자가 가상 머신에서 직접 호출할 수 있도록 다양한 함수로 구분됩니다. 이 코드 부분은 에 위치합니다. 확장된 파일이 꽤 크며,
if (IS_CONST == IS_CV) {와 같은 코드도 있다는 것을 발견했습니다. 전혀 말이 되지 않죠? 하지만 상관없습니다. C 컴파일러는 자동으로 이런 방식으로 최적화하고 판단합니다. 대부분의 경우 특정 OPCODE 처리 논리를 이해하려면 템플릿 파일
을 읽는 것이 더 쉽습니다. 그런데 템플릿을 기반으로 C 코드를 생성하는 프로그램은 PHP로 구현되어 있습니다.zend/zend_vm_execute.h실행 과정
정확히 말하면 PHP의 실행은 컴파일과 실행 두 부분으로 나누어집니다. 여기서는 컴파일 부분을 자세히 설명하지 않고 실행 프로세스에 중점을 둡니다. zend/zend_vm_def.h
struct _zend_op_array {
/* Common elements */
zend_uchar type;
zend_uchar arg_flags[3]; /* bitset of arg_info.pass_by_reference */
uint32_t fn_flags;
zend_string *function_name;
zend_class_entry *scope;
zend_function *prototype;
uint32_t num_args;
uint32_t required_num_args;
zend_arg_info *arg_info;
/* END of common elements */
uint32_t *refcount;
uint32_t last;
zend_op *opcodes;
int last_var;
uint32_t T;
zend_string **vars;
int last_live_range;
int last_try_catch;
zend_live_range *live_range;
zend_try_catch_element *try_catch_array;
/* static variables support */
HashTable *static_variables;
zend_string *filename;
uint32_t line_start;
uint32_t line_end;
zend_string *doc_comment;
uint32_t early_binding; /* the linked list of delayed declarations */
int last_literal;
zval *literals;
int cache_size;
void **run_time_cache;
void *reserved[ZEND_MAX_RESERVED_RESOURCES];
};OPCODE를 저장하는 배열.
opcodes 현재 실행 중인 스크립트의 파일명입니다.
filename 현재 실행 중인 메소드의 이름입니다.
function_name 정적 변수 목록입니다.
static_variables
last_try_catchtry_catch_array 문자열 foo 또는 숫자 23과 같은 모든 상수 리터럴의 모음입니다.
왜 이렇게 거대한 데이터를 생성해야 할까요? 컴파일하는 동안 생성되는 정보가 많을수록 실행하는 동안 필요한 시간이 줄어듭니다. literals
接下来，我们看下 PHP 是如何执行 OPCODE。OPCODE 的执行被放在一个大循环中，这个循环位于 zend/zend_vm_execute.h 中的 execute_ex 函数：
ZEND_API void execute_ex(zend_execute_data *ex)
{
DCL_OPLINE
zend_execute_data *execute_data = ex;
LOAD_OPLINE();
ZEND_VM_LOOP_INTERRUPT_CHECK();
while (1) {
if (UNEXPECTED((ret = ((opcode_handler_t)OPLINE->handler)(ZEND_OPCODE_HANDLER_ARGS_PASSTHRU)) != 0)) {
if (EXPECTED(ret > 0)) {
execute_data = EG(current_execute_data);
ZEND_VM_LOOP_INTERRUPT_CHECK();
} else {
return;
}
}
}
zend_error_noreturn(E_CORE_ERROR, "Arrived at end of main loop which shouldn't happen");
}这里，我去掉了一些环境变量判断分支，保留了运行的主流程。可以看到，在一个无限循环中，虚拟机会不断调用 OPCODE 指定的 handler 函数处理指令集，直到某次指令处理的结果 ret 小于0。注意到，在主流程中并没有移动 OPCODE 数组的当前指针，而是把这个过程放到指令执行的具体函数的结尾。所以，我们在大多数 OPCODE 的实现函数的末尾，都能看到调用这个宏：
ZEND_VM_NEXT_OPCODE_CHECK_EXCEPTION();
在之前那个简单例子中，我们看到 vld 打印出的执行 OPCODE 数组中，最后有一项指令为 ZEND_RETURN 的 OPCODE。但我们编写的 PHP 代码中并没有这样的语句。在编译时期，虚拟机会自动将这个指令加到 OPCODE 数组的结尾。ZEND_RETURN 指令对应的函数会返回 -1，判断执行的结果小于0时，就会退出循环，从而结束程序的运行。
如果我们调用一个自定义的函数，虚拟机会如何处理呢？
<?php
function foo() {
echo 'test';
}
foo();我们通过 vld 查看生成的 OPCODE。出现了两个 OPCODE 指令执行栈，是因为我们自定义了一个 PHP 函数。在第一个执行栈上，调用自定义函数会执行两个 OPCODE 指令：INIT_FC<a href="//m.sbmmt.com/wiki/1483.html" target="_blank">ALL</a> 和 DO_FCALL。
compiled vars: none
line
#* E I O op
fetch
ext return operands
-------------------------------------------------------------------------------------
2 0 E > NOP
6 1 INIT_FCALL 'foo'
2 DO_FCALL
0
3 > RETURN 1
compiled vars: none
line #* E I O op
fetch
ext
return
operands
-------------------------------------------------------------------------------------
3 0 E > ECHO 'test'
4 1 > RETURN null其中，INIT_FCALL 准备了执行函数时所需要的上下文数据。DO_FCALL 负责执行函数。DO_FCALL 的处理函数根据不同的调用情况处理了大量逻辑，我摘取了其中执行用户定义的函数的逻辑部分：
ZEND_VM_HANDLER(60, ZEND_DO_FCALL, ANY, ANY, SPEC(RETVAL))
{
USE_OPLINE
zend_execute_data *call = EX(call);
zend_function *fbc = call->func;
zend_object *object;
zval *ret;
...
if (EXPECTED(fbc->type == ZEND_USER_FUNCTION)) {
ret = NULL;
if (RETURN_VALUE_USED(opline)) {
ret = EX_VAR(opline->result.var);
ZVAL_NULL(ret);
}
call->prev_execute_data = execute_data;
i_init_func_execute_data(call, &fbc->op_array, ret);
if (EXPECTED(zend_execute_ex == execute_ex)) {
ZEND_VM_ENTER();
} else {
ZEND_ADD_CALL_FLAG(call, ZEND_CALL_TOP);
zend_execute_ex(call);
}
}
...
ZEND_VM_SET_OPCODE(opline + 1);
ZEND_VM_CONTINUE();
}可以看到，DO_FCALL 首先将调用函数前的上下文数据保存到 call->prev_execute_data，然后调用 i_init_func_execute_data 函数，将自定义函数对象中的 op_array（每个自定义函数会在编译的时候生成对应的数据，其数据结构中包含了函数的 OPCODE 数组） 赋值给新的执行上下文对象。
然后，调用 zend_execute_ex 函数，开始执行自定义的函数。zend_execute_ex 实际上就是前面提到的 execute_ex 函数（默认是这样，但扩展可能重写 zend_execute_ex 指针，这个 API 让 PHP 扩展开发者可以通过覆写函数达到扩展功能的目的，不是本篇的主题，不准备深入探讨），只是上下文数据被替换成当前函数所在的上下文数据。
我们可以这样理解，最外层的代码就是一个默认存在的函数（类似 C 语言中的 main()函数），和用户自定义的函数本质上是没有区别的。
我们知道指令都是顺序执行的，而我们的程序，一般都包含不少的逻辑判断和循环，这部分又是如何通过 OPCODE 实现的呢？
<?php
$a = 10;
if ($a == 10) {
echo 'success';
} else {
echo 'failure';
}我们还是通过 vld 查看 OPCODE（不得不说 vld 扩展是分析 PHP 的神器）。
compiled vars: !0 = $a
line #* E I O op
fetch ext return operands
-------------------------------------------------------------------------------------
2 0 E > ASSIGN !0, 10
3 1 IS_EQUAL
~2 !0, 10
2 > JMPZ ~2, ->5
4 3 > ECHO 'success'
4 > JMP ->6
6 5 > ECHO 'failure'
7 6 > > RETURN 1我们看到，JMPZ 和 JMP 控制了执行流程。JMP 的逻辑非常简单，将当前的 OPCODE 指针指向需要跳转的 OPCODE。
ZEND_VM_HANDLER(42, ZEND_JMP, JMP_ADDR, ANY)
{
USE_OPLINE
ZEND_VM_SET_OPCODE(OP_JMP_ADDR(opline, opline->op1));
ZEND_VM_CONTINUE();
}JMPZ 仅仅是多了一次判断，根据结果选择是否跳转，这里就不再重复列举了。而处理循环的方式与判断基本上是类似的。
<?php
$a = [1, 2, 3];
foreach ($a as $n) {
echo $n;
}compiled vars: !0 = $a, !1 = $n
line #* E I O op
fetch
ext return
operands
-------------------------------------------------------------------------------------
2 0 E > ASSIGN !0, <array>
3 1 > FE_RESET_R
$3 !0, ->5
2 > > FE_FETCH_R $3, !1, ->5
4 3 > ECHO !1
4 > JMP ->2
5 > FE_FREE $3
5 6 > RETURN 1循环只需要 JMP 指令即可完成，通过 FE_FETCH_R 指令判断是否已经到达数组的结尾，如果到达则退出循环。
通过了解 Zend 虚拟机，相信你对 PHP 是如何运行的，会有更深刻的理解。想到我们写的一行行代码，最后机器执行的时候会变成数不胜数的指令，每个指令又建立在复杂的处理逻辑之上。那些从前随意写下的代码，现在会不会在脑海里不自觉的转换成 OPCODE 再品味一番呢？
위 내용은 PHP 커널 분석 - Zend 가상 머신 상세 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
