RE: [boost] Bug in pool not resetting next_size on purge_memory()

From: scleary_at_[hidden]
Date: 2002-10-18 09:08:49

> -----Original Message-----
> From: Brad Spencer [mailto:spencer_at_[hidden]]
> 
> I have an application that allocates memory using a pool and then
> often frees the entire pool using purge_memory(), but then reuses the
> same pool again to allocate more.  The algorithm looks as follows:
> 
>   1. Allocate a bunch of memory from pool
>   2. Call purge_memory()
>   3. Goto 1
> 
> After a brief period of time, the pool is calling the UserAllocator
> with a request of just over 1 GB (0x4000000C).  The pool's requested
> size is 32 K. It would appear that neither purge_memory() nor
> release_memory() reset the next_size back to its original setting.

Yes, this is a bug for purge_memory() and release_memory().  I'll update it
when I have time (probably not for a few weeks).  It will essentially do the
same thing as your work-around.

> Also, perhaps next_size should grow by a factor of 1.5 instead 2, as
> is suggested by Andrei Alexandrescu in "Modern C++ Design" (I don't have
> the page handy :)

When I wrote Boost.Pool, I considered two different growths for next_size:
  next_size = next_size * 2;
and
  next_size = next_size * 2 + 1;

There's a disadvantage to the "*2+1" scheme: the "array doubling" scheme has
a historical precedent, which makes it more likely that general-purpose
allocation schemes are tuned to supply allocations of powers-of-2.  Before
making this decision, I reviewed a few Standard library implementations (all
the ones I had access to at the time), and found that std::vector used array
doubling in every one.

I have not heard of this growth by 1.5 idea, and I just took a brief look
through Andrei's book and couldn't find it.  Could you look up the
reference, or maybe just describe the advantages of that approach?

        -Steve