ARC 정리 - Low-level까지 딥다이브

그림과 같이 메모리해제가 이루어진다. Freed 상태는 weak 참조만 남아 있는 상태로 swift 4.0 이전의 문제가 해결되는 모습을 볼수 있다.

Freed 상태에서는 참조당하는 객체는 할당해제된 상태지만 사이드 테이블(모든 weak variable에 nil이 할당된)만 남아 있으며 weak 참조를 통해 접근하게 되면 nil을 반환 받고 weak rc를 감소시킨다.

즉 unowned의 존재와 사용이유는 사이드 테이블 생성과 사이드 테이블을 순회하며 nil을 할당하는 zeroing weak reference 과정 없이 참조당하는 객체의 메모리를 효율적으로 관리할 수 있기 때문..!

저수준 단계에서의 메모리 관리

지금까지는 swift complie structure의 semantic analysis 단계에서의 ARC과정을 알아보았다.. 실제 Canonical SIL 코드를 보며 좀더 저수준 언어에서 어떻게 처리되는지 알아보자..

class aClass{
    var value = 1
}

let object1 = aClass()
let object2 = aClass()
let object3 = aClass()


class bClass{
    var o1 = object1
    weak var o2 = object2
    unowned var o3 = object3
}

let b = bClass()
b.o1.value = 10
b.o2?.value = 10
b.o3.value = 10

위 코드를 변환하면 너무 긴 SIL 코드가 나오므로 관련있는 부분만 살펴보자..

SIL 문법 알아보기

1. 변수 초기화 부분

// object1 초기화
alloc_global @$s4main7object1AA6aClassCvp       // 전역 변수 object1을 위한 메모리 할당
%3 = global_addr @$s4main7object1AA6aClassCvp : $*aClass
%5 = function_ref @$s4main6aClassCACycfC : $@convention(method) (@thick aClass.Type) -> @owned aClass
%6 = apply %5(%4) : $@convention(method) (@thick aClass.Type) -> @owned aClass  // aClass 인스턴스 생성
store %6 to %3 : $*aClass                       // 생성된 인스턴스를 object1에 저장

// object2 초기화 (object1과 유사)
alloc_global @$s4main7object2AA6aClassCvp
%9 = global_addr @$s4main7object2AA6aClassCvp : $*aClass
%12 = apply %11(%10) : $@convention(method) (@thick aClass.Type) -> @owned aClass
store %12 to %9 : $*aClass

// object3 초기화 (object1과 유사)
alloc_global @$s4main7object3AA6aClassCvp
%15 = global_addr @$s4main7object3AA6aClassCvp : $*aClass
%18 = apply %17(%16) : $@convention(method) (@thick aClass.Type) -> @owned aClass
store %18 to %15 : $*aClass

// b 초기화
alloc_global @$s4main1bAA6bClassCvp
%21 = global_addr @$s4main1bAA6bClassCvp : $*bClass
%24 = apply %23(%22) : $@convention(method) (@thick bClass.Type) -> @owned bClass
store %24 to %21 : $*bClass

2. 참조 카운트 관리 부분(ref count 증감하는 부분만)

// o1(강한 참조)
// 강한 참조 증가
%28 = apply %27(%26) : $@convention(method) (@guaranteed bClass) -> @owned aClass
strong_retain %28 : $aClass

// 강한 참조 감소
strong_release %28 : $aClass


// o2(약한 참조)
// 약한 참조를 통한 객체 접근 (강한 참조 증가)
%48 = load %47 : $*aClass
strong_retain %48 : $aClass

// 강한 참조 감소
strong_release %48 : $aClass

// 약한 참조를 통한 메모리 관리
store_weak %11 to %7 : $*@sil_weak Optional<aClass>


// o3(소유되지 않은 참조)
// unowned 참조에서 strong 참조로 변환
%63 = apply %62(%61) : $@convention(method) (@guaranteed bClass) -> @owned aClass
%66 = class_method %63 : $aClass, #aClass.value!setter : (aClass) -> (Int) -> ()

// unowned 참조 증가
unowned_retain %18 : $@sil_unowned aClass

// unowned 참조 감소
unowned_release %9 : $@sil_unowned aClass

// 강한 참조 감소
strong_release %63 : $aClass

3. 메모리 해제 부분

// bClass.deinit()
sil hidden @$s4main6bClassCfd : $@convention(method) (@guaranteed bClass) -> @owned Builtin.NativeObject {
  %2 = ref_element_addr %0 : $bClass, #bClass.o1  // o1에 대한 접근
  destroy_addr %2 : $*aClass                      // o1 인스턴스 해제
  %6 = ref_element_addr %0 : $bClass, #bClass.o2  // o2에 대한 접근
  destroy_addr %6 : $*@sil_weak Optional<aClass>  // o2 인스턴스 해제
  %10 = ref_element_addr %0 : $bClass, #bClass.o3 // o3에 대한 접근
  destroy_addr %10 : $*@sil_unowned aClass        // o3 인스턴스 해제
  
  %2 = ref_element_addr %0 : $bClass, #bClass.o1  // o1에 대한 접근
  %3 = begin_access [deinit] [static] %2 : $*aClass
  destroy_addr %3 : $*aClass                      // o1 인스턴스 해제
  end_access %3 : $*aClass                        // id: %5
  
  %6 = ref_element_addr %0 : $bClass, #bClass.o2  // o2에 대한 접근
  %7 = begin_access [deinit] [static] %6 : $*@sil_weak Optional<aClass> // users: %9, %8
  destroy_addr %7 : $*@sil_weak Optional<aClass>  // o2 인스턴스 해제
  end_access %7 : $*@sil_weak Optional<aClass>    // id: %9
  
  %10 = ref_element_addr %0 : $bClass, #bClass.o3 // o3에 대한 접근
  %11 = begin_access [deinit] [static] %10 : $*@sil_unowned aClass // users: %13, %12
  destroy_addr %11 : $*@sil_unowned aClass        // o3 인스턴스 해제
  end_access %11 : $*@sil_unowned aClass          // id: %13
}

// bClass.__deallocating_deinit()
sil hidden @$s4main6bClassCfD : $@convention(method) (@owned bClass) -> () {
  %2 = function_ref @$s4main6bClassCfd
  %3 = apply %2(%0)                               // deinit 호출
  dealloc_ref %4 : $bClass                        // 메모리 해제
}

SIl 코드를 통해 알게된 점

ref count를 관리하는 방식
Swift doc의 SIL - ref counting 부분에서 확인해보면

• strong_retain: 객체의 강력한 유지 수를 늘립니다.

• strong_release: 객체의 강력한 참조 카운트를 감소시킵니다. release 연산이 객체의 강력한 참조 카운트를 0으로 만들면 객체가 파괴되고 약한 참조가 지워집니다. 강력한 참조 카운트와 소유되지 않은 참조 카운트가 모두 0에 도달하면 객체의 메모리가 할당 해제됩니다.

• unowned_retain: 힙 객체의 소유되지 않은 참조 횟수를 증가시킵니다.

• unowned_release: 객체의 unowned 참조 카운트를 감소시킵니다. strong 참조 카운트와 unowned 참조 카운트가 모두 0에 도달하면 객체의 메모리가 할당 해제됩니다.

• load_weak: 실제 ARC 호출은 아니지만 선택 사항에 의해 참조되는 객체의 강력한 참조 횟수를 증가시킵니다.

• store_weak: 약한 참조를 초기화하거나 재할당합니다.

참조 방식과 상관없이 strong ref count를 참조해 연산하거나 변환하는 방식...
실제로 3가지의 참조방식 모두 컴파일 단계에서 ref count를 개념적으로 저장하는 변수가 있지만 최적화를 통해 Strong ref count를 가지고 다른 참조 카운트를 운용하는 것을 확인할 수 있다.

+) https://www.uraimo.com/2016/10/27/unowned-or-weak-lifetime-and-performance/ 에 따르면 내부적으로 Strong reference counter와 additional weak reference counter 두가지를 운용하며 내부적으로 ref count를 처리한다고 하지만, RefCount.h, HeapObject.h, HeapObject.cpp, Heap.cpp 등 SIL 문서 커밋로그까지 다 확인해도 해당 내용을 확인 할 수 없었다..

아마 개념적으로 32bit(+64bit도 해당) RefCount 객체가 StrongExtraRefCount와 UnownedRefCount 두가지를 가지고 연산하는 걸 개념적으로 설명한거라고 생각된다.. (너무 오래되기도 했고),,

참조가 생성되거나 해제 될 때 현재 객체의 참조관련 상태를 읽고 상태에 따라 다르게 동작한다는 정도만 알면 될듯 하다..
ex) strong_retain_unowned

자세하게 알고 싶다면 SIL ref counting과 swift 헤더 파일들을 확인해보는게 좋을 듯하다..

정리

(low-level에서의 참조 카운트 관리는 사실 몰라도 상관없다고 생각한다..)
객체는 strong, weak, unowned 각각 참조 카운터를 가지고 있으며, weak 참조를 통해 side-table을 생성하고 바로 접근할 수 있으며 strong과 unowned는 객체에 직접 접근한다.

메모리 해제 과정에 있어
side-table 을 순환하며 nil을 할당하는 zeroing weak, weak ref count의 strong ref count로의 변환에 있어 멀티쓰레드 환경에서의 레이스 컨디션 등의 과정이 추가적으로 필요해 weak 참조는 unowned 참조에 비해 오버헤드가 비교적 크다.

swift ARC 공식 문서
에서 확인할 수 있듯 퍼포먼스와 메모리 최적화를 위해 unowned를 사용할수 있는 상황일 때는 unowned 사용에 대한 런타임 에러, 복잡한 구조에서의 사이드 이펙트를 피하기위해 방어적으로 weak을 사용하기 보단 한번더 고민하고 적극적으로 도입해 보자..
ex) 클로저는 캡처된 객체와 동일한 수명을 가지므로 객체에 도달할 수 있을 때까지만 클로저에 도달할 수 있으며 외부 객체와 클로저는 동일한 수명을 갖는, 객체와 부모 간의 간단한 역참조 상황)

+) 여러 메모리 관리 도구들을 통해 의도적으로 weak 참조의 오버헤드를 증가시켜도 의미있는 차이를 확인하지 못함...
최적화 단계가 아닌 구현 개발 단계라면 그냥 weak을 사용하는게 맞다고 생각한다...

References

• https://www.uraimo.com/2016/10/27/unowned-or-weak-lifetime-and-performance/
• https://maximeremenko.com/swift-arc-weak-references
• https://github.com/swiftlang/swift/blob/d1c87f3c936c41418ee93320e42d523b3f51b6df/stdlib/public/SwiftShims/RefCount.h#L44
• https://docs.swift.org/swift-book/documentation/the-swift-programming-language/automaticreferencecounting/#Resolving-Strong-Reference-Cycles-Between-Class-Instances
• https://www.vadimbulavin.com/
• https://apple-swift.readthedocs.io/en/latest/SIL.html#id2
• https://github.com/swiftlang/swift/blob/main/docs/SIL.rst