C ++ memory management revolution (4): boost: object_pool and GC Allocator

This article has been migrated to: http://cpp.winxgui.com/cn:gc-allocator-and-boost-object-pool

C ++ memory management revolution (4): boost: object_pool

Xu Shiwei (copyright statement)
2007-4-21

This article has been dragging on for a long time. Neutraledevil urged me to continue writing three months ago. For the sake of winxgui integrity, I have been trying to give priority to other articles, rather than making people misunderstand that winxgui is a memory management library. :)

Let's get down to the truth. We have introduced the boost: pool component in the memory pool technical details. From the perspective of the change in the concept of memory management, this is a traditional mempool component, although there are some improvements (but only performance improvements ). But boost: Unlike object_pool, It is very consistent with the concept I emphasized in the C ++ memory management revolution. It can be considered that boost: object_pool is an uncommon GC Allocator component.

I have already proposedGC Allocator. It should be emphasized here,GC Allocator refers to Allocator with garbage collection capability.. C ++ memory management revolution (1) we introduced this concept, but the word GC allocator is not clear.

Boost: object_pool Memory Management Concept

Boost: the remarkable thing about object_pool is that this is the first time C ++ admitted from the library level that programmers make mistakes in memory management, it is difficult for programmers to ensure that the memory is not leaked. Boost: object_pool allows you to forget to release the memory. Let's look at an example:

Class X {... };
 
Void func ()
{
Boost: object_pool <x> alloc;
 
X * obj1 = alloc. Construct ();
X * obj2 = alloc. Construct ();
Alloc. Destroy (obj2 );
}

If boost: object_pool is just a common Allocator, this code is obviously faulty because the destructor of obj1 is not executed and the applied memory is not released.

However, this code is completely normal. Yes, the structure of obj1 is indeed executed, and the applied memory is also released. That is to say,Boost: object_pool supports both manual memory release (by calling object_pool: Destroy) and automatic memory recovery (through object_pool ::~ Object_pool destructor execution ). This is in line with GC Allocator specifications.

Note: Object Management is better for memory management. Memory application and release are more specifically the creation and destruction of objects. However, we do not deliberately distinguish between the two.

Boost: object_pool and autofreealloc

We know that autofreealloc does not support manual release. Instead, we can only wait until the autofreealloc object is parsed to release all the memory at a time. Can I think that boost: object_pool is more complete than autofreealloc?

Actually not. Boost: Neither object_pool nor autofreealloc are full GC allocator. Autofreealloc is only applicable to specific use cases because it can only be released at one time. However, although autofreealloc is not universal, it is a general GC allocator. Boost: object_pool can only manage one type of objects. It is not a general-purpose Allocator, but has more limitations.

Boost: Implementation Details of object_pool

Everyone should have a general grasp of Boost: object_pool. Now let's go deep into the Implementation Details of object_pool.

In the memory pool technical explanation, we will introduceBoost: PoolWhen using components, I would like to remind you to pay attention to them.Pool: ordered_malloc/ordered_freeFunction. In fact,Boost: object_poolOfMalloc/construct, free/destroyFunction calledPool: ordered_malloc, ordered_freeFunction insteadPool: malloc, freeFunction.

Let's explain why.

In fact, the key lies in the support of object_pool.Manual memory release and automatic memory recovery (and automatic execution of destructor)Two modes. If there is no automatic structure analysis, the general mempool is enough, and ordered_free is not required. Since Automatic Recovery and manual release existMemory block (memblock)Which node isFree memory node (freenode)And which nodes are used. Obviously, the object's destructor cannot be called for nodes that are already in free memory.

Let's take a look at object_pool ::~ Object_pool function implementation:

Template <typename T, typename userallocator>
Object_pool <t, userallocator> ::~ Object_pool ()
{
// Handle trivial case
If (! This-> list. Valid ())
Return;
 
Details: podptr <size_type> iter = This-> list;
Details: podptr <size_type> next = ITER;
 
// Start 'freed _ ITER 'at beginning of Free List
Void * freed_iter = This-> first;
 
Const size_type partition_size = This-> alloc_size ();
 
Do
{
// Increment next
Next = Next. Next ();

// Delete all contained objects that aren't freed

// Iterate 'I' through all chunks in the memory block
For (char * I = ITER. Begin (); I! = ITER. End (); I + = partition_size)
{
// If this chunk is free
If (I = freed_iter)
{
// Increment freed_iter to point to next in Free List
Freed_iter = nextof (freed_iter );
 
// Continue searching chunks in the memory block
Continue;
}

// This chunk is not free (allocated), so call its destructor
Static_cast <t *> (static_cast <void *> (I)-> ~ T ();
// And continue searching chunks in the memory block
}

// Free storage
Userallocator: Free (ITER. Begin ());

// Increment ITER
Iter = next;
} While (ITER. Valid ());

// Make the block list empty so that the inherited destructor doesn't try
// Free it again.
This-> list. invalidate ();
}

This code is not hard to understand. object_pool traverses all applicationsMemory block (memblock)And traverse all of themNode)If the node does not appearFreenodelist)The node is not released by the user, and the corresponding destructor is required.

Now you understand,Ordered_mallocTo make memblock in memblocklist orderly,Ordered_freeIt is to order all freenode in freenodelist. Memblocklist and freenodelist are ordered to quickly detect whether the node is free or used (this is actually a collection request process. We recommend you look at STD: set_intersection, it is defined in <algorithm> of STL ).

C ++ memory management revolution-series of articles

• C ++ memory management revolution
• C ++ memory management revolution (2): The most pocket Garbage Collector
• C ++ memory management revolution (3): alternative Memory Management
• Discussion on garbage collection (GC) in C ++)

Click here to view more articles on memory management.