Boost Pool and Object_pool

Memory pool is a way of allocating memory. Often we are used to apply for allocating memory directly using APIs such as new, malloc, and the disadvantage is that due to the variable size of the requested memory block, when used frequently, it causes a lot of memory fragmentation and thus degrades performance. A memory pool is a request to allocate a certain number of memory blocks of equal size (in general) to be reserved before actually using memory. When there is a new memory requirement, a portion of the memory block is separated from the memory pool, and if the memory block is not enough, then continue to request new memory. One notable advantage of this is that memory fragmentation is avoided as much as possible, resulting in improved memory allocation efficiency.

Memory Pool Classification:

1, the memory pool of indefinite length. Typical implementations are Apr_pool and Obstack. The advantage is that there is no need to create different pools of memory for different data types, and the disadvantage is that the allocated memory cannot be returned to the pool. This is due to the fact that the session is granular and based on the hierarchical nature of the business process.

2, fixed long memory pool. The typical implementation has Loki, BOOST. The feature is to create a separate memory pool for different types of data structures, and to request memory from the corresponding memory pool when memory is needed, the advantage is that the memory can be returned to the pool immediately after use, and more granular control blocks of memory can be made.
This type of memory pool is more common than it is to grow, and on the other hand, it can waste a lot of memory in a large number of different data type environments. But the general system of the main data structures are not many, and are repeated application release use, in this case, fixed-length memory pool of this small disadvantage can be ignored.

Pool allocation is a method of allocating memory that is used to quickly allocate memory blocks of the same size.
This is especially true if you repeatedly allocate/release memory blocks of the same size.

There are two main benefits of using pool memory pools:

1. The ability to effectively manage the allocation and release of many small objects avoids the memory fragmentation and inefficiencies that arise from managing memory on their own .

2. Say goodbye to the memory leak of the program, the pool library will automatically manage the internal memory, avoid the programmer accidentally caused by the memory leak problem.

Document: Http://www.boost.org/doc/libs/1_59_0/libs/pool/doc/html/index.html

  Template<typename Userallocatorclass pool;   

Basic fixed-length memory pool

#include <boost/pool/pool.hpp>

typedef struct STUDENT_ST

{

Char name[10];

int age;

}cstudent;

int main ()

{

Boost::p ool<> student_pool (sizeof (cstudent));

Cstudent * Const obj= (cstudent *) Student_pool.malloc ();

Student_pool.free (obj);

return 0;

}

The template parameter for pool has only one sub-type, and boost provides two types of Default_user_allocator_new_delete/default_user_allocator_malloc_free, Specifies whether to use New/delete or malloc/free when applying for memory release, default_user_allocator_new_delete by default. The constructor has 2 parameters: Nrequested_size,nnext_size. Nrequested_size is the size of the block (because void* saves the serial number, so the boost has a minimum of block, nrequested_size is too small to take the built-in value), Nnext_size is Simple_segregated_ When memory is low in storage, the number of blocks requested is 32 by default. The most comprehensive instantiation pool is similar to this: boost::p ool<boost::d efault_user_allocator_malloc_free> student_pool (sizeof (cstudent), 255) ;

The functions provided by the pool are mainly:

Malloc/free based on Add_block/malloc/free, efficient

Ordered_malloc/ordered_free is based on the Add_ordered_block/malloc/ordered_free implementation, do not have any meaning in the pool, do not use.

Release_memory/purge_memory the former frees up unused memory in the pool, which frees all memory in the pool. Another pool destructor also frees memory

2) Object_pool

Object memory pool, which is one of the most failed memory pool designs.

#include <boost/pool/object_pool.hpp>

Class a{

Public

A ():d ata_ (0) {}

Private

int Data_;

};

int main ()

{

Boost::object_pool<a> Obj_pool;

A *const pa=obj_pool.construct ();

Obj_pool.destroy (PA);

return 0;

}

Object_pool inherit to pool, there are two template parameters, the first one is the object type, the second is the allocation subtype, the default is Default_user_allocator_new_delete. Constructor parameters are only nnext_size, meaning and default values are the same as pool. The most comprehensive instantiation of Object_pool is similar to this: boost::p ool<a,boost::d efault_user_allocator_malloc_free> obj_pool (255);

The functions provided by Object_pool are mainly (inherited to the parent class): The Malloc/free,add_ordered_block/malloc/ordered_free implementation of the Malloc/free replication pool

Construct/destroy based on the malloc/free implementation of this class, additional calls to the default constructor and default destructor.

~object_pool alone to come up with this, if the destruction of the object is not destroy, can be detected, release memory before it executes destroy

     Why is boost::object_pool designed to do this? The ability to invoke constructors and destructors is obviously not the starting point for the Boost::object_pool class design, because constructors can only execute default constructors (first publish error: Arbitrary constructors can be called, see Code files: Boost/pool/detail/pool_ Construct.inc and Boost/pool/detail/pool_construct_simple.inc, thanks to exile), almost none, it's focused on the memory release time of the cleanup work, this work default destructor is sufficient. The memory cleanup function can be registered in the Apr_pool memory pool, and operations such as closing the file descriptor, closing the socket, and so on, are executed at the moment of memory release. Boost::object_pool also wanted to achieve the same function, so designed the function of destroy, and in order to prevent users from missing the call, but also in the memory pool when the destruction of the detection and recovery. For this purpose without the time complexity of the Object_pool is O (n squared), Boost::object_pool pay a heavy price, in each of the destoy to perform sorting function, time complexity O (n), the last time complexity of the destruction is O (n), Also for this purpose, increased add_ordered_block/ordered_free,pool from simple_segregated_storage increased the Ordered_malloc/ordered_ Free, and other redundant functions.

Based on the reasons discussed above, Boost::object_pool is designed to look the way it is, and it becomes a chicken class. The designer of the class seems to have forgotten the purpose of the memory pool, forgetting that memory requests in the memory pool have been released in a very high frequency, much larger than the destruction of the memory pool object. If you still want to use similar to this memory cleanup function, can be modified on the Boost::object_pool, no longer write malloc/free, rewrite the object_pool of the destruction, simply free memory, so the destruction object_ Do not forget to call destroy before the pool, which is also the rule by default with placement new, or maintain the previous destructor, sacrificing performance at the time of destruction. The role of placement new is to call the constructor for the memory that has been applied, using a process of (1) Requesting Memory BUF (2) Call placement New:new (BUF) Construtor () (3) Call destructor destructor () (4) Release the memory buf. #include <new> can use placement new.

3) Singleton_pool

The lock version of the pool.

#include <boost/pool/singleton_pool.hpp>

typedef struct STUDENT_ST

{

Char name[10];

int age;

}cstudent;

typedef struct SINGLETON_POOL_TAG{}SINGLETON_POOL_TAG;

int main ()

{

typedef boost::singleton_pool<singleton_pool_tag,sizeof (Cstudent) > global;

Cstudent * Const df= (cstudent *) Global::malloc ();

Global::free (DF);

return 0;

}

Singleton_pool is a singleton class, which is a lock package for the pool, and is suitable for multithreaded environments where all functions are static types. It has 5 template parameters, Tag: tag, meaningless; Requestedsize:block length; Userallocator: Sub-allocation, default or Default_user_allocator_new_delete ; Mutex: Lock mechanism, the default value ultimately depends on the system environment, Linux is Pthread_mutex, it is the encapsulation of pthread_mutex_t; Nextsize: When memory is low, the number of blocks requested is 32 by default. The most comprehensive use of singleton_pool is similar to this: TypeDef boost::singleton_pool<singleton_pool_tag,sizeof (cstudent), Default_user_ Allocator_new_delete,details::p ool::d efault_mutex,200> Global;

It exposes the same function as the pool.

4) Pool_allocator/fast_pool_allocator

The replacement scheme for Stl::allocator. Both are based on the Singleton_pool implementation, the implementation of the stl::allocator requirements of the interface specification. The use of the two is the same, the difference is that Pool_allocator's internal implementation calls the Ordered_malloc and Ordered_free, which satisfies the allocation request for a large number of contiguous blocks of memory. Fast_pool_allocator's internal implementation calls malloc and free, which is more appropriate for a single large block of memory at a time, but also for general purpose allocations, but with some performance drawbacks. It is therefore recommended to use the latter.

#include <boost/pool/pool_alloc.hpp>

#include <vector>

typedef struct STUDENT_ST

{

Char name[10];

int age;

}cstudent;

int main ()

{

Std::vector<cstudent *,boost::fast_pool_allocator<cstudent *> > V (8);

Cstudent *pobj=new cstudent ();

V[1]=pobj;

Boost::singleton_pool<boost::fast_pool_allocator_tag,sizeof (Cstudent *);::p urge_memory ();

return 0;

}

There are four template parameters for the Fast_pool_allocator: type, sub-allocation, lock type, the number of blocks requested when the memory is low, and the following three have default values, no longer said. It uses the Singleton_pool tag to be boost::fast_pool_allocator_tag.

Summary: Boost::p ool Small and efficient, use more, multi-threaded environment use Boost::singleton_pool, do not use the Ordered_malloc/ordered_free function of both. Boost::object_pool is not recommended, it can be modified after use. Pool_allocator/fast_pool_allocator recommends using the latter.

Boost Pool and Object_pool