. Net memory usage-restaurant case study [reprinted]

Simon Singh, the author I like, is really an expert in analysis. In his book, his analysis of concepts is not only easy to understand, but also hard to forget. Because it will present a concept in your mind.

At work a few days ago, I heard that one of my colleagues was explaining to a customer why memory usage and memory exceptions occurred. Although I talked about memory overflow and memory management in an earlier article, I think his analysis is so interesting that I would like to share it with you.

Statement: To avoid being lengthy, I want to simplify many things. For example, in my opinion, the garbage collector allocates 64 MB block space. Although the size of the CIDR block allocated in different frameworks is different. It is also related to the space allocated to each object initially, for example, reading a large object heap. Some other details about memory allocation depend on configurations. I have excluded these details here.

Part 1-General memory usage

If you have read my previous post, you will know that the typical addressing space of 32-bit system processes is 2 GB of virtual address space. This is the memory space for work, and it is independent of the amount of Ram space occupied at the same time. Having more RAM is helpful for improving performance, but it does not help extend to address space 2 GB away.

At this time, you can think of the 2 GB address space as all the space occupied by a restaurant.

When you allocate a space for an object (whether it is A. Net object or not), you usually take the following two steps: first pre-define the space and then place the object in the pre-defined space.

Memory booking is like booking a dining table in a restaurant. Like a restaurant, memory reservation depends on its memory manager (Memory Manager), which will help you book a piece of continuous memory (memory in chunks ). For example, if you have a three-person dinner party, there may be no three dining tables in the restaurant, but you may reserve a four-person dining table, where you use three seats, waste a seat.

Compared with the memory space, you can reserve a table as if it was a reserved memory (in virtual bytes). The actual occupied seats (three seats) are like the actual occupied memory (in private bytes ). No pre-defined floor space is available memory.

On a wonderful evening, the restaurant may look like this:

The blue area indicates the reserved space, the red area indicates the actual space used, and the white area indicates the available space. As follows:

Now, if someone calls to book a three-person dining table, he will be told that the restaurant is no longer available. Because three people need a four-person dining table to sit together. Although you can sit down on two tables, it does not seem a good idea because you want to sit together.

Similarly, it is impossible for a memory reservation to divide the memory into small blocks and distribute them in different places. Otherwise, nothing is allocated, or allocated in a continuous area. Therefore, the memory reservation is also like the above three-person dining table scenario, it will "memory overflow", although there are enough small pieces of space available.

A careful audience may say that it is not possible to separate the tables into one, so that they can join one. Isn't this a four-person table? But Would customers who have already eaten want to move the table at this time? The reserved memory is as follows.

We talked about memory fragments and the remaining But unavailable memory blocks (because they are too small to accommodate a new table ), we also talk about how much memory has been reserved but not used (different from the memory occupied by virtual bytes and private bytes ).
 
Part 2-. Net garbage collection

In most cases, you rely on some Memory Manager (such as NT heap, C ++ heap, and GC) to create objects in the application. In the restaurant case scenario, you will compare the memory manager to a waitress who will reserve a seat for you and will take you to your seat. For example, if you call the malloc method, you do not need to provide the address you want to allocate. Instead, you only need to inform you of the size of the memory block required. malloc will return the address specified in the memory. OK. Table 1 in the "C ++ Heap" area is the address assigned to you.

. Net's garbage collection mechanism (GC) should go further. In a process, if you want to use a. Net object, it will reserve a large "table" (64-seat table) in advance ). When someone creates a. Net object, GC will receive them to the next available seat on the table. Sometimes the receptionist will move back and forth at the table to check if someone has finished the meal and invites them to leave. Other guests will sit at the table. Some may have to wait for others to finish their meals before they can leave (for example, reference objects), so they have to wait. There are also some "ye" people, occupying a window seat, very angry to say, "I am not leaving ". This means that he cannot leave a place, and others cannot.

The vacant space between the guest and the guest is like. Net memory fragments.

Once the 64-seat table is full, GC needs to reserve a new 64-seat table to receive new guests. If the reservation fails, a memory overflow exception is thrown.

But what is its true face?

OK, there is enough analysis, and you will see the real Asp.net application memory.

Again, the red part is used memory, the blue part is pre-configured but not used memory, and the white part is available memory.

At the end of the memory space, some of the smaller points you see may be some DLL. Although there is still a lot of white space in a restaurant, it is likely that the gap between the two red dots is not enough to accommodate a 64 m block. In this way, A memory overflow exception occurs when the next GC request for a new memory.

These little red dots (DLL) are filled with space as a result of these special DLL loads on a more suitable base address. You can't do more for that type of DLL, because it is difficult to predict where the "good" address they will allocate is, but what you do for this, find out where the actually used memory goes.