正常
WeakPtr 前置知识（六）：TRIVIAL_ABI 与平凡可重定位
前面几篇咱们把 WeakPtr 的成员摸清了:一个 WeakReference(里头是 scoped_refptr<const Flag>,持引用计数),一个 T* ptr_。它有非平凡析构——析构时得 dec flag 的引用计数。按 C++ 默认 ABI 规则,这种类型在函数调用里不能直接进寄存器按值传,得绕道走内存(栈或者隐藏的引用参数)。
但您要是翻开 Chromium 的 weak_ptr.h,会发现 WeakPtr 和 WeakReference 上都挂了个叫 TRIVIAL_ABI 的属性(weak_ptr.h:101,203)。挂上之后,有非平凡析构的类型在调用约定里被当平凡类型处理,可以进寄存器、按值高效传递。WeakPtr 一共就两个指针大,标完之后函数间传来传去就跟传两个指针一样便宜。
笔者第一次看到这事儿是懵的。一个持引用计数的类型,凭什么敢标"平凡"?这里有个反直觉的点值得咱们花一篇来拆:trivial_abi 到底是什么、代价是什么,以及——WeakPtr 凭什么满足它的安全条件。答案不是"引用计数无关紧要",而是这套设计刻意把每块零件都摆到了能安全标注的位置上。
平凡类型 vs 非平凡类型:ABI 视角
C++ 把类型分成"平凡(trivial)"和"非平凡(non-trivial)"两档,调用约定(ABI)上区别对待。
平凡类型比如 int、std::pair<int,int>、POD 结构,拷贝、移动、析构都"什么都不做",或者说 bitwise 等价于 memcpy。这种类型函数调用时可以直接塞寄存器按值传,返回也能走寄存器,开销小到几乎可以忽略。
非平凡类型——只要非平凡的拷贝构造、移动构造、析构里有任意一个,就算——传递时 ABI 通常走内存:栈上开一份,或者塞个隐藏的引用参数。原因是编译器得保证那些非平凡操作(比如析构时 dec 引用计数)在它该跑的地方跑,不能简单 memcpy。
WeakPtr 因为持 scoped_refptr(析构要 dec refcount),是非平凡类型。按默认 ABI,传一个 WeakPtr 得走内存,进不了寄存器。
[[clang::trivial_abi]] 是什么
[[clang::trivial_abi]] 是 Clang 的一个类型属性,Chromium 把它包成了 TRIVIAL_ABI 宏——__has_cpp_attribute(clang::trivial_abi) 为真时展开成该属性,否则为空(base/compiler_specific.h)。
它的语义说白了就一句:让这个非平凡类型在调用约定里被当成平凡类型处理。两个具体效果。一是按值传参或按值返回时可以走寄存器,跟平凡类型一个待遇。二是对象可以被"重定位(relocate)"——把"移动 + 析构源对象"这两步合成一次 memcpy 搬运。
这里头有个前提(Clang 文档专门强调了),标的类型必须是平凡可重定位(trivially relocatable)的。意思是这样:把对象从一处 bitwise 搬到另一处、然后忽略原处的析构,这件事在语义上得跟"对它做一次 move 构造 + 析构源对象"完全等价。满足了,编译器就能拿 memcpy 顶替 move+destroy,放心地用寄存器传参。
代价:析构时机/位置改变
trivial_abi 不是白吃的午餐,它动了析构的时机和位置。
对一个普通非平凡类型,ABI 严格规定了"这个临时对象在哪一层栈帧析构"。标了 trivial_abi 之后,对象可能在调用方栈帧里构造、被装进寄存器传过去、在被调用方栈帧里析构——析构落点变了。类型真要是平凡可重定位,这变化无所谓(move+destroy 反正等价 memcpy)。但类型要不是真正平凡可重定位——比如析构里有不能省的副作用——强标上去就会出 bug。
代价就在这。Clang 文档因此专门提醒:trivial_abi 只能用在真正满足条件的类型上,不能随手贴。
WeakPtr 为什么能安全标注
那 WeakPtr 持着引用计数(通过 scoped_refptr<Flag>),它凭什么满足"平凡可重定位"?咱们一块一块拆。
先看 T* ptr_。它是个裸指针,拷贝、移动、析构都是平凡的(bitwise),完全不碰 inc/dec。裸指针本身就是平凡可重定位的,对 trivial_abi 没任何障碍。
真正的关键在 WeakReference ref_ 里那个 scoped_refptr<const Flag>。它不是平凡类型——拷贝要 inc refcount,析构要 dec。那它是不是"平凡可重定位"?
咱们推一下。scoped_refptr 的 move 构造干了什么?把源对象的裸指针偷过来(ptr_ = other.ptr_; other.ptr_ = nullptr;),不 inc。源对象随后被析构时,它的 ptr_ 已经是 nullptr,release() 走出去是个 no-op。把这两步合起来看,净效果就是把裸指针 bitwise 搬过去,没 inc、没 dec,引用计数纹丝不动。
这正好就是"平凡可重定位"的定义。所以 scoped_refptr 虽然非平凡,却平凡可重定位。WeakPtr 持有它,继承了这个性质;加上 ptr_ 部分天然平凡,整个 WeakPtr 满足 trivial_abi 的前提。
还有一层容易漏的保证。trivial_abi 让析构位置不确定——某个 WeakPtr 实例可能最终在一个"意外"的线程上被析构(比如调用方栈帧里),它持有的 scoped_refptr 会在那个线程 dec flag 的 refcount。这就要求 flag 的引用计数操作跨线程安全,正是 前置知识（一） 里讲的 RefCountedThreadSafe(原子 inc/dec)兜的底。再加上 Flag::Invalidate 里 HasOneRef() 那个跨线程析构豁免,flag 在任意线程减到 0 析构都安全。没这一层,trivial_abi 叠上"析构位置漂移",跨线程场景下迟早翻车。
这是设计规避,不是属性固有
讲到这里,有个结论笔者得强调一下,免得您拿这套思路去贴别的类型时翻车。
trivial_abi 对"持有引用计数句柄"的类型,并不是固有安全的。WeakPtr 能标,是因为它的成员被刻意设计成了平凡可重定位——而不是"任何带 refcount 的类型都能随便贴这个属性"。
举个反例。您要是自己写个类,手动管理引用计数(拷贝构造里 ++count_,析构里 --count_ 且归零时清理),却没保证"move+destroy-source 等价于 memcpy",那强标 trivial_abi 就可能让编译器在错误的位置或时机省掉一次析构。引用计数一失准,轻的泄漏,重的 double-free,Clang 文档和 Chromium 自己的注释都专门警告过这一点。
回到 WeakPtr,它的安全是三层共同撑起来的。ptr_ 是裸指针,天然平凡;scoped_refptr 虽非平凡但平凡可重定位,move+destroy 等价 memcpy;Flag 用 RefCountedThreadSafe,跨线程析构有 HasOneRef() 兜底。三层缺一不可。所以您在 02-6 看到 WeakPtr 标了 TRIVIAL_ABI 享受寄存器传递的好处时,这份"零开销"是前面大量设计换来的——开销没消失,是被设计提前消解掉了。这正是 Chromium 的零开销抽象哲学。
前置知识七篇到这就齐了:pre-00 弱引用导论,加上 pre-01~06 这六块零件——侵入式引用计数、原子与 memory order、序列与 DCHECK/CHECK、concepts、模板友元与 uintptr_t、TRIVIAL_ABI。零件凑齐,该动手把 WeakPtr 的核心骨架搭起来了,咱们下一篇就看看这七块零件怎么咬合成一整套工业级弱指针。