Re: [boost] [pool] future directions

From: Atry (pop.atry_at_[hidden])
Date: 2007-05-08 04:22:57

Moving live objects is very dangerous, and I think it would cause a
lot of problem on threads' synchronization.

2007/5/8, Michael Gopshtein <mgopshtein_at_[hidden]>:
> According to documentation to "Pool" library, it is intended to be used
> "when there is a lot of allocation and deallocation of small objects".
>
>
>
> In our product we also use such pool for allocation of "normal" - heavier
> objects. In such case we can't benefit from significant improvement in
> memory consumption per object (overhead of malloc's internal structure
> relative to used size of the object), but the allocations themselves are
> much more efficient.
>
> Additional advantage is memory fragmentation - all objects in the pool
> reside in continuous memory blocks.
>
>
>
> The main problem with such usage is, in our case, that the pool never
> "returns" memory to the system, unless it's released. For example, if I use
> the pool for allocation of Event objects, and at some point of time I had
> 10000 concurrent events, the pool will occupy all that memory while the
> process is alive, even if for most of the time I use a small portion of it.
>
>
>
> As a solution I was thinking about adding a "defragment" function to memory
> pool, which will compact it by moving live objects to free cells at the
> "beginning" of the pool. Such feature can be implemented with help of
> additional "index" table of pointers. Of cause, instead of returning pointer
> to allocated object, the pool will return a wrapper object, actually
> pointing to that index table (for which separate "classical" pool can be
> used).
>
>
>
> So, the first question is: do you think such feature will be helpful?
>
>
>
> If yes - please share your thoughts regarding suggested and/or other
> implementations?
>
>
>
>
>
> Michael
>
>
>
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>