Re: Allocator tuning parameters

[Dhruv Matani <dhruvbird at gmx dot net>]

On Sat, 2004-01-24 at 01:48, Loren James Rittle wrote:
[...]

> There is also the issue that the default pool allocator has some cases
> where its performance profile truly stinks (for single-threaded, we
> think it beats most per-platform malloc implementations; however I
> have test cases where that is not always true).  Since we never
> figured out the best way to set the default allocator on a
> per-platform basis, the compromise was to always allow one to disable
> the pool cache.

I have a suggestion that may not be always feasable, because it involves
the client to instantiate an allocator explicitly.

Firstly, to make this work, we need to make each allocator truly type
parameterized, meaning that some_allocator<int> and
some_allocator<float> will not be sharing pools. As I have mentioned
earlier, this would improve the efficiency too.

Then, make each allocator a reference counted entity. When a new istance
is created, the reference count goes up by 1, and when destroyed, it
goes down by 1. When the reff. count becomes 0, we deallocate the memory
associated with the internal pool. So, effectively, 2 different
instances of some_allocator<int> CAN share their memory.

Now, if a client wishes that he/she does not want to deallocate the
memory associated with an allocator at program exit, he/she can just
instantiate an allocator on the heap. Thus guaranteeing that that memory
will never be released.


Example:

allocator<int> *pialloc = new allocator<int>;
//User does not wish to deallocate the memory associated with list<int>,
but wants to release the memory assiciated with list<float> so that it
can be reused by list<double>!

{
   list<int, allocator<int> > il;
   list<float, allocator<float> > fl;
   //Manipulate the list, and at the end of the scope, both will get
destroyed. However, the instance count for allocator<int> is still 1, so
the associated memory does not get destroyed.
}

list<double, allocator<double> > dl;
//The memory that allocator<double> acquires from operator new/malloc
may be the same as that given back by allocator<float>. If the user is
sure that he/she will never be using list<float> again, it does not make
sense for the allocator<float> to keep the free list in memory. However,
if the user knows that he/she will be using list<int> again, he/she just
instantiated that allocator and prevents the memory from being released.

Would this be feasible?




-- 
	-Dhruv Matani.
http://www.geocities.com/dhruvbird/