iOS开发底层探究之路

iOS底层 - cache原理分析

2020-09-22  本文已影响0人  Lcr111

iOS开发底层探究之路

在对Objective-C底层的探究过程中，已经探究过objc_class 结构中的isa及bits,那么本篇文章我们来见见这个cache是个啥玩意：

struct objc_class : objc_object {
    // Class ISA;
    Class superclass;
    cache_t cache;             // formerly cache pointer and vtable
    class_data_bits_t bits;    // class_rw_t * plus custom rr/alloc flags

    class_rw_t *data() const {
        return bits.data();
    }
}

以及cache_t结构体类型的cache源码：

struct cache_t {
#if CACHE_MASK_STORAGE == CACHE_MASK_STORAGE_OUTLINED
    explicit_atomic<struct bucket_t *> _buckets;
    explicit_atomic<mask_t> _mask;
#elif CACHE_MASK_STORAGE == CACHE_MASK_STORAGE_HIGH_16
    explicit_atomic<uintptr_t> _maskAndBuckets;
    mask_t _mask_unused;
    
    // How much the mask is shifted by.
    static constexpr uintptr_t maskShift = 48;
    
    // Additional bits after the mask which must be zero. msgSend
    // takes advantage of these additional bits to construct the value
    // `mask << 4` from `_maskAndBuckets` in a single instruction.
    static constexpr uintptr_t maskZeroBits = 4;
    
    // The largest mask value we can store.
    static constexpr uintptr_t maxMask = ((uintptr_t)1 << (64 - maskShift)) - 1;
    
    // The mask applied to `_maskAndBuckets` to retrieve the buckets pointer.
    static constexpr uintptr_t bucketsMask = ((uintptr_t)1 << (maskShift - maskZeroBits)) - 1;
    
    // Ensure we have enough bits for the buckets pointer.
    static_assert(bucketsMask >= MACH_VM_MAX_ADDRESS, "Bucket field doesn't have enough bits for arbitrary pointers.");
#elif CACHE_MASK_STORAGE == CACHE_MASK_STORAGE_LOW_4
    // _maskAndBuckets stores the mask shift in the low 4 bits, and
    // the buckets pointer in the remainder of the value. The mask
    // shift is the value where (0xffff >> shift) produces the correct
    // mask. This is equal to 16 - log2(cache_size).
    explicit_atomic<uintptr_t> _maskAndBuckets;
    mask_t _mask_unused;

    static constexpr uintptr_t maskBits = 4;
    static constexpr uintptr_t maskMask = (1 << maskBits) - 1;
    static constexpr uintptr_t bucketsMask = ~maskMask;
#else
#error Unknown cache mask storage type.
#endif
    
#if __LP64__
    uint16_t _flags;
#endif
    uint16_t _occupied;
// 省略下方方法
}

其中，在不同运行环境解释为：

struct bucket_t {
private:
    // IMP-first is better for arm64e ptrauth and no worse for arm64.
    // SEL-first is better for armv7* and i386 and x86_64.
#if __arm64__
    explicit_atomic<uintptr_t> _imp;
    explicit_atomic<SEL> _sel;
#else
    explicit_atomic<SEL> _sel;
    explicit_atomic<uintptr_t> _imp;
#endif
void set(SEL newSel, IMP newImp, Class cls);
}

上面源码分析可以看出：

cache例子分析

首先在可编译源码工程中创建一个LGPerson类，并添加属性及方法：

@interface LGPerson : NSObject
@property (nonatomic, copy) NSString *lgName;
@property (nonatomic, strong) NSString *nickName;
- (void)sayHello;
- (void)sayCode;
- (void)sayMaster;
- (void)sayNB;
@end
#import "LGPerson.h"
@implementation LGPerson
- (void)sayHello{
    NSLog(@"LGPerson say : %s",__func__);
}
- (void)sayCode{
    NSLog(@"LGPerson say : %s",__func__);
}
- (void)sayMaster{
    NSLog(@"LGPerson say : %s",__func__);
}
- (void)sayNB{
    NSLog(@"LGPerson say : %s",__func__);
}
@end

main.m 文件main入口函数中创建实例并方法调用：

cache_t例子分析

如图，断点停在22行，在对象p调用实例方法之前，我们利用lldb打印当前pClass相关类信息，因为实例方法存放在类信息里面:

查看类cache信息
通过对当前pClass类指针偏移16位的地址进行打印，我们得到当前类的cache信息，其中_occupied = 0，_mask = 0 ，好，我们继续下一个断点，来到了23行，此时只进行了sayHello方法的调用，我们再次打印当前类的cache信息： 第一次调用方法结果打印

可以看到：

好，接下来我们再调用第二个方法sayCode，再继续查看当前类的cahce信息：


第二个方法调用类信息打印

继续接着第三个方法sayMaster方法调用，那么此时再打印类信息又会是怎样的：

第三个方法调用结果打印
上图可以看出，在调用第三个方法之后，cache信息有了很大变化：

最后调用第四个方法sayNB，来看看结果又是怎样的：

第四方法调用结果
继续利用地址偏移，最后找到sayNB方法sel和imp 信息：
sayNB方法查找打印

从上面两个打印结果看出：

接下来我们通过分析cache缓存方法的源码来一探究竟。

cache 源码分析

拓展：查看源码原则，一般属性只有存储信息的作用，能改变信息的一般我们认准函数方法，函数方法才大有可能是改变信息的地方。

首先我们来看文章开始cache_t源码中隐藏的函数方法部分：

public:
    static bucket_t *emptyBuckets();
    
    struct bucket_t *buckets();
    mask_t mask();   
    mask_t occupied();
    void incrementOccupied();
    void setBucketsAndMask(struct bucket_t *newBuckets, mask_t newMask);
    void initializeToEmpty();

    unsigned capacity();
    bool isConstantEmptyCache();
    bool canBeFreed();
    void reallocate(mask_t oldCapacity, mask_t newCapacity, bool freeOld);
    void insert(Class cls, SEL sel, IMP imp, id receiver);

    static void bad_cache(id receiver, SEL sel, Class isa) __attribute__((noreturn, cold));

从上面所有函数方法中探究，前四个函数，查看源码，发现只是简单的获取cache的相对应的属性。我们发现第五个函数incrementOccupied()：

void cache_t::incrementOccupied() 
{
    _occupied++;
}

可以看出此函数正式改变（增加）_occupied 值的，那我们就从此函数入手，全局搜索incrementOccupied()，发现只有void cache_t::insert(Class cls, SEL sel, IMP imp, id receiver) 方法中找到此函数的调用位置：

incrementOccupied调用

从参数上来看,insert 方法可以理解为向cache中插入方法的sel及imp信息，全局搜索发现只有在cache_fill方法中进行了cache->insert调用:

void cache_fill(Class cls, SEL sel, IMP imp, id receiver)
{
    runtimeLock.assertLocked();

#if !DEBUG_TASK_THREADS
    // Never cache before +initialize is done
    if (cls->isInitialized()) {
        cache_t *cache = getCache(cls);
#if CONFIG_USE_CACHE_LOCK
        mutex_locker_t lock(cacheUpdateLock);
#endif
        cache->insert(cls, sel, imp, receiver); //向cache插入方法sel、imp信息
    }
#else
    _collecting_in_critical();
#endif
}

全局搜索cache_fill，发现在cache_fill方法之前，还进行了Cache中的sel与imp 查找：

cache_fill

insert方法分析

下面着重分析 cache 缓存方法的核心函数insert源码：

cache::insert方法初探

我们可以将上面三个断点作为insert方法的三个阶段：

reallocate 初始化方法分析

ALWAYS_INLINE
void cache_t::reallocate(mask_t oldCapacity, mask_t newCapacity, bool freeOld)
{
    bucket_t *oldBuckets = buckets();
    bucket_t *newBuckets = allocateBuckets(newCapacity);

    // Cache's old contents are not propagated. 
    // This is thought to save cache memory at the cost of extra cache fills.
    // fixme re-measure this

    ASSERT(newCapacity > 0);
    ASSERT((uintptr_t)(mask_t)(newCapacity-1) == newCapacity-1);

    setBucketsAndMask(newBuckets, newCapacity - 1);
    
    if (freeOld) {
        cache_collect_free(oldBuckets, oldCapacity);
    }
}

首先去内存中申请buckets内存空间，allocateBuckets函数：

bucket_t *allocateBuckets(mask_t newCapacity)
{
    // Allocate one extra bucket to mark the end of the list.
    // This can't overflow mask_t because newCapacity is a power of 2.
    bucket_t *newBuckets = (bucket_t *)
        calloc(cache_t::bytesForCapacity(newCapacity), 1);

    bucket_t *end = cache_t::endMarker(newBuckets, newCapacity);

#if __arm__   //真机
    // End marker's sel is 1 and imp points BEFORE the first bucket.
    // This saves an instruction in objc_msgSend.
    end->set<NotAtomic, Raw>((SEL)(uintptr_t)1, (IMP)(newBuckets - 1), nil);
#else          //模拟器或macOS（当前环境）
    // End marker's sel is 1 and imp points to the first bucket.
    end->set<NotAtomic, Raw>((SEL)(uintptr_t)1, (IMP)newBuckets, nil);
#endif
    
    if (PrintCaches) recordNewCache(newCapacity);

    return newBuckets;
}

通过calloc 函数去内存中申请newCapacity 大小的容量的newBuckets，此方法返回的newBuckets只是一个临时变量。setBucketsAndMask就是 将newBuckets保存在cache中：

对比可以看出，真机环境下，bucket和mask的位置存储，并将occupied占用设置为0，模拟器或者macOS下，正常存储bucket和mask，并将occupied占用设置为0。

最后判断是否需要清理oldBuckets，如果需要则调用cache_collect_free将旧的buckets清理掉。

清理旧buckets

hash 算法存储sel、imp

static inline mask_t cache_hash(SEL sel, mask_t mask) 
{
    return (mask_t)(uintptr_t)sel & mask;
}

cache_hash通过(SEL sel, mask_t mask) 中的sel & mask，把得到的作为下标在buckets获取当前的bucket_t，如果当前的bucket中的sel == 0 ，说明当前位置暂无插入任何sel、imp,即插入当前的sel及imp,并且_occupied占用加1；如果当前bucket中的sel与要插入的sel相等，说明已经存在了当前的sel,就直接返回，避免重复插入；如果当前bucket已经存在sel，即已经保存了别的方法的sel及imp信息，那就通过cache_next哈希冲突方法重新查找别的位置进行插入。

#if __arm__  ||  __x86_64__  ||  __i386__
// objc_msgSend has few registers available.
// Cache scan increments and wraps at special end-marking bucket.
#define CACHE_END_MARKER 1
static inline mask_t cache_next(mask_t i, mask_t mask) {
    return (i+1) & mask;
}

#elif __arm64__
// objc_msgSend has lots of registers available.
// Cache scan decrements. No end marker needed.
#define CACHE_END_MARKER 0
static inline mask_t cache_next(mask_t i, mask_t mask) {
    return i ? i-1 : mask;
}

至此，cache源码分析告一段落！

问题解释及LGPerson例子解释

上一篇 下一篇

猜你喜欢

热点阅读