大家来找茬：记一起 clang 开启 -Oz 选项引发的血案
前言
-Oz 优化选项时发现的编译器缺陷。
问题
-O0，在 Release 模式默认使用 -Os（兼顾执行速度和体积），但是在一些性能要求不大的场景，我们可以使用 -Oz级别，开启后编译器会针对代码体积采取更加激进的优化手段。
-Oz 优化级别进行编译，但在开启后的测试中发现，视频组件在导出视频时出现内存暴涨然后发生 OOM 闪退，并且可以稳定重现。通过 Instruments 及 Xcode 的 Memory Graph 功能可以看到大量的 GLFramebuffer 被创建，而每个 GLFramebuffer 中会持有一个 2MB 的 CVPixelBuffer ，导致占用大量内存。
GLFramebuffer 应该被复用而不是重复创建，但通过日志发现每次获取时都没有可用的 buffer，于是就不断创建新的 buffewr。在代码逻辑中， buffer 是否能重用依赖于 -[GLFramebuffer unlock] 是否被调用，但是通过观察发现：这些 buffer 会堆积到导出任务结束后才被 unlock，所以我们需要找到 unlock 被推迟的原因。
GLFramebuffer 会被一个 SampleData 对象持有，并在 -[SampleData dealloc] 被调用时对 GLFramebuffer 进行 unlock ，当 SampleData 对象被放到 autoreleasepool 中堆积起来就会出现内存暴涨，符合前面观察到 buffer 批量 unlock 的现象（在 autoreleasepool 批量释放对象的时候）。
-Oz 时 SampleData 对象是不会进入 autorelasepool 的，所以没有问题，于是接下来我们需要找到为什么开启 -Oz 后 SampleData 对象会被进入 autorelasepool。
objc_autoreleaseReturnValue / objc_autorelease 的 C 函数来触发 autorelease 操作，我们无法通过符号断点到 -[SampleData autorelease] 来确认释放时机，除非把代码改回 MRC，所以这里得通过特殊的方式：
-fno-objc-arc 关闭 ARC：
// 和 SampleData 一样都是继承自 NSObject
@interface BDRetainTracker : NSObject
@end
@implementation BDRetainTracker
- (id)autorelease {
return [super autorelease]; // 此处设置断点
}
@end
autorelease 方法设置断点，然后在 App 启动后执行：
class_setSuperclass(SampleData.class, (Class)NSClassFromString(@"BDRetainTracker"));
SampleData 被 autorelease 时会在我们设置的断点停下。通过这种方法结合上下文可以发现 SampleData 被 autorelease 的时机集中在 -[CompileReaderUnit processSampleData:] ：
- (BOOL)processSampleData:(SampleData *)sampleData {
...
SampleData *videoData = [self videoReaderOutput];
...
- (BOOL)processSampleData:(SampleData *)sampleData {
@autoreleasepool {
...
SampleData *videoData = [self videoReaderOutput];
...
}
[self videoReaderOutput] 返回一个 autoreleased 对象是符合 ARC 的约定的，但是之前没开启 -Oz 时编译器进行了优化，对象并不会进入 autoreleasepool，方法返回后就马上被释放了，查看 LLVM 的相关文档：
When returning from such a function or method, ARC retains the value at the point of evaluation of the return statement, then leaves all local scopes, and then balances out the retain while ensuring that the value lives across the call boundary. In the worst case, this may involve an autorelease, but callers must not assume that the value is actually in the autorelease pool.
ARC performs no extra mandatory work on the caller side, although it may elect to do something to shorten the lifetime of the returned value.
-Oz 后此处的编译器对应的优化失效了，让我们查看 SampleData *videoData = [self videoReaderOutput] 处的汇编：
adrp x8, #0x1018b5000
ldr x1, [x8, #0x1c0] ; 加载 @selector(videoReaderOutput)
bl _OUTLINED_FUNCTION_40_100333828 ; 调用外联函数
bl _OUTLINED_FUNCTION_0_1003336bc ; 调用外联函数
_OUTLINED_FUNCTION_ 函数的内容如下：
_OUTLINED_FUNCTION_40_100333828:
mov x0, x20
b imp_stubsobjc_msgSend
_OUTLINED_FUNCTION_0_1003336bc:
mov x29, x29
b imp_stubsobjc_retainAutoreleasedReturnValue
-
调用 objc_msgSend(self, @selector(videoReaderOutput), ...)返回一个 autoreleased 对象 -
然后对返回的对象调用 objc_retainAutoreleasedReturnValue进行强引用
-Os 生成的代码，此处 LLVM 的 MIR outliner 生效了：
adrp x8, #0x10190d000
ldr x1, [x8, #0xf0]
mov x0, x20
bl imp_stubsobjc_msgSend
mov x29, x29
bl imp_stubsobjc_retainAutoreleasedReturnValue
Machine Outliner
编译器在 -Oz 优化级别下 3~4 行和 5~6 行两段指令因为在多处被使用，于是分别被抽离到独立的函数进行复用，而原来的地方变成了一条函数调用的指令，数量从 4 条变成 2 条，从而达到减包的目的，这便是 LLVM 的 Machine Outliner 所做的事情，在 -Oz 下它会被默认开启来达到更极致的代码体积缩减（在其它优化级别下需要通过 -mllvm -enable-machine-outliner=always 来开启），其大致原理如下：
extern int do_something(int);
int calc_1(int a, int b) {
return do_something(a * (a - b));
}
int calc_2(int a, int b) {
return do_something(a * (a + b));
}
calc_1/calc_2 都调用了 do_something，尽管参数都不一样，但是我们能从汇编看到一些重复出现的指令序列（这里用 ARMv7 架构的汇编方便演示）
calc_1(int, int):
add r1, r1, r0 ; A
mul r0, r1, r0 ; B
add r1, r1, r0 ; A
mul r0, r1, r0 ; B
b do_something(int) ; C
calc_2(int, int):
add r1, r1, r0 ; A
add r1, r1, r0 ; A
mul r0, r1, r0 ; B
b do_something(int) ; C
calc_1 的指令序列是 ABABC 而 calc_2 是 AABC，编译器通过构造一个后缀树可以找到它们的最长公共子串是 ABC，那么 ABC 这一段就可以被剥离成一个独立的函数：
calc_1(int, int):
add r1, r1, r0 ; A
mul r0, r1, r0 ; B
b OUTLINED_FUNCTION_0
calc_2(int, int):
add r1, r1, r0 ; A
b OUTLINED_FUNCTION_0
OUTLINED_FUNCTION_0:
add r1, r1, r0 ; A
mul r0, r1, r0 ; B
b do_something(int) ; C
ARC 优化
但是为何指令被 outline 后 ARC 的优化会失效呢？留意到 mov x29, x29 这条指令，它实际上并没有做任何有意义的操作（将 x29 寄存器的值又存到 x29)，它只是个特殊的标记，是编译器用于辅助运行时进行优化的手段， videoReaderOutput 的实现中返回 autorelease 对象是一个这样的调用:
return objc_autoreleaseReturnValue(ret);
// Prepare a value at +1 for return through a +0 autoreleasing convention.
id objc_autoreleaseReturnValue(id obj) {
if (prepareOptimizedReturn(ReturnAtPlus1)) return obj;
return objc_autorelease(obj);
}
// Try to prepare for optimized return with the given disposition (+0 or +1).
// Returns true if the optimized path is successful.
// Otherwise the return value must be retained and/or autoreleased as usual.
static ALWAYS_INLINE bool
prepareOptimizedReturn(ReturnDisposition disposition) {
assert(getReturnDisposition() == ReturnAtPlus0);
if (callerAcceptsOptimizedReturn(__builtin_return_address(0))) {
if (disposition) setReturnDisposition(disposition);
return true;
}
return false;
}
static ALWAYS_INLINE bool
callerAcceptsOptimizedReturn(const void *ra){
// fd 03 1d aa mov x29, x29
if (*(uint32_t *)ra == 0xaa1d03fd) {
return true;
}
return false;
}
static ALWAYS_INLINE void
setReturnDisposition(ReturnDisposition disposition) {
tls_set_direct(RETURN_DISPOSITION_KEY, (void*)(uintptr_t)disposition);
}
objc_autoreleaseReturnValue 中会使用 __builtin_return_address 获取返回地址的指令，检查是否存在标记 mov x29 x29，如果有，意味着我返回的这个对象会马上被 retain，所以没必要放到 autoreleasepool 中，此时运行时会在 Thread Local Storage 中记录此处做了优化，然后回计数 +1 的对象即可。
videoReaderOutput 的调用方会使用 objc_retainAutoreleasedReturnValue 引用住对象，实现如下：
// Accept a value returned through a +0 autoreleasing convention for use at +1.
id objc_retainAutoreleasedReturnValue(id obj) {
if (acceptOptimizedReturn() == ReturnAtPlus1) return obj;
return objc_retain(obj);
}
// Try to accept an optimized return.
// Returns the disposition of the returned object (+0 or +1).
// An un-optimized return is +0.
static ALWAYS_INLINE ReturnDisposition
acceptOptimizedReturn() {
ReturnDisposition disposition = getReturnDisposition();
setReturnDisposition(ReturnAtPlus0); // reset to the unoptimized state
return disposition;
}
static ALWAYS_INLINE ReturnDisposition
getReturnDisposition() {
return (ReturnDisposition)(uintptr_t)tls_get_direct(RETURN_DISPOSITION_KEY);
}
objc_retainAutoreleasedReturnValue 看到 TLS 中的标记知道无需进行额外 retain，于是两者配合从而优化掉了一次 autorelease 和 retain 操作，但这是编译器和运行时的优化细节，不应该假设优化一定会被发生。正是由于开启 -Oz 后，machine outliner 棒打鸳鸯把 objc_msgSend 和 objc_retainAutoreleasedReturnValue 的调用指令及标记 outline 了，导致这个优化没有触发，对象进入 autoreleasepool。
总结
所以本质上这既是一个开发者的疏忽：使用占用大内存的临时对象后没有及时增加 autoreleasepool 将其释放，只是 ARC 的优化将这个问题隐藏，最终在开启 -Oz 后被暴露。
-enable-copy-propagation ）没有开启的情况下一些对象的生命周期可能会被延长，然后这个现象被开发者利用，在编译器保证之外的生命周期使用该对象，一开始可能没有问题，但是一旦这些优化由于编译器的升级或者代码的改动突然生效了，那么之前使用对象的地方可能就会访问到一个被释放的对象，更多具体的例子可以参考 WWDC 21 的 Session 10216。
LLVM 的相关文档
https://clang.llvm.org/docs/AutomaticReferenceCounting.html#unretained-return-values
Machine Outliner
https://llvm.org/doxygen/MachineOutliner_8cpp_source.html
Outlined 相关演讲
http://www.llvm.org/devmtg/2016-11/Slides/Paquette-Outliner.pdf
指令被 outline 后 ARC 的优化
https://github.com/opensource-apple/objc4/blob/cd5e62a5597ea7a31dccef089317abb3a661c154/runtime/objc-object.h#L929-L984
bug 修复
https://github.com/llvm/llvm-project/commit/ed4718eccb12bd42214ca4fb17d196d49561c0c7
WWDC 21 的 Session 10216
https://developer.apple.com/videos/play/wwdc2021/10216
关于字节终端技术团队
评论