编译器对autorelease的优化

[obj autorelease]内部会调用到rootAutorelease，其中有个判断prepareOptimizedReturn返回true的话就直接返回对象，而不去走添加对象到autoreleasepool中这一套逻辑，来提高效率，减少autoreleasepool的开销

本文的runtime版本为objc4-779.1、设备架构是模拟器x86_64

rootAutorelease的实现如下：

inline id 
objc_object::rootAutorelease()
{
    if (isTaggedPointer()) return (id)this; // tagged pointer直接返回不走这一套流程
    if (prepareOptimizedReturn(ReturnAtPlus1)) return (id)this;

    return rootAutorelease2();
}

那么系统是怎么做到什么时候去优化，什么时候不去优化了；一时间摸不着头脑，后面看了些文章再结合源码，有了个大概的理解。

1. 分析源码

我们看到上面的代码中有个判断prepareOptimizedReturn返回true的话就直接return对象不做对应的autorelease操作，那么我们就顺着源码去看看
1.1 prepareOptimizedReturn

// 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;
}

这里看到核心是判断callerAcceptsOptimizedReturn为true的时候才返回true，开启优化；那么这里是怎么知道需要优化的了，需要看看callerAcceptsOptimizedReturn的具体实现；在这之前先了解下__builtin_return_address和setReturnDisposition的作用。

1.1.1 __builtin_return_address(0)
作用就是得到函数的返回地址，0--表示返回当前函数的返回地址，1--表示当前函数的调用方的返回地址；具体可参照gcc官方文档的介绍

1.1.2 setReturnDisposition
内部实现如下：

enum ReturnDisposition : bool {
    ReturnAtPlus0 = false, ReturnAtPlus1 = true
};

static ALWAYS_INLINE void 
setReturnDisposition(ReturnDisposition disposition)
{
    tls_set_direct(RETURN_DISPOSITION_KEY, (void*)(uintptr_t)disposition);
}

它的作用就是将disposition的值存储到TLS(Thread Local Storage)中，对应的还有一个读取的方法

static ALWAYS_INLINE ReturnDisposition 
getReturnDisposition()
{
    return (ReturnDisposition)(uintptr_t)tls_get_direct(RETURN_DISPOSITION_KEY);
}

后面在讲objc_autoreleaseReturnValue可以看到会存储这个值为ReturnAtPlus1

1.2 callerAcceptsOptimizedReturn
这个函数看名字意思就是调用方是否接受优化的返回，那么编译器就得通过一些手段来知道调用方是怎么处理返回值的，来决定是否去做优化；看源码发现不同的系统架构，该方法的实现也都不一样；

我这里贴的是x86_64的实现

static ALWAYS_INLINE bool 
callerAcceptsOptimizedReturn(const void * const ra0)
{
    const uint8_t *ra1 = (const uint8_t *)ra0;
    const unaligned_uint16_t *ra2;
    const unaligned_uint32_t *ra4 = (const unaligned_uint32_t *)ra1;
    const void **sym;

#define PREFER_GOTPCREL 0
#if PREFER_GOTPCREL
    // 48 89 c7    movq  %rax,%rdi
    // ff 15       callq *symbol@GOTPCREL(%rip)
    if (*ra4 != 0xffc78948) {
        return false;
    }
    if (ra1[4] != 0x15) {
        return false;
    }
    ra1 += 3;
#else
    // 48 89 c7    movq  %rax,%rdi
    // e8          callq symbol
    if (*ra4 != 0xe8c78948) {
        return false;
    }
    ra1 += (long)*(const unaligned_int32_t *)(ra1 + 4) + 8l;
    ra2 = (const unaligned_uint16_t *)ra1;
    // ff 25       jmpq *symbol@DYLDMAGIC(%rip)
    if (*ra2 != 0x25ff) {
        return false;
    }
#endif
    ra1 += 6l + (long)*(const unaligned_int32_t *)(ra1 + 2);
    sym = (const void **)ra1;
    // 这里检验了主调方在返回值之后是否紧接着调用了以下2个方法去持有返回的对象，如果有则说明可以去优化，不需要被调用方去autorelease，也不需要调用方去retain返回的对象了，省去了开销
    if (*sym != objc_retainAutoreleasedReturnValue  &&  
        *sym != objc_unsafeClaimAutoreleasedReturnValue) 
    {
        return false;
    }

    return true;
}

看代码当调用方在返回值之后如果调用了objc_retainAutoreleasedReturnValue或者objc_unsafeClaimAutoreleasedReturnValue的时候就表示可以优化；

这2个函数的具体实现如下：

// Accept a value returned through a +0 autoreleasing convention for use at +1.
id
objc_retainAutoreleasedReturnValue(id obj)
{
    if (acceptOptimizedReturn() == ReturnAtPlus1) return obj; // 调用方去TLS中查找刚好标记位为true，那么就直接返回该对象了。省去了retain的操作

    return objc_retain(obj);
}

// Accept a value returned through a +0 autoreleasing convention for use at +0.
id
objc_unsafeClaimAutoreleasedReturnValue(id obj)
{
    if (acceptOptimizedReturn() == ReturnAtPlus0) return obj;

    return objc_releaseAndReturn(obj); // release(obj) and return obj
}

acceptOptimizedReturn则去读取TLS中存储的值，同时读取之后也会置为ReturnAtPlus0

static ALWAYS_INLINE ReturnDisposition 
acceptOptimizedReturn()
{
    ReturnDisposition disposition = getReturnDisposition(); // 从tsl中读取对应的值
    setReturnDisposition(ReturnAtPlus0);  // reset to the unoptimized state 将数据之为0
    return disposition;
}

objc_retainAutoreleasedReturnValue表示调用方是强持有返回的对象，而objc_unsafeClaimAutoreleasedReturnValue表示调用方不强持有返回的对象；

这里可以这么去理解：

  • 假如编译器知道调用方是强持有返回的值(ref + 1)，那么就没必要返回的时候autorelease一下，然后调用方再将返回值retain一下，直接返回对象就好了
  • 假如调用方不强持有返回的值，那么返回值不加入autoreleasepool中的话，就需要objc_releaseAndReturnrelease该对象了，省去了加入autoreleasepool的操作

2.示例解析

2.1 强持有的情况
测试代码：

@implementation TestClass

+ (instancetype)testInstance {
    return [self new];
}

@end

// 测试用例：
void autoreleaseTestCase(void) {
    TestClass *test = [TestClass testInstance]; // test的默认修饰符是strong
}

查看汇编代码：

// 被调用方实现：
define internal i8* @"\01+[TestClass testInstance]"(i8* %0, i8* %1) #1 !dbg !72 {
  %3 = alloca i8*, align 8
  %4 = alloca i8*, align 8
  store i8* %0, i8** %3, align 8
  call void @llvm.dbg.declare(metadata i8** %3, metadata !83, metadata !DIExpression()), !dbg !85
  store i8* %1, i8** %4, align 8
  call void @llvm.dbg.declare(metadata i8** %4, metadata !86, metadata !DIExpression()), !dbg !85
  %5 = load i8*, i8** %3, align 8, !dbg !88
  %6 = call i8* @objc_opt_new(i8* %5), !dbg !89
  %7 = bitcast i8* %6 to %1*, !dbg !89
  %8 = bitcast %1* %7 to i8*, !dbg !89
  %9 = tail call i8* @llvm.objc.autoreleaseReturnValue(i8* %8) #3, !dbg !90
  ret i8* %9, !dbg !90
}


// 调用方实现：
define void @autoreleaseTestCase() #4 !dbg !311 {
  %1 = alloca %1*, align 8
  call void @llvm.dbg.declare(metadata %1** %1, metadata !312, metadata !DIExpression()), !dbg !313
  %2 = load %struct._class_t*, %struct._class_t** @"OBJC_CLASSLIST_REFERENCES_$_.63", align 8, !dbg !314
  %3 = load i8*, i8** @OBJC_SELECTOR_REFERENCES_.69, align 8, !dbg !314, !invariant.load !8
  %4 = bitcast %struct._class_t* %2 to i8*, !dbg !314
  %5 = call i8* bitcast (i8* (i8*, i8*, ...)* @objc_msgSend to i8* (i8*, i8*)*)(i8* %4, i8* %3), !dbg !314
  %6 = notail call i8* @llvm.objc.retainAutoreleasedReturnValue(i8* %5) #3, !dbg !314
  %7 = bitcast i8* %6 to %1*, !dbg !314
  store %1* %7, %1** %1, align 8, !dbg !314
  %8 = bitcast %1** %1 to i8**, !dbg !315
  call void @llvm.objc.storeStrong(i8** %8, i8* null) #3, !dbg !315
  ret void, !dbg !315
}

在看看被调用方中的objc_autoreleaseReturnValue实现：

id 
objc_autoreleaseReturnValue(id obj) // return [obj autorelease] ??
{
    if (prepareOptimizedReturn(ReturnAtPlus1)) return obj; // 这里判断如果调用方是objc_retainAutoreleasedReturnValue，那么就说明外部是对obj retain操作，那么这里就不需要将对象加到autorelease中，然后外部调用方又去retain一下，直接返回回去该对象，节省了这些开销

    return objc_autorelease(obj);
}

这里调用方在返回值调用了retainAutoreleasedReturnValue，那么被调用方在prepareOptimizedReturn操作就会存储true到TLS中，并且直接返回了obj；同时调用方在执行retainAutoreleasedReturnValue读到了TLS中存储的值为true，则表示不需要去retain操作了，这样就省去了被调用方返回的时候加入autoreleasepool的操作，以及调用方retain返回值的操作

2.2 非强持有
测试代码：

void autoreleaseTestCase1(void) {
// 这里我们对返回值不强持有
    __unsafe_unretained id testObj = [TestClass testInstance];
}

查看汇编代码：

// 被调用方：
define internal i8* @"\01+[TestClass testInstance]"(i8* %0, i8* %1) #1 !dbg !72 {
  %3 = alloca i8*, align 8
  %4 = alloca i8*, align 8
  store i8* %0, i8** %3, align 8
  call void @llvm.dbg.declare(metadata i8** %3, metadata !83, metadata !DIExpression()), !dbg !85
  store i8* %1, i8** %4, align 8
  call void @llvm.dbg.declare(metadata i8** %4, metadata !86, metadata !DIExpression()), !dbg !85
  %5 = load i8*, i8** %3, align 8, !dbg !88
  %6 = call i8* @objc_opt_new(i8* %5), !dbg !89
  %7 = bitcast i8* %6 to %1*, !dbg !89
  %8 = bitcast %1* %7 to i8*, !dbg !89
  %9 = tail call i8* @llvm.objc.autoreleaseReturnValue(i8* %8) #3, !dbg !90
  ret i8* %9, !dbg !90
}

// 调用方：
define void @autoreleaseTestCase1() #4 !dbg !145 {
  %1 = alloca i8*, align 8
  call void @llvm.dbg.declare(metadata i8** %1, metadata !146, metadata !DIExpression()), !dbg !147
  %2 = load %struct._class_t*, %struct._class_t** @"OBJC_CLASSLIST_REFERENCES_$_.63", align 8, !dbg !148
  %3 = load i8*, i8** @OBJC_SELECTOR_REFERENCES_.69, align 8, !dbg !148, !invariant.load !8
  %4 = bitcast %struct._class_t* %2 to i8*, !dbg !148
  %5 = call i8* bitcast (i8* (i8*, i8*, ...)* @objc_msgSend to i8* (i8*, i8*)*)(i8* %4, i8* %3), !dbg !148
  %6 = call i8* @llvm.objc.unsafeClaimAutoreleasedReturnValue(i8* %5) #3, !dbg !148
  %7 = bitcast i8* %6 to %1*, !dbg !148
  %8 = bitcast %1* %7 to i8*, !dbg !148
  store i8* %8, i8** %1, align 8, !dbg !148
  ret void, !dbg !149
}

上面也分析过被调用方autoreleaseReturnValue在调用方调用了unsafeClaimAutoreleasedReturnValue也会通过prepareOptimizedReturn(ReturnAtPlus1)将true写入TLS中，免去了将返回值加入autoreleasepool的操作，而unsafeClaimAutoreleasedReturnValue在从TLS中取值的时候就不会走这个分支if (acceptOptimizedReturn() == ReturnAtPlus0) return obj;而走了return objc_releaseAndReturn(obj)，这样对象也正常release了。

3. 总结

  • 编译器通过__builtin_return_address来知道调用方是强持有或者非强持有autoreleased返回值来决定去优化
  • 被调用方通过向TLS存储ReturnAtPlus1标记位表示做了优化，调用方读取该标记位的值，来决定是否需要retain及release操作；从而省去了将对象加入到autoreleasepool的操作

4. 参考文档

©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 206,839评论 6赞 482
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 88,543评论 2赞 382
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 153,116评论 0赞 344
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 55,371评论 1赞 279
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 64,384评论 5赞 374
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 49,111评论 1赞 285
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 38,416评论 3赞 400
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 37,053评论 0赞 259
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 43,558评论 1赞 300
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,007评论 2赞 325
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,117评论 1赞 334
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,756评论 4赞 324
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 39,324评论 3赞 307
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,315评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,539评论 1赞 262
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 45,578评论 2赞 355
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,877评论 2赞 345