PHP 8.4：ZVAL 的减肥狂想曲 —— 从 16 字节到 12 字节的物理重排
各位好！欢迎来到本次的“内核极客”内部讲座。
今天我们不聊业务逻辑，不聊 foreach 的性能，我们要聊点更硬核的——内存。具体来说，我们要聊 PHP 引擎中那个最核心、最频繁被触碰的胖子——zval 结构体。
众所周知，PHP 8.1 把 zval 的体重从之前的 24 字节（在 64 位系统上）狂暴地减到了 16 字节。这是 PHP 历史上一次伟大的减肥运动，就像是一个大腹便便的程序员突然决定去跑马拉松。
但如果你以为 PHP 8.1 的优化就到头了，那你可能低估了 Zend 引擎团队的毅力。现在，坐在我们面前的 PHP 8.4，正憋着一口气，准备把 zval 的体重再往下压一压，目标是从 16 字节瘦身至 12 字节。
这不仅仅是减掉 4 个字节的问题，这是在 CPU 缓存行的边缘疯狂试探，是一场关于位操作、内存对齐和物理重排的物理实验。
准备好了吗？让我们把显微镜打开，看看这个 12 字节的小家伙到底是怎么炼成的。
第一部分：16 字节的“黄金时代”
在深入 8.4 之前，我们得先膜拜一下 PHP 8.1 的杰作。在 PHP 8.1 之前，zval 是一个 24 字节的怪兽。它结构臃肿，充满了冗余。
PHP 8.1 狠心地将它切成了 16 字节。我们来回顾一下当时的结构（为了叙述方便，我简化了部分字段）：
typedef struct _zend_value {
union {
uint64_t lval; // 整数
double dval; // 浮点数
} u;
zend_refcounted *counted; // 指向实际数据的指针（对象、字符串、数组）
} zend_value;等等，这里有个坑！
看到 zend_refcounted *counted 了吗？这是一个指针，在 64 位系统上，指针本身占了 8 个字节。而前面的 union u 最多也就是 8 个字节。
这意味着什么？意味着无论 zval 里存的是什么（是整数 1，还是字符串 "hello"），这个指针字段永远是存在的。哪怕你存的是 null，那个指针依然在那里占用 8 字节。
这就好比你买了一个外卖盒（zval），不管你往里面装的是炸鸡（字符串）、牛排（对象）还是空气（NULL），那个印着“XX 传媒”的包装纸（指针）永远贴在盒盖上。
第二部分：缓存行的诅咒
为什么我们要纠结这 4 个字节？
这就不得不提计算机科学的恶梦——缓存未命中。
在 64 位系统上，CPU 的 L1 缓存行通常是 64 字节。这意味着 CPU 每次从内存读取数据时，都会抓取 64 字节的一块区域。
想象一下，如果你有一个数组，里面有 100 个元素，每个元素是一个 zval。
- 旧版 (24 字节)：内存里是
[zval1][zval2][zval3]...[zval3][空余][空余]...。CPU 读取时，虽然zval1到zval3读完了，但还得把后面一大堆垃圾（空余空间）读进来。 - PHP 8.1 (16 字节)：
[zval1][zval2][zval3][zval4]...[zval4][zval5][zval5]...
虽然紧凑了，但在 64 字节的缓存行边界处，仍然存在大量的“浪费”。如果我们能把 zval 变成 12 字节，那么理论上，在同一个缓存行里，我们能塞进 5 个 zval，而不是 4 个。这对于处理大型数组、哈希表来说，是巨大的性能提升。
第三部分：8.4 的激进策略——“偷梁换柱”
那么，PHP 8.4 是怎么把 16 字节变成 12 字节的呢？我们要面对一个物理学上的难题：如果去掉了那个 8 字节的指针，我怎么知道这个 zval 里存的是什么类型？
如果 zval 里没有指针，那存整数 12345 时，数据去哪了？是挤在 zval 结构体里吗？那太浪费了，因为字符串和数组可能很大。
所以，PHP 8.4 采用了一个听起来像魔术师手法，实则是底层工程学的方案：复用引用计数指针。
这个方案的核心在于 zend_refcounted。原来的设计里，counted 指针直接指向数据。但在新设计中，这个指针被打包了。
这里涉及到一个概念叫 RC 指针。一个 RC 指针既包含了指向数据的地址，也包含了引用计数。
- 假设：我们使用 32 位的引用计数（足以满足绝大多数 PHP 场景），那么一个指针占 32 位。
- 操作：我们将这个指针的低位用于存储数据指针，高位用于存储引用计数。
但这还不够，因为 zval 需要知道“我是整数还是字符串”。这需要一个类型标记。
PHP 8.4 的结构体重排极其精妙，它不再像以前那样使用一个显式的 u.type 字段。相反，它通过位运算从不同的字段中提取类型信息。
让我们看看现在的雏形（基于 RFC 1131 及后续更新）：
typedef struct _zend_value {
// 这是一个联合体，用于存放具体值
union {
uint64_t lval; // 整数
double dval; // 浮点数
zend_refcounted *counted; // 对象、字符串、数组
} value;
// 关键变化：不再是一个独立的 type 字段，而是通过掩码从 value 或其他字段提取类型
uint32_t u1.type_info;
} zend_value;等等，这不是还是 16 字节吗？
没错，如果只是这样改，它还是 16 字节。真正的瘦身在于：u1.type_info 不再占用一个独立的 8 字节空间，而是从 counted 指针或者通过特殊的位域操作复用空间。
实际上，在 8.4 的最终设计中，zend_value 被重构为一个更紧凑的结构。我们来看一个更具体的 12 字节版结构体示例（为了演示原理，省略了 GC 等复杂逻辑）：
typedef struct _zend_value {
// 1. 值域（8字节）
union {
uint64_t lval;
double dval;
struct {
uint64_t count : 32; // 引用计数 (从指针的高位借位)
uint64_t ptr : 32; // 实际数据的指针 (从指针的低位借位)
} v;
} u;
// 2. 类型与标志（4字节）
// 注意：这里不是独立的 type，而是通过位操作嵌入的
uint32_t type_info;
} zend_value;这算什么？这不还是 12 字节吗？ 是的，但我们省下的空间不仅仅是字节本身，更是缓存行的填充。
第四部分：位操作的艺术
要理解为什么这能行，我们必须看懂那个神秘的 type_info 和位域 u.v。
在 64 位系统上，一个指针占 8 字节。PHP 8.4 引入了 ZEND_TYPE_INFO 这个宏，它把类型信息塞进了 u1 或 u2 的特定位置。
让我们看一段代码，模拟 PHP 8.4 内部是如何判断一个 zval 是字符串的：
// 假设我们有一个 zval 变量 z
zval z;
// 假设我们把一个字符串 "foo" 放进去
zend_string *str = zend_string_init("foo", 3, 0);
ZVAL_STR(&z, str);
// 旧版本 (PHP 8.1) 的判断方式
// if (z.value.counted->type == IS_STRING) { ... }
// 新版本 (PHP 8.4) 的判断方式（伪代码，展示位运算逻辑）
void check_type(zval *z) {
// 获取 type_info 字段
uint32_t type = z->type_info & ZEND_TYPE_MASK;
if (type == IS_STRING) {
// 我们需要获取实际的字符串指针
// 注意：在 8.4 中，counted 指针被“拆解”了
uint64_t counted_ptr = z->value.u.v.ptr;
// 原始的 counted 结构体可能就在 counted_ptr 指向的地方
// 但因为内存布局变了，我们需要通过 RC 指针来反向推导
zend_string *s = (zend_string *) (counted_ptr | z->value.u.v.count);
printf("It's a string: %sn", s->val);
} else {
printf("Not a stringn");
}
}看懂了吗？这就是物理重排。我们将“引用计数”和“数据指针”合二为一，变成了一个 64 位的整数。我们在运行时通过“截断”和“拼接”来还原这个指针。
这就好比，原本你需要一个信封（指针）和一个信纸（引用计数），现在你把它们揉成一个纸团（64位整数）。当你需要写信时，你只需要把它展开。
第五部分：从 16 到 12 的物理映射
让我们更直观地对比一下内存布局。
场景 A：PHP 8.1 (16 字节)
+----------------+----------------+----------------+----------------+
| value | value | counted | counted | <- 16 字节
| (8 bytes, val) | (8 bytes, val) | (8 bytes, ptr) | (8 bytes, ptr) |
+----------------+----------------+----------------+----------------+注意，这里的 counted 和 value 是两个独立的 64 位槽位。哪怕你存整数，counted 也是空的（或者存了一个空指针），但它依然占据 8 字节的物理内存。
场景 B：PHP 8.4 (12 字节 + 隐式扩展)
+----------------+----------------+----------------+----------------+
| value | value | type_info | type_info | <- 16 字节对齐 (Padding)
| (8 bytes, val) | (4 bytes, val) | (4 bytes, info)| (4 bytes, info)|
+----------------+----------------+----------------+----------------+等等，这不对。如果它变成了 12 字节，那它如何适应 64 字节的缓存行？
真正的真相是： zval 的结构体大小可能还是 16 字节（为了兼容性），但是它使用的物理空间从 16 字节变成了 12 字节。剩下的 4 个字节被用来对齐，或者被新的字段（比如 gchandle，用于 WebGL/图像处理）填充。
或者，在某些极端优化的路径下，它确实是 12 字节。如果是 12 字节，它的内存布局是这样的：
// 实际上，8.4 的实现可能更倾向于保持 16 字节对齐，但减少内存消耗
// 让我们看看 RFC 中的具体描述：
typedef struct _zend_value {
union {
uint64_t lval;
double dval;
struct {
uint32_t count;
uint32_t ptr;
} v;
} u;
uint32_t type_info;
} zend_value;总共：8 + 4 + 4 = 16 字节。
但是！ 仔细看 u 结构体。它把 64 位整数拆分成了两个 32 位整数。
这有什么用？这允许编译器更好地进行对齐。
如果我们将 zval 放入一个数组：
- 在 8.1 中，数组里的每一个
zval都有一个 8 字节的指针槽位（counted）。 - 在 8.4 中，那个指针槽位被“压缩”了。如果引用计数很小（比如 1），它可能就只占 1 字节，或者利用
type_info中的空闲位。
最激进的观点： PHP 8.4 的目标实际上是移除 8 字节的独立指针槽位。
即，zval 的大小从 16 字节变成了 12 字节。
typedef struct _zend_value {
union {
uint64_t lval;
double dval;
struct {
uint32_t count; // 这里嵌入了指针的高32位
uint32_t ptr; // 这里嵌入了指针的低32位
} v;
} u;
uint32_t type_info;
} zend_value;
// 这种写法在某些编译器下可能变成 16 字节，但在底层物理上，它不再需要额外的 aligned storage 来容纳一个 8 字节指针。第六部分：代码演示——看，它变小了！
让我们写一段 PHP 代码，然后反汇编看看（虽然我们不能真反汇编，但我们可以模拟内存分析）。
假设我们执行以下代码：
<?php
$arr = [];
for ($i = 0; $i < 10; $i++) {
$arr[] = $i * 1000; // 存入整数
}PHP 8.1 的内存足迹：
对于数组中的每一个元素，PHP 8.1 分配了：
zval结构体（16 字节）。- HashTable 的桶（8 字节，存储索引和指针）。
- 指向
zval的指针。
PHP 8.4 的内存足迹：
对于数组中的每一个元素，PHP 8.4 分配了：
zval结构体（12 字节）。- HashTable 的桶（8 字节）。
- 指向
zval的指针。
节省了 4 字节！
听起来不多？但在 PHP 这种脚本语言中，内存往往是瓶颈。如果是一个包含 100 万个 zval 的大型数组，PHP 8.4 将节省约 4MB 的内存（仅 zval 本身，不计数据）。配合 64 字节的缓存行，这意味着内存带宽利用率提升了 25%！
第七部分：技术深潜——Type Unions
这是 8.4 最酷炫的技术点之一：联合体的位域化。
在旧版中，如果类型是 IS_STRING，value 中存的是 double；如果类型是 IS_LONG，value 中存的是 lval。
在 8.4 中，为了进一步压缩，zval 的设计变得更加“特务化”。
typedef struct _zval_struct {
zend_value value;
uint32_t type_info;
} zval;
typedef struct _zend_value {
// 如果是整数
uint64_t lval;
// 如果是浮点数
double dval;
// 如果是对象/字符串/数组
zend_refcounted *counted;
} zend_value;为了从 16 字节变成 12 字节，8.4 引入了 zend_string 和 zend_array 的“栈分配”或者“小对象池”策略。
但这只是辅助。
真正的魔法在于 type_info 字段。在 8.1 中，type_info 有 8 位用于类型，还有 24 位用于标志。
在 8.4 中，这些位被重新洗牌了。例如，ZEND_TYPE_IS_NULL 这种极端情况，可能不再需要完整的类型检查，而是通过指针的值来判断。
代码示例：类型判断的“神级操作”
static zend_always_inline zend_object* obj_from_zval(zval *z) {
// 在 PHP 8.4 中，我们可能不需要显式的类型检查字段
// 因为如果 u.v.ptr 的某些位为 0，或者特定的模式，我们就知道它是对象。
// 这是一个非常激进的假设示例：
// 假设我们将指针的高位用作类型编码
uint64_t data = z->value.u.v.ptr;
uint64_t refcount = z->value.u.v.count;
// 解码类型
// 假设最高位是类型标志
if (data & (1ULL << 63)) {
return (zend_object*)data;
}
// 如果不是对象，可能是整数或浮点数
// 这里省略了详细逻辑，展示概念
return NULL;
}第八部分：性能测试与模拟
为了让你们信服，我们来做一个（模拟的）性能对比。
假设我们有一个函数，遍历 100 万个 zval，并打印出它们的类型。
PHP 8.1 (16 字节 ZVAL):
- CPU L1 缓存加载：1 次（64 字节）。
- 加载 100 万个元素，意味着内存访问次数约为 1,000,000 * (64/16) = 4,000,000 次内存读取。
- 开销：由于对齐，每次读取都会带入一些不必要的数据。
PHP 8.4 (12 字节 ZVAL):
- CPU L1 缓存加载：1 次（64 字节）。
- 加载 100 万个元素，意味着内存访问次数约为 1,000,000 * (64/12) ≈ 5,333,333 次内存读取。
- 等等！这看起来更慢了？
请住手！这是陷阱！
不要被这个计算欺骗了。内存带宽并不是唯一的瓶颈。真正的瓶颈是CPU 流水线停顿和缓存行的污染。
当你访问一个 16 字节的 zval 时，它的对齐可能并不完美。假设它从偏移量 0 开始，那么下一个 zval 就在 16 处。
在 64 字节的缓存行中：
- 16 字节 ZVAL:
[Z1][Z2][Z3][Z4] [Waste](4 个 ZVAL 塞满一行)。 - 12 字节 ZVAL:
[Z1][Z2][Z3] [Z4][Z5](5 个 ZVAL 塞满一行)。
如果 12 字节能更紧密地贴合 64 字节的边界（即 12 的倍数 60，余 4，或者 12 的倍数 48，等等），那么 CPU 就能更高效地预取。
更重要的是，ZVAL 的小型化带来了“栈分配”的可能性。
在 PHP 8.4 中，像常量、简单的局部变量，如果引用计数为 1（通常情况），我们可以将 ZVAL 直接分配在栈上，而不是堆上。
void example_function() {
zval local_var; // PHP 8.4: 可能直接分配在栈上，或者是更紧凑的堆分配
ZVAL_LONG(&local_var, 42);
// 使用 local_var...
}这种“零拷贝”和“栈分配”对于高频调用的函数来说，性能提升是指数级的。它避免了昂贵的内存分配器（emalloc/efree）的调用，这比节省那 4 个字节的内存更值钱。
第九部分：重构的代价
当然，这事儿没那么容易。没有免费的午餐。
- 兼容性噩梦：ZVAL 是 PHP 最底层的结构。修改它就像在飞机上更换引擎。所有 C 扩展（Swoole, Redis, Imagick）都必须重写。任何直接操作
zval内存布局的扩展都会挂掉。 - 调试困难：当内存损坏时，一个 12 字节的 ZVAL 变得更加难以用调试器定位，因为内存中的垃圾数据可能被解释为不同的类型。
- 复杂性增加：代码中充满了大量的位掩码操作。可读性下降了。一个简单的
Z_TYPE_P(z)可能变成了一行复杂的宏，包含多个条件判断。
第十部分：总结（不带总结的总结）
所以，PHP 8.4 的 ZVAL 重排，本质上是一场与 CPU 架构的博弈。
它试图通过牺牲一点代码的可读性（位操作），换取巨大的物理内存效率和缓存命中率。
想象一下，我们在写代码时，PHP 引擎在底层默默地把内存打包，把浪费的空间挤掉，让 CPU 能一次抓取更多有用的数据。这就是现代编程语言进化的缩影：越来越快，越来越小，越来越抽象。
下次当你看到一个简单的 echo "Hello"; 时，不要忘了在 zend/zend_value 结构体里，有一行代码正在通过位运算，小心翼翼地把你那 5 个字符的字符串塞进那个只有 12 字节的盒子里。
这不仅是 PHP 8.4 的进化，也是每一个程序员内心深处对“极致优化”的渴望。
好了，今天的讲座就到这里。现在，让我们去看看 zval 到底有没有成功减掉那 4 磅肉。我是你们的内存专家，下课！