PHP7 커널의 zval에 대한 심층적인 이해

PHP7이 출시되었습니다. 약속대로 이 시리즈의 글을 쓰기 시작하겠습니다. 오늘은 우리가 PHP7의 엄청난 성능 향상 뒤에 어떤 일을 했는지 알려드리고 싶습니다. zval의 변경 사항 zval의 변경 사항에 대해 이야기하기 전에 먼저 PHP5에서 zval이 어떻게 보이는지 살펴보겠습니다. zval은 다음과 같이 정의됩니다.

struct _zval_struct {
     union {
          long lval;
          double dval;
          struct {
               char *val;
               int len;
          } str;
          HashTable *ht;
          zend_object_value obj;
          zend_ast *ast;
     } value;
     zend_uint refcount__gc;
     zend_uchar type;
     zend_uchar is_ref__gc;
};

PHP5 커널을 아는 학생은 zval은 PHP의 모든 데이터 유형을 나타낼 수 있으므로 zval이 저장하는 값 유형을 나타내는 유형 필드를 포함하므로 이 구조에 대해 잘 알고 있어야 합니다. 일반적으로 가능한 옵션은 IS_NULL, IS_LONG, IS_STRING, IS_ARRAY, IS_OBJECT 등입니다. #🎜 🎜#유형 필드의 값에 따라 다른 방법을 사용해야 합니다. 값의 값을 해석합니다. 예를 들어 유형이 IS_STRING인 경우 value.str을 사용하여 해석해야 합니다. zval.value 필드이고 유형이 IS_LONG이면 value.lval을 사용하여 해석해야 합니다.#🎜 🎜#또한 PHP는 참조 카운팅을 사용하여 기본 가비지 수집을 수행한다는 것을 알고 있으므로 zval의 refcount__gc 필드는 이 zval에 대한 참조 개수를 나타내는데 여기서 설명할 것이 있습니다. 5.3 이전에는 이 필드의 이름을 5.3 이후에는 순환을 처리하기 위해 새로운 가비지 수집 알고리즘이 도입되었습니다. 참조 카운팅을 위해 저자는 오류가 더 빨리 나타나도록 하기 위해 refcount__gc로 이름을 바꾸었습니다.

마찬가지로 is_ref가 있습니다. . 이 값은 PHP의 유형이 참조인지 여부를 나타냅니다. 여기서는 참조가 플래그인지 여부를 확인할 수 있습니다.

이것은 2013년 PHP5의 opcache JIT 작업 당시의 zval입니다. , 실제 프로젝트에서는 JIT의 성능이 좋지 않았기 때문에 이 구조에 많은 문제가 있음을 깨달았습니다. 그리고 PHPNG 프로젝트는 이 구조를 다시 작성하여 시작되었습니다. 🎜🎜#

PHP5의 zval 정의는 Zend Engine 2에서 탄생했는데, 시간이 지날수록 당시 디자인의 한계는 점점 더 뚜렷해졌습니다.

우선 크기가 이 구조는 (64비트 시스템에서) 24바이트입니다. 이 zval .value 공용체를 자세히 살펴보겠습니다. 그 중 zend_object_value는 가장 큰 긴 보드이므로 전체 값은 16바이트가 필요합니다. 결국 IS_OBJECT는 가장 일반적으로 사용되는 유형이 아니기 때문입니다.

둘째, 이 구조의 각 필드에는 명확한 의미가 있으며, 사용자 정의 필드가 예약되어 있지 않아 PHP5 시대에 많은 최적화가 이루어졌습니다. zval과 관련된 일부 정보를 저장해야 하는 경우 zval을 확장하기 위해 다른 구조 매핑이나 외부 패키징 및 패치를 사용해야 합니다. 5.3에서는 순환 참조를 해결하기 위해 새로운 GC가 도입되었습니다. 다음 비교 해킹 방법을 사용하면 안 됩니다:

/* The following macroses override macroses from zend_alloc.h */
#undef  ALLOC_ZVAL
#define ALLOC_ZVAL(z)                                   \
    do {                                                \
        (z) = (zval*)emalloc(sizeof(zval_gc_info));     \
        GC_ZVAL_INIT(z);                                \
    } while (0)
它用zval_gc_info劫持了zval的分配:
typedef struct _zval_gc_info {
    zval z;
    union {
        gc_root_buffer       *buffered;
        struct _zval_gc_info *next;
    } u;
} zval_gc_info;

그런 다음 zval_gc_info를 사용하여 zval을 확장하므로 실제로 PHP5에서 zval을 적용할 때 시대에는 실제로 32바이트를 할당하지만 실제로 GC는 IS_ARRAY 및 IS_OBJECT 유형에만 관심이 필요하므로 많은 메모리 낭비가 발생합니다.

또한 이전에 만든 Taint 확장과 마찬가지로 필요합니다. 일부 문자열에 대한 일부 태그를 저장하려고 하는데 zval에 사용할 수 있는 공간이 없기 때문에 특별한 방법을 사용해야 했습니다.

Z_STRVAL_PP(ppzval) = erealloc(Z_STRVAL_PP(ppzval), Z_STRLEN_PP(ppzval) + 1 + PHP_TAINT_MAGIC_LENGTH);
PHP_TAINT_MARK(*ppzval, PHP_TAINT_MAGIC_POSSIBLE);

은 문자열 길이를 int만큼 확장하는 것입니다. 그런 다음 마법의 숫자로 표시하고 뒷면에 ​​씁니다. 이 접근 방식은 기술적으로 더 안전하고 안정적입니다. 보장 없음

셋째, 대부분의 PHP zval은 값으로 전달되며 값은 다음과 같습니다. 그러나 개체와 리소스라는 두 가지 예외가 있습니다. 이는 항상 참조로 전달되므로 zval의 참조 카운트 외에도 개체와 리소스에는 메모리가 필요합니다. 따라서 PHP5 시대에는 객체를 예로 들면 두 세트의 참조 카운트가 있습니다. 하나는 zval에 있고 다른 하나는 obj 자체의 카운트입니다. 위에서 언급한 두 가지 참조 세트 외에도 객체를 얻으려면 다음을 수행해야 합니다. #🎜 🎜#

typedef struct _zend_object_store_bucket {
    zend_bool destructor_called;
    zend_bool valid;
    union _store_bucket {
        struct _store_object {
            void *object;
            zend_objects_store_dtor_t dtor;
            zend_objects_free_object_storage_t free_storage;
            zend_objects_store_clone_t clone;
            const zend_object_handlers *handlers;
            zend_uint refcount;
            gc_root_buffer *buffered;
        } obj;
        struct {
            int next;
        } free_list;
    } bucket;
} zend_object_store_bucket;

길고 많은 메모리 읽기 후에 실제 객체 객체 자체는 다음과 같습니다. 효율성은 상상할 수 있습니다.

이 모든 것은 Zend 엔진의 초기 설계 때문입니다. 좋은 설계는 일단 사고가 발생하면 전체를 유발합니다.

Fourth , 우리는 PHP에서 많은 계산이 문자열 중심이라는 것을 알고 있습니다. 그러나 참조 카운팅이 zval에 적용되기 때문에 결과적으로 문자열 유형의 zval을 복사하려면 문자를 복사하는 것 외에 다른 방법이 없습니다. zval 문자열을 배열에 키로 추가하면 복사하는 것 외에는 다른 방법이 없습니다. PHP5.4에서는 INTERNED STRING을 도입했지만 여전히 이 문제를 근본적으로 해결할 수 없습니다.

예를 들어 PHP의 많은 구조는 Hashtable을 기반으로 구현됩니다. Hashtable을 추가, 삭제, 수정, 확인하는 작업은 CPU 시간을 많이 소모하며, 먼저 문자열을 검색하려면 Hash 값이 필요합니다. 이론적으로는 문자열의 Hash 값을 계산한 후 저장하여 다시 계산하지 않아도 됩니다#🎜🎜 #

第五, 这个是关于引用的, PHP5的时代, 我们采用写时分离, 但是结合到引用这里就有了一个经典的性能问题:

<?php
 
    function dummy($array) {}
 
    $array = range(1, 100000);
 
    $b = &$array;
 
    dummy($array);
?>

当我们调用dummy的时候, 本来只是简单的一个传值就行的地方, 但是因为$array曾经引用赋值给了$b, 所以导致$array变成了一个引用, 于是此处就会发生分离, 导致数组复制, 从而极大的拖慢性能, 这里有一个简单的测试:

<?php
$array = range(1, 100000);
 
function dummy($array) {}
 
$i = 0;
$start = microtime(true);
while($i++ < 100) {
    dummy($array);
}
 
printf("Used %sS\n", microtime(true) - $start);
 
$b = &$array; //注意这里, 假设我不小心把这个Array引用给了一个变量
$i = 0;
$start = microtime(true);
while($i++ < 100) {
    dummy($array);
}
printf("Used %ss\n", microtime(true) - $start);
?>

我们在5.6下运行这个例子, 得到如下结果:

$ php-5.6/sapi/cli/php /tmp/1.php
Used 0.00045204162597656s
Used 4.2051479816437s

相差1万倍之多. 这就造成, 如果在一大段代码中, 我不小心把一个变量变成了引用(比如foreach as &$v), 那么就有可能触发到这个问题, 造成严重的性能问题, 然而却又很难排查.

第六, 也是最重要的一个, 为什么说它重要呢? 因为这点促成了很大的性能提升, 我们习惯了在PHP5的时代调用MAKE_STD_ZVAL在堆内存上分配一个zval, 然后对他进行操作, 最后呢通过RETURN_ZVAL把这个zval的值”copy”给return_value, 然后又销毁了这个zval, 比如pathinfo这个函数:

PHP_FUNCTION(pathinfo)
{
.....
     MAKE_STD_ZVAL(tmp);
     array_init(tmp);
.....
 
    if (opt == PHP_PATHINFO_ALL) {
        RETURN_ZVAL(tmp, 0, 1);
    } else {
.....
}

这个tmp变量, 完全是一个临时变量的作用, 我们又何必在堆内存分配它呢? MAKE_STD_ZVAL/ALLOC_ZVAL在PHP5的时候, 到处都有, 是一个非常常见的用法, 如果我们能把这个变量用栈分配, 那无论是内存分配, 还是缓存友好, 都是非常有利的

还有很多, 我就不一一详细列举了, 但是我相信你们也有了和我们当时一样的想法, zval必须得改改了, 对吧?

现在的zval

到了PHP7中, zval变成了如下的结构, 要说明的是, 这个是现在的结构, 已经和PHPNG时候有了一些不同了, 因为我们新增加了一些解释 (联合体的字段), 但是总体大小, 结构, 是和PHPNG的时候一致的:

struct _zval_struct {
     union {
          zend_long         lval;             /* long value */
          double            dval;             /* double value */
          zend_refcounted  *counted;
          zend_string      *str;
          zend_array       *arr;
          zend_object      *obj;
          zend_resource    *res;
          zend_reference   *ref;
          zend_ast_ref     *ast;
          zval             *zv;
          void             *ptr;
          zend_class_entry *ce;
          zend_function    *func;
          struct {
               uint32_t w1;
               uint32_t w2;
          } ww;
     } value;
    union {
        struct {
            ZEND_ENDIAN_LOHI_4(
                zend_uchar    type,         /* active type */
                zend_uchar    type_flags,
                zend_uchar    const_flags,
                zend_uchar    reserved)     /* call info for EX(This) */
        } v;
        uint32_t type_info;
    } u1;
    union {
        uint32_t     var_flags;
        uint32_t     next;                 /* hash collision chain */
        uint32_t     cache_slot;           /* literal cache slot */
        uint32_t     lineno;               /* line number (for ast nodes) */
        uint32_t     num_args;             /* arguments number for EX(This) */
        uint32_t     fe_pos;               /* foreach position */
        uint32_t     fe_iter_idx;          /* foreach iterator index */
    } u2;
};

虽然看起来变得好大, 但其实你仔细看, 全部都是联合体, 这个新的zval在64位环境下,现在只需要16个字节(2个指针size), 它主要分为俩个部分, value和扩充字段, 而扩充字段又分为u1和u2俩个部分, 其中u1是type info, u2是各种辅助字段.

其中value部分, 是一个size_t大小(一个指针大小), 可以保存一个指针, 或者一个long, 或者一个double.

而type info部分则保存了这个zval的类型. 扩充辅助字段则会在多个其他地方使用, 比如next, 就用在取代Hashtable中原来的拉链指针, 这部分会在以后介绍HashTable的时候再来详解.

类型

PHP7中的zval的类型做了比较大的调整, 总体来说有如下17种类型:

/* regular data types */
#define IS_UNDEF                    0
#define IS_NULL                     1
#define IS_FALSE                    2
#define IS_TRUE                     3
#define IS_LONG                     4
#define IS_DOUBLE                   5
#define IS_STRING                   6
#define IS_ARRAY                    7
#define IS_OBJECT                   8
#define IS_RESOURCE                 9
#define IS_REFERENCE                10
 
/* constant expressions */
#define IS_CONSTANT                 11
#define IS_CONSTANT_AST             12
 
/* fake types */
#define _IS_BOOL                    13
#define IS_CALLABLE                 14
 
/* internal types */
#define IS_INDIRECT                 15
#define IS_PTR                      17

其中PHP5的时候的IS_BOOL类型, 现在拆分成了IS_FALSE和IS_TRUE俩种类型. 而原来的引用是一个标志位, 现在的引用是一种新的类型.

对于IS_INDIRECT和IS_PTR来说, 这俩个类型是用在内部的保留类型, 用户不会感知到, 这部分会在后续介绍HashTable的时候也一并介绍.

从PHP7开始, 对于在zval的value字段中能保存下的值, 就不再对他们进行引用计数了, 而是在拷贝的时候直接赋值, 这样就省掉了大量的引用计数相关的操作, 这部分类型有:

IS_LONG
IS_DOUBLE

当然对于那种根本没有值, 只有类型的类型, 也不需要引用计数了:

IS_NULL
IS_FALSE
IS_TRUE

而对于复杂类型, 一个size_t保存不下的, 那么我们就用value来保存一个指针, 这个指针指向这个具体的值, 引用计数也随之作用于这个值上, 而不在是作用于zval上了.

PHP7 zval示意图

以IS_ARRAY为例:

struct _zend_array {
    zend_refcounted_h gc;
    union {
        struct {
            ZEND_ENDIAN_LOHI_4(
                zend_uchar    flags,
                zend_uchar    nApplyCount,
                zend_uchar    nIteratorsCount,
                zend_uchar    reserve)
        } v;
        uint32_t flags;
    } u;
    uint32_t          nTableMask;
    Bucket           *arData;
    uint32_t          nNumUsed;
    uint32_t          nNumOfElements;
    uint32_t          nTableSize;
    uint32_t          nInternalPointer;
    zend_long         nNextFreeElement;
    dtor_func_t       pDestructor;
};

zval.value.arr将指向上面的这样的一个结构体, 由它实际保存一个数组, 引用计数部分保存在zend_refcounted_h结构中:

typedef struct _zend_refcounted_h {
    uint32_t         refcount;          /* reference counter 32-bit */
    union {
        struct {
            ZEND_ENDIAN_LOHI_3(
                zend_uchar    type,
                zend_uchar    flags,    /* used for strings & objects */
                uint16_t      gc_info)  /* keeps GC root number (or 0) and color */
        } v;
        uint32_t type_info;
    } u;
} zend_refcounted_h;

所有的复杂类型的定义, 开始的时候都是zend_refcounted_h结构, 这个结构里除了引用计数以外, 还有GC相关的结构. 从而在做GC回收的时候, GC不需要关心具体类型是什么, 所有的它都可以当做zend_refcounted*结构来处理.

另外有一个需要说明的就是大家可能会好奇的ZEND_ENDIAN_LOHI_4宏, 这个宏的作用是简化赋值, 它会保证在大端或者小端的机器上, 它定义的字段都按照一样顺序排列存储, 从而我们在赋值的时候, 不需要对它的字段分别赋值, 而是可以统一赋值, 比如对于上面的array结构为例, 就可以通过:

arr1.u.flags = arr2.u.flags;

一次完成相当于如下的赋值序列:

arr1.u.v.flags                    = arr2.u.v.flags;
arr1.u.v.nApplyCount           = arr2.u.v.nApplyCount;
arr1.u.v.nIteratorsCount     = arr2.u.v.nIteratorsCount;
arr1.u.v.reserve                = arr2.u.v.reserve;

还有一个大家可能会问到的问题是, 为什么不把type类型放到zval类型的前面, 因为我们知道当我们去用一个zval的时候, 首先第一点肯定是先去获取它的类型. 这里的一个原因是, 一个是俩者差别不大, 另外就是考虑到如果以后JIT的话, zval的类型如果能够通过类型推导获得, 就根本没有必要去读取它的type值了.

标志位

除了数据类型以外， 以前的经验也告诉我们， 一个数据除了它的类型以外， 还应该有很多其他的属性， 比如对于INTERNED STRING，它是一种在整个PHP请求期都存在的字符串(比如你写在代码中的字面量), 它不会被引用计数回收. 在5.4的版本中我们是通过预先申请一块内存， 然后再这个内存中分配字符串， 最后用指针地址来比较， 如果一个字符串是属于INTERNED STRING的内存范围内， 就认为它是INTERNED STRING. 这样做的缺点显而易见， 就是当内存不够的时候， 我们就没有办法分配INTERNED STRING了， 另外也非常丑陋， 所以如果一个字符串能有一些属性定义则这个实现就可以变得很优雅.

还有， 比如现在我们对于IS_LONG, IS_TRUE等类型不再进行引用计数了， 那么当我们拿到一个zval的时候如何判断它需要不需要引用计数呢？ 想当然的我们可能会说用:

if (Z_TYPE_P(zv) >= IS_STRING) {
  //需要引用计数
}

但是你忘了， 还有INTERNED STRING的存在啊， 所以你也许要这么写了：

if (Z_TYPE_P(zv) >= IS_STRING && !IS_INTERNED(Z_STR_P(zv))) {
  //需要引用计数
}

是不是已经让你感觉到有点不对劲了? 嗯，别急， 还有呢， 我们还在5.6的时候引入了常量数组， 这个数组呢会存储在Opcache的共享内存中， 它也不需要引用计数：

if (Z_TYPE_P(zv) >= IS_STRING && !IS_INTERNED(Z_STR_P(zv))
    && (Z_TYPE_P(zv) != IS_ARRAY || !Z_IS_IMMUTABLE(Z_ARRVAL(zv)))) {
 //需要引用计数
}

你是不是也觉得这简直太丑陋了， 简直不能忍受这样墨迹的代码， 对吧？

是的，我们早想到了，回头看之前的zval定义， 注意到type_flags了么? 我们引入了一个标志位， 叫做IS_TYPE_REFCOUNTED, 它会保存在zval.u1.v.type_flags中， 我们对于需要引用计数的类型就赋予这个标志， 所以上面的判断就可以变得很优雅：

if (!(Z_TYPE_FLAGS(zv) & IS_TYPE_REFCOUNTED)) {
}

而对于INTERNED STRING来说， 这个IS_STR_INTERNED标志位应该是作用于字符串本身而不是zval的.

那么类似这样的标志位一共有多少呢？作用于zval的有：

IS_TYPE_CONSTANT            //是常量类型
IS_TYPE_IMMUTABLE           //不可变的类型， 比如存在共享内存的数组
IS_TYPE_REFCOUNTED          //需要引用计数的类型
IS_TYPE_COLLECTABLE         //可能包含循环引用的类型(IS_ARRAY, IS_OBJECT)
IS_TYPE_COPYABLE            //可被复制的类型， 还记得我之前讲的对象和资源的例外么？ 对象和资源就不是
IS_TYPE_SYMBOLTABLE         //zval保存的是全局符号表， 这个在我之前做了一个调整以后没用了， 但还保留着兼容，
                            //下个版本会去掉

作用于字符串的有:

IS_STR_PERSISTENT             //是malloc分配内存的字符串
IS_STR_INTERNED             //INTERNED STRING
IS_STR_PERMANENT            //不可变的字符串， 用作哨兵作用
IS_STR_CONSTANT             //代表常量的字符串
IS_STR_CONSTANT_UNQUALIFIED //带有可能命名空间的常量字符串

作用于数组的有:

#define IS_ARRAY_IMMUTABLE  //同IS_TYPE_IMMUTABLE

作用于对象的有：

IS_OBJ_APPLY_COUNT          //递归保护
IS_OBJ_DESTRUCTOR_CALLED    //析构函数已经调用
IS_OBJ_FREE_CALLED          //清理函数已经调用
IS_OBJ_USE_GUARDS           //魔术方法递归保护
IS_OBJ_HAS_GUARDS           //是否有魔术方法递归保护标志

有了这些预留的标志位， 我们就会很方便的做一些以前不好做的事情， 就比如我自己的Taint扩展， 现在把一个字符串标记为污染的字符串就会变得无比简单：

/* it's important that make sure
 * this value is not used by Zend or
 * any other extension agianst string */
#define IS_STR_TAINT_POSSIBLE    (1<<7)
#define TAINT_MARK(str)     (GC_FLAGS((str)) |= IS_STR_TAINT_POSSIBLE)

这个标记就会一直随着这个字符串的生存而存在的， 省掉了我之前的很多tricky的做法.

zval预先分配

前面我们说过, PHP5的zval分配采用的是堆上分配内存, 也就是在PHP预案代码中随处可见的MAKE_STD_ZVAL和ALLOC_ZVAL宏. 我们也知道了本来一个zval只需要24个字节, 但是算上gc_info, 其实分配了32个字节, 再加上PHP自己的内存管理在分配内存的时候都会在内存前面保留一部分信息:

typedef struct _zend_mm_block {
    zend_mm_block_info info;
#if ZEND_DEBUG
    unsigned int magic;
# ifdef ZTS
    THREAD_T thread_id;
# endif
    zend_mm_debug_info debug;
#elif ZEND_MM_HEAP_PROTECTION
    zend_mm_debug_info debug;
#endif
} zend_mm_block;

从而导致实际上我们只需要24字节的内存, 但最后竟然分配48个字节之多.

然而大部分的zval, 尤其是扩展函数内的zval, 我们想想它接受的参数来自外部的zval, 它把返回值返回给return_value, 这个也是来自外部的zval, 而中间变量的zval完全可以采用栈上分配. 也就是说大部分的内部函数都不需要在堆上分配内存, 它需要的zval都可以来自外部.

于是当时我们做了一个大胆的想法, 所有的zval都不需要单独申请.

而这个也很容易证明, PHP脚本中使用的zval, 要么存在于符号表, 要么就以临时变量(IS_TMP_VAR)或者编译变量(IS_CV)的形式存在. 前者存在于一个Hashtable中, 而在PHP7中Hashtable默认保存的就是zval, 这部分的zval完全可以在Hashtable分配的时候一次性分配出来, 后面的存在于execute_data之后, 数量也在编译时刻确定好了, 也可以随着execute_data一次性分配, 所以我们确实不再需要单独在堆上申请zval了.

所以, 在PHP7开始, 我们移除了MAKE_STD_ZVAL/ALLOC_ZVAL宏, 不再支持存堆内存上申请zval. 函数内部使用的zval要么来自外面输入, 要么使用在栈上分配的临时zval.

在后来的实践中, 总结出来的可能对于开发者来说最大的变化就是, 之前的一些内部函数, 通过一些操作获得一些信息, 然后分配一个zval, 返回给调用者的情况:

static zval * php_internal_function() {
    .....
    str = external_function();
 
    MAKE_STD_ZVAL(zv);
 
    ZVAL_STRING(zv, str, 0);
 
     return zv;
}
PHP_FUNCTION(test) {
     RETURN_ZVAL(php_internal_function(), 1, 1);
}

要么修改为, 这个zval由调用者传递:

static void php_internal_function(zval *zv) {
    .....
    str = external_function();
 
    ZVAL_STRING(zv, str);
     efree(str);
}
 
PHP_FUNCTION(test) {
     php_internal_function(return_value);
}

要么修改为, 这个函数返回原始素材:

static char * php_internal_function() {
    .....
    str = external_function();
     return str;
}
 
PHP_FUNCTION(test) {
     str = php_internal_function();
     RETURN_STRING(str);
     efree(str);
}

总结

(아직 어떻게 말해야할지 모르겠습니다. 원래는 zval**이 Hashtable에 더 이상 존재하지 않는다는 사실을 소개하고 참조 유형의 존재 필요성을 소개하고 싶었습니다. 그러나 그렇지 않으면 먼저 Hashtable의 구조에 대해 이야기하면 이 소개는 매우 갑작스러운 것 같습니다. 먼저, 나중에 수정하겠습니다.)

이제 우리는 기본적으로 zval의 변경 사항을 추상화했습니다. PHP7은 원래 값을 저장하거나 원래 값을 가리키는 포인터를 저장하는 값 포인터가 되었습니다. 즉, 현재 zval은 PHP5의 zval *과 동일하지만 zval *에 비해 zval은 직접 저장됩니다. , 포인터 역참조를 저장하여 캐시 친화성을 향상시킬 수 있습니다.

사실 PHP7 성능에 대한 새로운 기술 모델을 도입한 적은 없지만, 주로 지속적인 메모리 사용량 감소, 캐시 친화성 향상, 실행되는 명령 수를 줄입니다. PHP7의 리팩토링은 이 세 가지 원칙을 기반으로 합니다.

위 내용은 PHP7 커널의 zval에 대한 심층적인 이해의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!