Detailed explanation: Objective-C Class Ivar Layout

This exploration stems from a question asked by a friend. When we define an instance variable of a class, we can specify its modifier:

 @interface Sark : NSObject {
 __strong id _gayFriend; // Objects without modifiers will be added with __strong by default  
 __weak id _girlFriend;
 __unsafe_unretained id _company;
 }
 @end  

This allows ivar (instance variable) to be correctly reference counted under ARC just like properties.

So the question is, if this class is dynamically generated:

 Class class = objc_allocateClassPair(NSObject. class , "Sark" , 0 );
 class_addIvar( class , "_gayFriend" , sizeof(id), log2(sizeof(id)), @encode (id));
 class_addIvar( class , "_girlFriend" , sizeof(id), log2(sizeof(id)), @encode (id));
 class_addIvar( class , "_company" , sizeof(id), log2(sizeof(id)), @encode (id));
 objc_registerClassPair( class );

How do you add property modifiers to ivar like above?

After some investigation, I found that the modification information of ivar is stored in the Ivar Layout of Class:

 struct class_ro_t {
 uint32_t flags;
 uint32_t instanceStart;
 uint32_t instanceSize;
 #ifdef __LP64__
 uint32_t reserved;
 #endif
 const uint8_t * ivarLayout; // <- records which ivars are strong   
 
 const   char * name;
 const method_list_t * baseMethods;
 const protocol_list_t * baseProtocols;
 const ivar_list_t *ivars;
 const uint8_t * weakIvarLayout; // <- records which ivars are weak  
 const property_list_t *baseProperties;
 };

ivarLayout and weakIvarLayout respectively record which ivars are strong or weak. What is not recorded are the basic types and __unsafe_unretained object types.

These two values ​​can be accessed through several APIs provided by the runtime:

 const uint8_t *class_getIvarLayout(Class cls)
 const uint8_t *class_getWeakIvarLayout(Class cls)
 void class_setIvarLayout(Class cls, const uint8_t *layout)
 void class_setWeakIvarLayout(Class cls, const uint8_t *layout)

But we are unlikely to use these APIs. The value of IvarLayout is determined by the runtime, so there is no need to care about its existence. However, in order to solve the above problems, we tried to crack the encoding method of IvarLayout.

For example, if the class is defined as:

 @interface Foo : NSObject {
 __strong id ivar0;
 __weak id ivar1;
 __weak id ivar2;
 }
 @end  

The value of ivarLayout storing strong ivar is 0x012000

The value of weakIvarLayout that stores weak ivar is 0x1200

A uint8_t is two digits in hexadecimal, so the encoded value is a pair of two digits. Take the above ivarLayout as an example:

The first two digits 01 indicate that there are 0 non-strong objects and 1 strong object.

The next two digits 20 indicate that there are 2 non-strong objects and 0 strong objects.

***The two 00s are the end character, just like the \0 in cstring

Similarly, the weakIvarLayout above:

The first two digits 12 indicate that there is 1 non-weak object and the next 2 consecutive weak objects.

00 End character

In this way, two layout code values ​​can be used to check whether an ivar is strong or weak. If neither is found, it means that the object is unsafe_unretained.

As an exercise, if the class is defined as:

 @interface Bar : NSObject {
 __weak id ivar0;
 __strong id ivar1;
 __unsafe_unretained id ivar2;
 __weak id ivar3;
 __strong id ivar4;
 }
 @end  

The value of ivarLayout storing strong ivar is 0x012100

The value of weakIvarLayout that stores weak ivar is 0x01211000

 Class class = objc_allocateClassPair(NSObject. class , "Sark" , 0 );
 class_addIvar( class , "_gayFriend" , sizeof(id), log2(sizeof(id)), @encode (id));
 class_addIvar( class , "_girlFriend" , sizeof(id), log2(sizeof(id)), @encode (id));
 class_addIvar( class , "_company" , sizeof(id), log2(sizeof(id)), @encode (id));
 class_setIvarLayout( class , ( const uint8_t *) "\x01\x12" ); // <--- new  
 class_setWeakIvarLayout( class , ( const uint8_t *) "\x11\x10" ); // <--- new  
 objc_registerClassPair( class );

I thought I had solved this problem, but the runtime continued to slap me in the face, and the strong and weak memory management did not take effect. I continued to study and found that there is a flag in the class flags to record whether the class is ARC. When the class is compiled normally and marked with the -fobjc-arc flag, this flag is 1, but the dynamically created class does not set it. So I can only continue to use black magic to set this flag at runtime. I will not go into details about the exploration process. The implementation is as follows:

 static   void fixup_class_arc(Class class ) {
 struct {
 Class isa;
 Class superclass;
 struct {
 void *_buckets;
 uint32_t _mask;
 uint32_t _occupied;
 } cache;
 uintptr_t bits;
 } *objcClass = (__bridge typeof(objcClass)) class ;
 # if !__LP64__
 #define FAST_DATA_MASK 0xfffffffcUL
 # else  
 #define FAST_DATA_MASK 0x00007ffffffffff8UL
 #endif
 struct {
 uint32_t flags;
 uint32_t version;
 struct {
 uint32_t flags;
 } *ro;
 } *objcRWClass = (typeof(objcRWClass))(objcClass->bits & FAST_DATA_MASK);
 #define RO_IS_ARR 1flags |= RO_IS_ARR;
 }

After putting this fixup in objc_registerClassPair(class);, the dynamic class can finally operate ivar like the statically compiled class. You can test it:

 id sark = [ class   new ];
 Ivar weakIvar = class_getInstanceVariable( class , "_girlFriend" );
 Ivar strongIvar = class_getInstanceVariable( class , "_gayFriend" );
 {
 id girl = [NSObject new ];
 id boy = [NSObject new ];
 object_setIvar(sark, weakIvar, girl);
 object_setIvar(sark, strongIvar, boy);
 } // ARC will release the girl and boy in the curly braces here  
 // Output: weakIvar is nil, strongIvar has a value  
 NSLog(@ "%@, %@" , object_getIvar(sark, weakIvar), object_getIvar(sark, strongIvar));

Done.