Do you understand 50% of alloc and init?

Preface

This is a note that records my analysis and thinking about alloc and init. If readers want to understand my second thought, you may need to at least understand the segmentation and paging management of memory. If you don’t know anything about it, you can read this soft article to learn about it briefly. Another important point is, please think first.

Thinking 1. Why do objects need alloc, and what is init for?

Many people know that to initialize an object, you should write:

 MyClass* myObj = [MyClass alloc] init];

Have you ever thought about why? In fact, it is completely OK for me to write it like this:

 MyClass *myObj = [MyClass alloc];
 myObj = [myObj init];

Let's see what this does.

 alloc allocates a chunk of memory to hold the object, and   returns the pointer.

That is to say, alloc allocates a piece of memory to the object, does not release it, and returns the address to the pointer.

 MyClass *myObj = [MyClass alloc];

So why can't myobj be used after this? This is because this piece of memory has not been initialized correctly.

For example, if Wanda wants to build a house, the first step must be to obtain a piece of land from the government, and the second step is to start building the building on this land.

Here the operating system is the government, alloc is to fight for land, and init is to build a house on the ground. Without calling init, the house is not built, how can others buy a house and live in it? So we need to use init to initialize this piece of memory:

 -init{ 
 
 self=[super init]; // 1. 
 
 if(self){ // 2. 
 
 .... 
 
 } 
 
 return self; // 3. 
 
 }

The first step is to initialize the parent class information, such as instance variables, etc. It can be understood as Wang Sicong asking his father for his opinion before building a house. His father said he wanted to build an entertainment club. If he had no objection, he would build it into an entertainment club. If he had an objection, he could quietly change it to a LOL club in the second step. I won't talk about the third step.

Finally, a reminder, don’t write like this:

 MyClass* myObj = [MyClass alloc];
 myObj=[myObj init];

Because you might forget to add init in the second line and the code will grow.

Thinking 2. Thinking about alloc

In Thinking 1, we said that alloc allocates a piece of memory to the object, does not release it, and returns the address to the pointer. There are two main problems here:

• After calling alloc, is the memory directly mapped to the heap or is it only allocated to virtual memory?
• How big is this memory?

Let’s expand on each one.

Some readers may not understand what the first question means. Here we need to talk about some additional things about memory. In fact, this is a very important thing in iOS development, and it may be used in interviews or learning.

Extra Stuff

The memory in iOS is classified into Clean Memory and Dirty Memory. As the name implies, Clean Memory can be reclaimed by the operating system, while Dirty Memory cannot be reclaimed by the operating system.

• Clean Memory: There is a backup in the flash memory, which can be read and rebuilt again. For example:

Code, framework, memory-mapped files

• Dirty Memory: All non-clean memories, such as:

Allocated heap space, image cache

For example, in code like this:

 - (void)dirtyOrCleanMemory 
 
 { 
 
    NSString *str1 = [NSString stringWithString:@ "Welcome!" ]; // 1. 
 
    NSString *str2 = @ "Welcome" ; // 2. 
 
     
 
 char *buf = malloc(100 * 1024 * 1024); // 3. Allocate 100M memory to buf 
 
     
 
 for ( int i = 0; i < 3 * 1024 * 1024; ++i) { 
 
 buf[i] = rand(); 
 
 } // 4. The first 3M memory of buf is assigned 
 
 }

Analyze each line:

1.Dirty Memory.

Because stringWithString: allocates memory on the heap, if we don't recycle it, the system will always occupy this memory.

2.Clean Memory.

Because this method creates a constant string, which is placed in the read-only data segment. If this memory is released and we access it again, the operating system can read the value in the read-only data segment and rebuild this memory. (ps: So the string created in this way has no reference count.)

The following knowledge is to lead to the more important points of thinking about questions 1 and 2:

3.Clean Memory.

At this time, the 100M memory area pointed to by buf is Clean Memory, because the operating system is very lazy. It will only map this area to physical memory when we need it. When it is not used, it will only allocate a piece of virtual memory to buf. It is very confusing to read, here is a picture:

You can see that there is no mapping relationship between virtual memory and physical memory, so it is Clean Memory.

4.Dirty & Clean Memory mixed.

The first 3M is Dirty Memory, and the last 97M is Clean Memory. After the for statement is executed, the first 3M of buf is assigned, that is, the first 3M of buf is used, so the mapping relationship at this time is as follows:

Extra stuff done.

Back to the main thread

After calling alloc, is the memory directly mapped to the heap (physical memory) or is it only allocated to virtual memory?

How big is a lump of memory?

At this point, the readers should understand our first question. So how do we verify whether alloc is directly mapped to the heap or only allocated to virtual memory? This question made me think for several days, and finally Brother XO thought of a good remedy to verify it, that is, to use instrument to infer the opposite.

Using instrumentation to disprove

Our assumption is that after receiving the alloc message, the object only allocates space in the virtual memory.

This requires a little bit of code.

1. Let’s create a new project casually.

2. Then make a model class:

 #import <Foundation/Foundation.h> 
 
  
 
 @interface XOModel : NSObject 
 
 { 
 
 int a1; 
 
 NSString *a2; 
 
 } 
 
  
 
 @ end  

3. Add a click event to the view in the controller:

 - (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event { 
 
 for ( int i = 0; i < 100000; ++i) { 
 
 XOModel *model = [XOModel alloc]; // Note that this sentence only has alloc 
 
        [self.array addObject:model]; 
 
 } 
 
 }

4. Open the instrument's alloction, run and trigger a click event, and see the following:

(Graphic: Persistent bytes indicates the size of all such things in the heap, and Persistent indicates the number of all such things.)

We found that 3.05MB of space was actually allocated to the XOModel in the Persistent bytes (heap).

Let's trigger the click event again:

It was found that the heap space allocated to XOModel became twice the original size, 6.10MB.

Conclusion transition: If the object receives the alloc message and only allocates space in the virtual memory, then the persistent bytes (heap) will not be allocated to the XOModel size, which means that the persistent bytes size here should be 0. So the conclusion of question 1 is as follows:

Conclusion: alloc not only allocates in virtual memory, but also creates a mapping in physical memory.

Memory allocation for objects

Finally, we have one last question: After the class object receives the alloc message, how much memory will the operating system allocate?

The size of 3.05M is the sum of 100,000 XOModel objects. So how much space will the operating system allocate to an instance object of XOModel? It's very simple, 3.05M/100,000 and we get it. Wait, are you really going to calculate it this way? Well, actually I thought about it this way at the beginning, but this will definitely not give an accurate answer. The key is that you have to think about it.

There are two methods here, and I use the second one.

The first verification method is still instrument

We can modify the triggered code and then refresh the instrument to view the size of XOModel. The specific operations are the same as above and will not be repeated:

 - (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event { 
 
 for ( int i = 0; i < 1; ++i) { // Modifications 
 
 XOModel *model = [XOModel alloc]; // Note that this sentence only has alloc 
 
        [self.array addObject:model]; 
 
 } 
 
 }

The second verification method uses runtime

We can use the runtime to check the memory size required by a class object. It is worth mentioning that the method I used at the beginning was class_getInstanceSize, and its prototype is as follows:

 /** 
 
 * Returns the size   of instances of a class. 
 
 * 
 
 * @param cls A class object. 
 
 * 
 
 * @return The size   in bytes of instances of the class \e cls, or \c 0 if \e cls is \c Nil. 
 
 */ 
 
 OBJC_EXPORT size_t class_getInstanceSize(Class cls) 
 
     __OSX_AVAILABLE_STARTING(__MAC_10_5, __IPHONE_2_0);

It seems to be the function we need, but I found that this method has a bug. The returned size is different from the value of instruments. Later, I found that someone encountered the same problem, so I copied another method. The code is as follows:

 #import <objc/runtime.h> 
 
 #import <malloc/malloc.h> 
 
 ... 
 
 - (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event { 
 
    XOModel *model = [XOModel alloc]; 
 
    [self.array addObject:model]; 
 
     
 
    NSLog(@ "Size of % <a href=" http://www.jobbole.com/members/q697158886 "> @:</a> %zd" , NSStringFromClass([XOModel class]), malloc_size((__bridge const void *) model)); 
 
 }

Then paste the XOModel code:

 #import <Foundation/Foundation.h> 
 
  
 
 @interface XOModel : NSObject 
 
 { 
 
 int a1; 
 
 NSString *a2; 
 
 } 
 
  
 
 @ end  

Running on an iPhone 6 (or other 64-bit machine), the output is as follows:

 AllocTest[38470:2551068] Size   of XOModel: 32

"What? I have an int and a pointer and you give me 32 bytes. Operating system, are you crazy?"

Let's modify the XOModel code again, without instance variables:

 #import <Foundation/Foundation.h> 
 
  
 
 @interface XOModel : NSObject 
 
 { 
 
 } 
 
  
 
 @ end  

The output is as follows:

 AllocTest[38630:2562602] Size   of XOModel: 16

"Fuck, I don't have anything, and you still want to give me 16 bytes as an operating system. Are you stupid?"

Of course, there are reasons why a smart operating system does this. Here we need to know three things:

1. Any class object has an isa pointer, which requires memory to be allocated.
2. The pointer size is 4 bytes on 32-bit machines and 8 bytes on 64-bit machines.
3. Byte alignment.

I won’t talk about the first point. If you don’t know it, you probably don’t have the patience to read it till now.

The second point is to post a document picture. After iOS7, some Apple computers began to switch from 32-bit operating systems to 64-bit, so the sizes of some data types have also changed. Here we mainly focus on the pointers in the example:

Now, let's analyze the sample based on these two points.

• For the first example (an int in the class object, an NSString pointer, and an isa pointer), the output should be 4+8+8=20 on a 64-bit operating system, but the output is 32, which is wrong.
• In the second example (there is only one isa pointer in the class object), the value should be 8 on a 64-bit operating system, but the output is 16, which is still wrong. Why?

Byte alignment

I don't know much about byte alignment. To put it simply, the purpose is to improve access efficiency. I won't expand on the concept. You can read this. I will just talk about the principle here. First, I'll post a document from Apple:

When allocating any small blocks of memory, remember that the granularity for blocks allocated by the malloc library is 16 bytes. Thus, the smallest block of memory you can allocate is 16 bytes and any blocks larger than that are a multiple of 16. For example, if you call malloc and ask for 4 bytes, it returns a block whose size is 16 bytes; if you request 24 bytes, it returns a block whose size is 32 bytes. Because of this granularity, you should design your data structures carefully and try to make them multiples of 16 bytes whenever possible.

It's a bit long, but the simple meaning is:

When we allocate a block of memory, assuming the required memory is less than 16 bytes, the operating system will directly allocate 16 bytes; if the required memory is greater than 16 bytes, the operating system will allocate a*16 bytes. For example, if you call malloc and need 4 bytes, the system will give you a 16-byte block of memory; if you call malloc and need 24 bytes, the system will give you a 32-byte block of memory.

Now let’s look at our chestnuts and we can directly upload the picture:

In the first example, the misalignment should be 20 bytes, while the alignment should be 32 bytes.

The second example is not aligned to 8 bytes, so the alignment is 16 bytes:

ps: There may be different results on 32-bit machines because the pointer size is different, but 32-bit Apple machines are also 16-byte aligned.

This concludes our exploration of alloc.

Conclusion

This exploration was relatively thorough, and I learned a lot in the process. In this impetuous society, learning is about principles, and skills are secondary. Laying a solid foundation and keeping thinking will not erase your initial interest in it.

Reference link: (Since WeChat does not allow sending links, you can click on the original text to view it)

• iOS Memory Management and Optimization - Tencent Zhuang Yanjun
• Checking the size of an object in Objective-C – Stack Overflow
• Does class_getInstanceSize have a known bug about returning incorrect sizes? – Stack Overflow
• Memory Usage Performance Guidelines – Apple documentation
• Byte alignment - Baidu Encyclopedia

Done