27 Aug
2008
27 Aug
'08
8:49 a.m.
Hi Paul, On Wed, Aug 27, 2008 at 2:44 AM, Paul Bormans <pbor1234@hotmail.com> 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: [snip] > > >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? HTH -- Dean Michael C. Berris Software Engineer, Friendster, Inc.