From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2008-08-27 04:49:51
On Wed, Aug 27, 2008 at 2:44 AM, Paul Bormans <pbor1234_at_[hidden]> wrote:
> Some time ago i had noticed some strange behavior in the boost pool_allocator regarding its memory usage. Now that i've found these great mailinglists ;) i've reproduced the error and with some additional analysis i can post the thing here.
I have the same experience, although with Linux and GCC 4.1.2. More precisely:
> >From these tests;
> - why does the boost::pool_allocator reserve 16312 bytes for 1000 int's while the default stl vector consumes (only) 4264 bytes?
I think it has something to do with the way the pool_allocator grows,
which is by doubling the available pool source every time it "runs out
of available free contiguous space".
> - why does a call to release_memory( ) not remove all the memory allocations done by the pool_allocator? But only the last block?
I think this is the major bug that gets exacerbated in "high data
churn applications" -- where lots of small containers acquire/release
memory often, and the pool_allocator just doesn't know about the
blocks that are supposedly "free" and "available" again.
> - why does the size of each new block gets duplicated in size (even after release_memory)?
This I think is the intended behavior (which I think you mean is that
the size of the whole memory block gets doubled every time).
> Does this make sense to any of you?
No, but it would be nice to know if indeed this is a bug and whether
there should be additional tests to expose the bug.
One thing I notice is that there's an interface to
pool_allocator<...>::purge_memory() -- or something similar. Is this
by any means part of the standard allocator interface and shouldn't
this be called whenever a release is called as well?
-- Dean Michael C. Berris Software Engineer, Friendster, Inc.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk