BDE 4.14.0 Production release
|
Functions | |
void * | operator new (bsl::size_t size, BloombergLP::bdlma::Pool &pool) |
void | operator delete (void *address, BloombergLP::bdlma::Pool &pool) |
Provide efficient allocation of memory blocks of uniform size.
This component implements a memory pool, bdlma::Pool
, that allocates and manages maximally-aligned memory blocks of some uniform size specified at construction. A bdlma::Pool
object maintains an internal linked list of free memory blocks, and dispenses one block for each allocate
method invocation. When a memory block is deallocated, it is returned to the free list for potential reuse.
Whenever the linked list of free memory blocks is depleted, the bdlma::Pool
replenishes the list by first allocating a large, contiguous "chunk" of memory, then splitting the chunk into multiple memory blocks. A chunk and its constituent memory blocks can be depicted visually:
Note that the size of the allocated chunk is determined by both the growth strategy and maximum blocks per chunk, either of which can be optionally specified at construction (see the "Configuration at Construction" section).
When creating a bdlma::Pool
, clients must specify the specific block size managed and dispensed by the pool. Furthermore, clients can optionally configure:
For example, if geometric growth is used and the maximum blocks per chunk is specified as 30, the chunk size grows geometrically, starting from 1, until the specified maximum blocks per chunk, as follows:
If constant growth is used, the chunk size is always the specified maximum blocks per chunk (or an implementation-defined value if the maximum blocks per chunk is not specified), for example:
A default-constructed pool has an initial chunk size of 1 (i.e., the number of memory blocks of a given size allocated at once to replenish a pool's memory), and the pool's chunk size grows geometrically until it reaches an implementation-defined maximum, at which it is capped. Finally, unless otherwise specified, all memory comes from the allocator that was the currently installed default allocator at the time the bdlma::Pool
was created.
This component overloads the global operator new
to allow convenient syntax for the construction of objects using a bdlma::Pool
. The new
operator supplied in this component takes a bdlma::Pool
argument indicating the source of the memory. Consider the following use of standard placement new
syntax (supplied by bsl_new.h
) along with a bdlma::Pool
to allocate an object of type T
. Note that the size of T
must be the same or smaller than the blockSize
with which the pool is constructed:
This usage style is not exception-safe. If the constructor of T
throws an exception, pool->deallocate
is never called.
Supplying an overloaded global operator new
:
allows for the following cleaner usage, which does not require the size calculation and guarantees that pool->deallocate
is called in the case of an exception:
Also note that the analogous version of operator delete
should not be called directly. Instead, this component provides a static template member function deleteObject
, parameterized on TYPE
:
The above deleteObject
call is equivalent to performing the following:
An overloaded operator delete
is supplied solely to allow the compiler to arrange for it to be called in case of an exception.
This section illustrates intended use of this component.
A bdlma::Pool
can be used by node-based containers (such as lists, trees, and hash tables that hold multiple elements of uniform size) for efficient memory allocation of new elements. The following container template class, my_PooledArray
, stores values of (template parameter) TYPE
"out-of-place" as nodes in a vector
of pointers. Since the size of each node is fixed and known a priori, the class uses a bdlma::Pool
to allocate memory for the nodes to improve memory allocation efficiency. Note that for simplicity, we assume that TYPE
does not require an allocator, and that calls to the destructor of TYPE
can be elided.
First, we define the interface of our my_PooledArray
template class:
Next, we provide the implementation of the my_PooledArray
methods that are defined inline
.
Note that in the removeAll
method, all elements are deallocated by simply invoking the pool's release
method. This technique implies significant performance gain when the array contains many elements:
Next, we provide the implementation of the my_PooledArray
methods that are defined in the .cpp
file.
Note that the growth strategy and maximum chunk size of the pool defaults to those provided by bdlma::Pool
:
Since all memory is managed by d_pool
, we do not have to explicitly invoke deleteObject
to reclaim outstanding memory. The destructor of the pool will automatically deallocate all array elements:
Finally, note that the overloaded "placement" new
is used to allocate new nodes in the append
method:
|
inline |
Use the specified pool
to deallocate the memory at the specified address
. The behavior is undefined unless address
is non-zero, was allocated using pool
, and has not already been deallocated. Note that this operator is supplied solely to allow the compiler to arrange for it to be called in the case of an exception.
|
inline |
Return a block of memory of the specified size
(in bytes) allocated from the specified pool
. The behavior is undefined unless size
is the same or smaller than the blockSize
with which pool
was constructed. Note that an object may allocate additional memory internally, requiring the allocator to be passed in as a constructor argument:
Also note that the analogous version of operator delete
should not be called directly. Instead, this component provides a static template member function, deleteObject
, parameterized by TYPE
:
deleteObject
performs the following: