從原始碼解析 Swift 弱引用

Swift · 發表 2019-03-03 19:46:13

摘要：序言：各個社群有關 Objective-C weak 機制的實現分析文章有很多，然而 Swift 釋出這麼長時間以來，有關 ABI 的分析文章一直非常少，似乎也是很多 iOS 開發者未涉及的領域… 本文就從原始碼層面分析一下 Swift 是如何實現 weak 機制的。準備工...

序言：各個社群有關 Objective-C weak 機制的實現分析文章有很多，然而 Swift 釋出這麼長時間以來，有關 ABI 的分析文章一直非常少，似乎也是很多 iOS 開發者未涉及的領域… 本文就從原始碼層面分析一下 Swift 是如何實現 weak 機制的。

準備工作

由於 Swift 原始碼量較大，強烈建議大家把 repo clone 下來，結合原始碼一起來看這篇文章。

$ git clone https://github.com/apple/swift.git

Swift 整個工程採用了 CMake 作為構建工具，如果你想用 Xcode 來開啟的話需要先安裝 LLVM，然後用cmake -G 生成 Xcode 專案。

我們這裡只是進行原始碼分析，我就直接用Visual Studio Code 配合C/C++ 外掛了，同樣支援符號跳轉、查詢引用。另外提醒一下大家，Swift stdlib 裡 C++ 程式碼的型別層次比較複雜，不使用 IDE 輔助閱讀起來會相當費勁。

正文

下面我們就正式進入原始碼分析階段，首先我們來看一下 Swift 中的物件（class 例項）它的記憶體佈局是怎樣的。

`HeapObject`

我們知道 Objective-C 在 runtime 中通過objc_object 來表示一個物件，這些型別定義了物件在記憶體中頭部的結構。同樣的，在 Swift 中也有類似的結構，那就是HeapObject ，我們來看一下它的定義：

struct HeapObject {
/// This is always a valid pointer to a metadata object.
HeapMetadata const *metadata;

SWIFT_HEAPOBJECT_NON_OBJC_MEMBERS;

HeapObject() = default;

// Initialize a HeapObject header as appropriate for a newly-allocated object.
constexpr HeapObject(HeapMetadata const *newMetadata) 
: metadata(newMetadata)
, refCounts(InlineRefCounts::Initialized)
{ }

// Initialize a HeapObject header for an immortal object
constexpr HeapObject(HeapMetadata const *newMetadata,
InlineRefCounts::Immortal_t immortal)
: metadata(newMetadata)
, refCounts(InlineRefCounts::Immortal)
{ }

};

可以看到，HeapObject 的第一個欄位是一個HeapMetadata 物件，這個物件有著與isa_t 類似的作用，就是用來描述物件型別的（等價於type(of:) 取得的結果），只不過 Swift 在很多情況下並不會用到它，比如靜態方法派發等等。

接下來是SWIFT_HEAPOBJECT_NON_OBJC_MEMBERS ，這是一個巨集定義，展開後即：

RefCounts<InlineRefCountBits> refCounts;

這是一個相當重要東西，引用計數、弱引用、unowned 引用都與它有關，同時它也是 Swift 物件（文中後續的 Swift 物件均指引用型別，即class 的例項）中較為複雜的一個結構。

其實說複雜也並不是很複雜，我們知道 Objective-C runtime 裡就有很多union 結構的應用，例如isa_t 有pointer 型別也有nonpointer 型別，它們都佔用了相同的記憶體空間，這樣做的好處就是能更高效地使用記憶體，尤其是這些大量使用到的東西，可以大大減少執行期的開銷。類似的技術在 JVM 裡也有，就如物件頭的 mark word。當然，Swift ABI 中也大量採用這種技術。

`RefCounts` 型別和 Side Table

上面說到RefCounts 型別，這裡我們就來看看它到底是個什麼東西。

先看一下定義：

template <typename RefCountBits>
class RefCounts {
std::atomic<RefCountBits> refCounts;

// ...

};

這就是RefCounts 的記憶體佈局，我這裡省略了所有的方法和型別定義。你可以把RefCounts 想象成一個執行緒安全的 wrapper，模板引數RefCountBits 指定了真實的內部型別，在 Swift ABI 裡總共有兩種：

typedef RefCounts<InlineRefCountBits> InlineRefCounts;
typedef RefCounts<SideTableRefCountBits> SideTableRefCounts;

前者是用在HeapObject 中的，而後者是用在HeapObjectSideTableEntry （Side Table）中的，這兩種型別後文我會一一講到。

一般來講，Swift 物件並不會用到 Side Table，一旦物件被 weak 或 unowned 引用，該物件就會分配一個 Side Table。

InlineRefCountBits

定義：

typedef RefCountBitsT<RefCountIsInline> InlineRefCountBits;

template <RefCountInlinedness refcountIsInline>
class RefCountBitsT {

friend class RefCountBitsT<RefCountIsInline>;
friend class RefCountBitsT<RefCountNotInline>;

static const RefCountInlinedness Inlinedness = refcountIsInline;

typedef typename RefCountBitsInt<refcountIsInline, sizeof(void*)>::Type
BitsType;
typedef typename RefCountBitsInt<refcountIsInline, sizeof(void*)>::SignedType
SignedBitsType;
typedef RefCountBitOffsets<sizeof(BitsType)>
Offsets;

BitsType bits;

// ...

};

通過模板替換之後，InlineRefCountBits 實際上就是一個uint64_t ，相關的一堆型別就是為了通過模板超程式設計讓程式碼可讀性更高（或者更低，哈哈哈）。

下面我們來模擬一下物件引用計數 +1：

呼叫 SIL 介面swift::swift_retain ：

HeapObject *swift::swift_retain(HeapObject *object) {
return _swift_retain(object);
}

static HeapObject *_swift_retain_(HeapObject *object) {
SWIFT_RT_TRACK_INVOCATION(object, swift_retain);
if (isValidPointerForNativeRetain(object))
object->refCounts.increment(1);
return object;
}

auto swift::_swift_retain = _swift_retain_;

呼叫RefCounts 的increment 方法：

void increment(uint32_t inc = 1) {
// 3. 原子地讀出 InlineRefCountBits 物件（即一個 uint64_t）。
auto oldbits = refCounts.load(SWIFT_MEMORY_ORDER_CONSUME);
RefCountBits newbits;
do {
newbits = oldbits;
// 4. 呼叫 InlineRefCountBits 的 incrementStrongExtraRefCount 方法
//對這個 uint64_t 進行一系列運算。
bool fast = newbits.incrementStrongExtraRefCount(inc);
// 無 weak、unowned 引用時一般不會進入。
if (SWIFT_UNLIKELY(!fast)) {
if (oldbits.isImmortal())
return;
return incrementSlow(oldbits, inc);
}
// 5. 通過 CAS 將運算後的 uint64_t 設定回去。
} while (!refCounts.compare_exchange_weak(oldbits, newbits,
std::memory_order_relaxed));
}

到這裡就完成了一次 retain 操作。

SideTableRefCountBits

上面是不存在 weak、unowned 引用的情況，現在我們來看看增加一個 weak 引用會怎樣。

swift::swift_weakAssign
RefCounts<InlineRefCountBits>::formWeakReference

template <>
HeapObjectSideTableEntry* RefCounts<InlineRefCountBits>::formWeakReference()
{
// 分配一個 Side Table。
auto side = allocateSideTable(true);
if (side)
// 增加一個弱引用。
return side->incrementWeak();
else
return nullptr;
}

重點來看一下allocateSideTable 的實現：

template <>
HeapObjectSideTableEntry* RefCounts<InlineRefCountBits>::allocateSideTable(bool failIfDeiniting)
{
auto oldbits = refCounts.load(SWIFT_MEMORY_ORDER_CONSUME);

// 已有 Side Table 或正在析構就直接返回。
if (oldbits.hasSideTable()) {
return oldbits.getSideTable();
} 
else if (failIfDeiniting && oldbits.getIsDeiniting()) {
return nullptr;
}

// 分配 Side Table 物件。
HeapObjectSideTableEntry *side = new HeapObjectSideTableEntry(getHeapObject());

auto newbits = InlineRefCountBits(side);

do {
if (oldbits.hasSideTable()) {
// 此時可能其他執行緒建立了 Side Table，刪除該執行緒分配的，然後返回。
auto result = oldbits.getSideTable();
delete side;
return result;
}
else if (failIfDeiniting && oldbits.getIsDeiniting()) {
return nullptr;
}

// 用當前的 InlineRefCountBits 初始化 Side Table。
side->initRefCounts(oldbits);
// 進行 CAS。
} while (! refCounts.compare_exchange_weak(oldbits, newbits,
std::memory_order_release,
std::memory_order_relaxed));
return side;
}

還記得HeapObject 裡的RefCounts 實際上是InlineRefCountBits 的一個 wrapper 嗎？上面構造完 Side Table 以後，物件中的InlineRefCountBits 就不是原來的引用計數了，而是一個指向 Side Table 的指標，然而由於它們實際都是uint64_t ，因此需要一個方法來區分。區分的方法我們可以來看InlineRefCountBits 的建構函式：

LLVM_ATTRIBUTE_ALWAYS_INLINE
RefCountBitsT(HeapObjectSideTableEntry* side)
: bits((reinterpret_cast<BitsType>(side) >> Offsets::SideTableUnusedLowBits)
| (BitsType(1) << Offsets::UseSlowRCShift)
| (BitsType(1) << Offsets::SideTableMarkShift))
{
assert(refcountIsInline);
}

其實還是最常見的方法，把指標地址無用的位替換成標識位。

順便，看一下 Side Table 的結構：

class HeapObjectSideTableEntry {
// FIXME: does object need to be atomic?
std::atomic<HeapObject*> object;
SideTableRefCounts refCounts;

public:
HeapObjectSideTableEntry(HeapObject *newObject)
: object(newObject), refCounts()
{ }

// ...

};

此時再增加引用計數會怎樣呢？來看下之前的RefCounts::increment 方法：

void increment(uint32_t inc = 1) {
auto oldbits = refCounts.load(SWIFT_MEMORY_ORDER_CONSUME);
RefCountBits newbits;
do {
newbits = oldbits;
bool fast = newbits.incrementStrongExtraRefCount(inc);
// ---> 這次進入這個分支。
if (SWIFT_UNLIKELY(!fast)) {
if (oldbits.isImmortal())
return;
return incrementSlow(oldbits, inc);
}
} while (!refCounts.compare_exchange_weak(oldbits, newbits,
std::memory_order_relaxed));
}
template <typename RefCountBits>
void RefCounts<RefCountBits>::incrementSlow(RefCountBits oldbits,
uint32_t n) {
if (oldbits.isImmortal()) {
return;
}
else if (oldbits.hasSideTable()) {
auto side = oldbits.getSideTable();
// ---> 然後呼叫到這裡。
side->incrementStrong(n);
}
else {
swift::swift_abortRetainOverflow();
}
}
void HeapObjectSideTableEntry::incrementStrong(uint32_t inc) {
// 最終到這裡，refCounts 是一個 RefCounts<SideTableRefCountBits> 物件。
refCounts.increment(inc);
}

到這裡我們就需要引出SideTableRefCountBits 了，它與前面的InlineRefCountBits 很像，只不過又多了一個欄位，看一下定義：

class SideTableRefCountBits : public RefCountBitsT<RefCountNotInline>
{
uint32_t weakBits;

// ...

};

小結一下

不知道上面的內容大家看暈了沒有，反正我一開始分析的時候費了點時間。

上面我們講了兩種RefCounts ，一種是 inline 的，用在HeapObject 中，它其實是一個uint64_t ，可以當引用計數也可以當 Side Table 的指標。

Side Table 是一種類名為HeapObjectSideTableEntry 的結構，裡面也有RefCounts 成員，是內部是SideTableRefCountBits ，其實就是原來的uint64_t 加上一個儲存弱引用數的uint32_t 。

`WeakReference`

上面說的都是被引用的物件所涉及的邏輯，而引用者這邊的邏輯就稍微簡單一些了，主要就是通過WeakReference 這個類來實現的，比較簡單，我們簡單過一下就行。

Swift 中的weak 變數經過 silgen 之後都會變成swift::swift_weakAssign 呼叫，然後派發給WeakReference::nativeAssign ：

void nativeAssign(HeapObject *newObject) {
if (newObject) {
assert(objectUsesNativeSwiftReferenceCounting(newObject) &&
"weak assign native with non-native new object");
}

// 讓被引用者構造 Side Table。
auto newSide =
newObject ? newObject->refCounts.formWeakReference() : nullptr;
auto newBits = WeakReferenceBits(newSide);

// 喜聞樂見的 CAS。
auto oldBits = nativeValue.load(std::memory_order_relaxed);
nativeValue.store(newBits, std::memory_order_relaxed);

assert(oldBits.isNativeOrNull() &&
"weak assign native with non-native old object");
// 銷燬原來物件的弱引用。
destroyOldNativeBits(oldBits);
}

弱引用的訪問就更簡單了：

HeapObject *nativeLoadStrongFromBits(WeakReferenceBits bits) {
auto side = bits.getNativeOrNull();
return side ? side->tryRetain() : nullptr;
}

到這裡大家發現一個問題沒有，被引用物件釋放了為什麼還能直接訪問 Side Table？其實 Swift ABI 中 Side Table 的生命週期與物件是分離的，當強引用計數為 0 時，只有HeapObject 被釋放了。

只有所有的weak 引用者都被釋放了或相關變數被置nil 後，Side Table 才能得以釋放，相見：

void HeapObjectSideTableEntry::decrementWeak() {
// FIXME: assertions
// FIXME: optimize barriers
bool cleanup = refCounts.decrementWeakShouldCleanUp();
if (!cleanup)
return;

// Weak ref count is now zero. Delete the side table entry.
// FREED -> DEAD
assert(refCounts.getUnownedCount() == 0);
delete this;
}

所以即便使用了弱引用，也不能保證相關記憶體全部被釋放，因為只要weak 變數不被顯式置nil ，Side Table 就會存在。而 ABI 中也有可以提升的地方，那就是如果訪問弱引用變數時發現被引用物件已經釋放，就將自己的弱引用銷燬掉，避免之後重複無意義的 CAS 操作。當然 ABI 不做這個優化，我們也可以在 Swift 程式碼裡做。:)

總結

以上就是 Swift 弱引用機制實現方式的一個簡單的分析，可見思路與 Objective-C runtime 還是很類似的，都採用與物件匹配的 Side Table 來維護引用計數。不同的地方就是 Objective-C 物件在記憶體佈局中沒有 Side Table 指標，而是通過一個全域性的StripedMap 來維護物件和 Side Table 之間的關係，效率沒有 Swift 這麼高。另外 Objective-C runtime 在物件釋放時會將所有的__weak 變數都 zero-out，而 Swift 並沒有。

總的來說，Swift 的實現方式會稍微簡單一些（雖然程式碼更復雜，Swift 團隊追求更高的抽象）。第一次分析 Swift ABI，本文僅供參考，如果存在錯誤，歡迎大家勘正。感謝！

從原始碼解析 Swift 弱引用

準備工作

正文

HeapObject

RefCounts 型別和 Side Table