Windows Memory Mechanism Analysis (2)

By leezy_2000

Iii. Introduction to heap

(Given that Matt pietrek has explained in detail the heap of 9x system in its "the mysteries of Windows 95 system programming", the content involved here will be limited to Win2000)

 

Heap is the opposite of stack. You need to manually manage the application and release of each piece of memory (without the garbage collection mechanism). For C/C ++ programmers, there are too many ways to operate on heap. The following is a list of almost all methods that can be used to operate the heap memory:

Malloc/free

New/delete

Globalalloc/globalfree

Localalloc/localfree

Heapalloc/heapfree

 

Among them, malloc/free is provided by the Runtime Library, and new/delete is a built-in operator of C ++. They all use the Runtime Library's own heap. The runtime database has its own heap under 2000 and Win9x. This means that as long as you start the process, you will have at least two heaps, one as the process default, and the other as the Runtime Library for C/C ++.

 

Globalalloc/globalfree and localalloc/localfree have lost their original meaning, and all memory is allocated from the default heap of the process.

 

Heapalloc/heapfree allocates memory from the specified heap.

 

For a single allocation of memory (New/delete requires both structure and analysis), all these methods will eventually come down to a point where 2000 and 98 are both heapalloc. Therefore, Microsoft will emphasize that globalalloc/globalfree and localalloc/localfree will be relatively slow, and heapalloc is recommended. However, because global ** and local ** have a simple user interface, therefore, even in the source code provided by Microsoft, they are still widely used. It must be noted that heapalloc does not have its own implementation in kernel32.dll, but forwards all calls to NTDLL. rtlallocateheap. The following screenshot from msdn (Figure 2) helps us understand APIs related to the same heap.

 

The operation in the heap is similar to that in the sgi stl splitter. In general, the OS maintains several linked lists for each heap and stores blocks of a specified size range on each linked list. When you allocate memory, the operating system first determines the allocation from the linked list based on the size you provided, and then finds the appropriate block from the linked list, and return the linear address to you. If the required size cannot be found in the existing block, allocate a large memory (using virtualalloc) and then cut it, then return the linear address of a block to you. This is just a general situation. The operating system constantly updates its own heap algorithms to speed up heap operations.

The heap information (including the flag and the linked list header) is stored in the heap header. The heap handle is the pointer to the heap header. The heap header structure is not disclosed, we will try to do some analysis later. It is very interesting that Microsoft has repeatedly stressed that the heapid that is only valid for the toolhelp API is actually a heap handle.

 

It was originally intended to analyze some of the internal structures of the heap, but later I thought that the practical value was not very great, but the necessary effort was not small. Therefore, no specific operation is performed. However, the idea of implementing various changed mini-programs in the monitoring heap is made public here, hoping to help you. This applet is very simple. The main task to complete is to enumerate the changes of all the heaps in the process. Because it involves comparing the differences between two linked lists, STL vector containers and some algorithms are used here to reduce encoding. At the same time, in order to make STL memory usage do not interfere with the objects we want to monitor, we need to create our own allocator to use the heap we created separately. In addition, note that the toolhelp API heap32next does not allow any heap disturbance during the running process (otherwise, it always returns true), so we can only use vector, and reserve enough space in advance. (Another way to access some information in the heap is to useHeapwalkAPI, depending on your preferences ).

 

The program runs in this way. First, enumerate the existing heap in the current process, and store the result into a set-type variable heapid1. Then, create your own heap for the distributor, enumerate the heap existing in the process and store the result to another set variable heapid2. In this way, you can call set_difference to find the ID of the new heap, the heap represented by this ID will be excluded when the team's internal information is listed later. Next, we can store the information in the heap to the corresponding vector between the two points. By comparing the two vectors, we can get the information corresponding to the memory allocation operation and the changes in the heap.

 

(Figure 2 from msdn by Murali R. Krishnan)

 

The following are some pending questions that interest you to explore.

 

What is the heap header structure?

 

How does heap internally organize memory blocks? (Is it a linked list)

 

Where is the description of each small block? (If it is a linked list, there should be pointers to connect these small pieces to each other .)