iOS Advanced - iOS Memory Management

1 It seems that everyone has considered the problem when learning iOS

• What does alloc retain release delloc do?
• How is autoreleasepool implemented?
• What is __unsafe_unretained?
• How Block is implemented
• When does a retain cycle occur and when does it not?

So in this blog post I will explain in detail from ARC to iOS memory management, as well as Block-related principles and source codes.

2. Let’s start with ARC

When talking about iOS memory management, we have to start with ARC (Automatic Reference Counting), which was introduced by WWDC2011 and iOS5. ARC is a feature of the LLVM 3.0 compiler that is used to automatically manage memory.

Unlike GC in Java, ARC is a compiler feature rather than a runtime feature, so ARC actually automatically helps developers insert memory management code during the compilation phase rather than real-time monitoring and memory recovery.

ARC's memory management rules can be summarized as follows:

• Each object has a reference count.
• The object is held, and the reference count is +1.
• The object is abandoned, and the reference count is -1.
• "Reference count" = 0, release the object

3 What you need to know

• The Foundation framework, which contains the NSObject class, is not publicly available.
• The Core Foundation framework source code and some of the source code for memory management through NSObject are public.
• GNUstep is an interchange framework for the Foundation framework

GNUstep is also one of the GNU projects. It reimplements the Cocoa Objective-C software library as free software.

In a sense, the implementation of GNUstep and Foundation frameworks is similar.

Analyzing Foundation's memory management through GNUstep source code

4 Implementation of alloc retain release dealloc

4.1 GNU – alloc

See the alloc function in GNUStep.

GNUstep/modules/core/base/Source/NSObject.m alloc:

 + (id) alloc 
 
 { 
 
 return [self allocWithZone: NSDefaultMallocZone()]; 
 
 }  
  
 
 + (id) allocWithZone: (NSZone*)z 
 
 { 
 
 return NSAllocateObject (self, 0, z); 
 
 }

GNUstep/modules/core/base/Source/NSObject.m NSAllocateObject:

 struct obj_layout { 
 
 NSUInteger retained; 
 
 }; 
 
  
 
 NSAllocateObject(Class aClass, NSUInteger extraBytes, NSZone *zone) 
 
 { 
 
 int   size = calculate the memory size required to accommodate the object; 
 
 id new = NSZoneCalloc(zone, 1, size ); 
 
 memset (new, 0, size ); 
 
 new = (id)&((obj)new)[1]; 
 
 }

The NSAllocateObject function allocates the space required to store the object by calling the NSZoneCalloc function, then sets the memory space to nil, and finally returns a pointer to be used as the object.

We simplify the above code:

GNUstep/modules/core/base/Source/NSObject.m alloc simplified version:

 struct obj_layout { 
 
 NSUInteger retained; 
 
 }; 
 
  
 
 + (id) alloc 
 
 { 
 
 int   size = sizeof(struct obj_layout) + object size; 
 
 struct obj_layout *p = (struct obj_layout *)calloc(1, size ); 
 
 return (id)(p+1) 
 
 return [self allocWithZone: NSDefaultMallocZone()]; 
 
 }

The alloc class method uses the retained integer in struct obj_layout to save the reference count and writes it to the memory header of the object. It then returns after all memory blocks of the object are set to 0.

The representation of an object is as follows:

4.2 GNU – retain

GNUstep/modules/core/base/Source/NSObject.m retainCount:

 - (NSUInteger) retainCount 
 
 { 
 
 return NSExtraRefCount(self) + 1; 
 
 } 
  
 
 inline NSUInteger 
 
 NSExtraRefCount(id anObject) 
 
 { 
 
 return ((obj_layout)anObject)[-1].retained; 
 
 }

GNUstep/modules/core/base/Source/NSObject.m retain:

 - (id) retain 
 
 { 
 
 NSIncrementExtraRefCount(self); 
 
 return self; 
 
 } 
 
  
 
 inline void 
 
 NSIncrementExtraRefCount(id anObject) 
 
 { 
 
 if (((obj)anObject)[-1].retained == UINT_MAX - 1) 
 
 [NSException raise: NSInternalInconsistencyException 
 
 format: @"NSIncrementExtraRefCount() asked to increment too far"]; 
 
 ((obj_layout)anObject)[-1].retained++; 
 
 }

In the above code, the NSIncrementExtraRefCount method first writes the code that causes an exception when the retained variable exceeds the maximum value (because retained is an NSUInteger variable), and then performs the retain++ code.

4.3 GNU – release

Corresponding to retain, the release method does retain --.

GNUstep/modules/core/base/Source/NSObject.m release

 - (oneway void) release 
 
 { 
 
 if (NSDecrementExtraRefCountWasZero(self)) 
 
 { 
 
 [self dealloc]; 
 
 } 
 
 } 
 
  
 
 BOOL 
 
 NSDecrementExtraRefCountWasZero(id anObject) 
 
 { 
 
 if (((obj)anObject)[-1].retained == 0) 
 
 { 
 
 return YES; 
 
 } 
 
 ((obj)anObject)[-1].retained --;   
 
 return   NO ; 
 
 }

4.4 GNU – dealloc

dealloc will release the object.

GNUstep/modules/core/base/Source/NSObject.m dealloc:

 - (void) dealloc 
 
 { 
 
 NSDeallocateObject (self); 
 
 } 
  
 
 inline void 
 
 NSDeallocateObject(id anObject) 
 
 { 
 
 obj_layout o = &((obj_layout)anObject)[-1]; 
 
 free (o); 
 
 }

4. ***pple implementation

In Xcode, set Debug -> Debug Workflow -> Always Show Disassenbly to on. This way, you can see more detailed method calls after the breakpoint.

By setting breakpoints on alloc and other methods of the NSObject class, you can see that several methods are called internally:

retainCount

 __CFdoExternRefOperation
 CFBasicHashGetCountOfKey

retain

 __CFdoExternRefOperation
 CFBasicHashAddValue

release

 __CFdoExternRefOperation
 CFBasicHashRemoveValue

You can see that they all call a common __CFdoExternRefOperation method.

As you can see from the prefix, this method is included in Core Foundation and can be found in CFRuntime.c. The source code is simplified and listed as follows:

CFRuntime.c __CFDoExternRefOperation:

 int __CFDoExternRefOperation(uintptr_t op, id obj) { 
 
 CFBasicHashRef table = get the hash table of the object (obj); 
 
 int   count ; 
 
  
 
 switch (op) { 
 
 case OPERATION_retainCount: 
 
 count = CFBasicHashGetCountOfKey( table , obj); 
 
 return   count ; 
 
 break; 
 
 case OPERATION_retain: 
 
 count = CFBasicHashAddValue( table , obj); 
 
 return obj; 
 
 case OPERATION_release: 
 
 count = CFBasicHashRemoveValue( table , obj); 
 
 return 0 == count ; 
 
 } 
 
 }

Therefore, __CFDoExternRefOperation performs specific method calls for different operations. If op is OPERATION_retain, the method that specifically implements retain is removed.

From the method name BasicHash, we can see that the reference count table is actually a hash table.

The key is the hash (the address of the object) and the value is the reference count.

The following figure compares Apple and GNU's implementation:

5 autorelease and autorelaesepool

Apple's documentation for NSAutoreleasePool states:

Each thread (including the main thread) maintains a stack of managed NSAutoreleasePools. When a new Pool is created, they are added to the top of the stack. When the Pool is destroyed, they are removed from the stack.

The autorelease object will be added to the Pool at the top of the current thread's stack. When the Pool is destroyed, the objects in it will also be released.

When the thread ends, all Pools are destroyed and released.

Set breakpoints on the NSAutoreleasePool class method and the autorelease method, and view its running process. You can see that the following functions are called:

 NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; 
 
 // Equivalent to objc_autoreleasePoolPush 
 
  
 
 id obj = [[NSObject alloc] init]; 
 
 [obj autorelease]; 
 
 // Equivalent to objc_autorelease(obj) 
 
  
 
 [NSAutoreleasePool showPools]; 
 
 // Check NSAutoreleasePool status 
 
  
 
 [pool drain]; 
 
 // Equivalent to objc_autoreleasePoolPop(pool)

[NSAutoreleasePool showPools] can show the status of all pools of the current thread:

 objc[21536]: ############## 
 
 objc[21536]: AUTORELEASE POOLS for thread 0x10011e3c0 
 
 objc[21536]: 2 releases pending. 
 
 objc[21536]: [0x101802000] ............ PAGE (hot) (cold) 
 
 objc[21536]: [0x101802038] ################ POOL 0x101802038 
 
 objc[21536]: [0x101802040] 0x1003062e0 NSObject 
 
 objc[21536]: ############## 
 
 Program ended with exit code: 0

In objc4, you can see AutoreleasePoolPage:

 objc4/NSObject.mm AutoreleasePoolPage 
 
  
 
 class AutoreleasePoolPage 
 
 { 
 
 static inline void *push() 
 
 { 
 
 Create or hold NSAutoreleasePool class objects 
 
 } 
 
 static inline void pop(void *token) 
 
 { 
 
 Deprecated NSAutoreleasePool class objects 
 
 releaseAll(); 
 
 } 
 
 static inline id autorelease(id obj) 
 
 { 
 
 Equivalent to the addObject class method of the NSAutoreleasePool class 
 
 AutoreleasePoolPage *page = Get the AutoreleasePoolPage instance in use; 
 
 } 
 
 id * add (id obj) 
 
 { 
 
 Appends the object to the internal array 
 
 } 
 
 void releaseAll() 
 
 { 
 
 Call the release method of the object in the internal array 
 
 } 
 
 }; 
 
  
 
 void * 
 
 objc_autoreleasePoolPush(void) 
 
 { 
 
 if (UseGC) return nil; 
 
 return AutoreleasePoolPage::push(); 
 
 } 
 
  
 
 void 
 
 objc_autoreleasePoolPop(void *ctxt) 
 
 { 
 
 if (UseGC) return ; 
 
 AutoreleasePoolPage::pop(ctxt); 
 
 }

AutoreleasePoolPage is composed in the form of a doubly linked list (corresponding to the parent pointer and child pointer in the structure).

The thread pointer points to the current thread.

Each AutoreleasePoolPage object will allocate 4096 bytes of memory (that is, the size of one page of virtual memory). In addition to the space occupied by the above instance variables, the remaining space is used to store the address of the autorelease object.

The next pointer points to the location where the next autorelease object added will be stored.

When the space of a Page is full, a new AutoreleasePoolPage object will be created to connect to the linked list.

6 __unsafe_unretained

Sometimes we also use the __unsafe_unretained modifier in addition to __weak and __strong, so how much do we know about __unsafe_unretained?

__unsafe_unretained is an unsafe ownership modifier. Although ARC memory management is the work of the compiler, variables with the __unsafe_unretained modifier do not belong to the compiler's memory management objects. Neither strong references nor weak references are obtained when assigning values.

Let's run a piece of code:

 id __unsafe_unretained obj1 = nil; 
 
 { 
 
 id __strong obj0 = [[NSObject alloc] init];  
  
 
 obj1 = obj0;  
  
 
 NSLog(@ "A: %@" , obj1); 
 
 }  
  
 
 NSLog(@ "B: %@" , obj1);

Running results:

 2017-01-12 19:24:47.245220 __unsafe_unretained[55726:4408416] A: 
 
 2017-01-12 19:24:47.246670 __unsafe_unretained[55726:4408416] B: 
 
 Program ended with exit code: 0

Detailed analysis of the code:

 id __unsafe_unretained obj1 = nil; 
 
 { 
 
 // Generate and hold the object yourself 
 
 id __strong obj0 = [[NSObject alloc] init]; 
 
  
 
 // Because obj0 variable is a strong reference, 
 
 // So I hold the object myself 
 
 obj1 = obj0; 
 
  
 
 // Although obj0 variable is assigned to obj1 
 
 // But the obj1 variable holds neither a strong reference nor a weak reference to the object 
 
 NSLog(@ "A: %@" , obj1); 
 
 // Output the object represented by the obj1 variable 
 
 } 
 
  
 
 NSLog(@ "B: %@" , obj1); 
 
 // Output the object represented by the obj1 variable 
 
 // The object represented by the obj1 variable has been discarded 
 
 // So what you get at this time is a dangling pointer 
 
 // Error access

Therefore, the *** NSLog just happens to run normally. If it is accessed incorrectly, it will cause a crash.

When using the __unsafe_unretained modifier, when assigning to a variable with the __strong modifier, make sure that the object actually exists.