Re: Challenge: pool allocator

From: mtsirkin_at_[hidden]
Date: 2000-07-06 00:57:39

--- In boost_at_[hidden], Boris Fomitchev <fbp_at_s...> wrote:
> Dave Abrahams wrote:
> 
> > Hi everyone,
> >
> > I spent a considerable amount of effort recently trying to come 
up with a
> > pool allocator for boost, but failed. Here's what I'm trying to 
accomplish:
> >
> > A general system for dynamically allocating and constructing 
instances of a
> > (possibly non-POD) type. Any outstanding instances in a pool are 
destroyed
> > and deallocated when the pool is destroyed.
> >
> > I'm thinking of usage something like this:
> >
> > class Foo { ... };
> > boost::pool<Foo> foo_pool;
> > Foo *foo1 = foo_pool.create(<args>);
> > [One could also use placement new above, but it seems harder to 
control: you
> > have to force the correct placement delete to be defined, and 
some compilers
> > don't support that correctly anyway]
> >
> 
> Well, how do you suppose to handle variable arguments here ? I 
believe placement
> new
> is the only right solution. It also allows for important 
generalization - then
> the pool
> allocation manage only allocation itself, not initialization. More 
good news :
> SGI STL/STLport
> already use that generalized pool allocator ;). And, you may just 
use
> allocator<T> w/o
> redefined placement new or delete.
> 

IIRC this is not exactly what is asked for here:
in STLport there is one static pool .
Therefore the pool can be never destroyed.

> 
> 
> >
> > This is harder than it looks - remember that if an exception is 
thrown
> > during construction the the memory for the instance should be 
returned to
> > the pool *and more importantly* the instance should not be 
double-destroyed
> > when the pool is destroyed.
> >
> 
> Yep, and it's trivial for pool allocator<>, as those issues are 
> decoupled then.
> 
> 
> 
> >
> > Some of the hard issues are:
> > 1. Memory alignment of instances in the pool
> > 2. You can't make unions of non-POD types, so it's hard to thread 
a
> > free-list through memory for instances in the pool
> >
> > Any suggestions?
> > Anyone already have a good solution?
> >
> > -Dave

Another issue worth considering IMHO is the locality principle:
when you have a container (e.g. vector) and inside it
a pointer to allocated memory, you might want to try to
put the allocated chunk as close as possible to the original 
object itself, to reduce the amount of memory pages used.

We use a commercial memory management library that provides such 
allocator, but I know of no public domain implemntation that can do 
this.
Or testing shows that when memory usage is high, results can be 
imressive, performance-wise.

-MSt