Re: [Boost-users] does pool::release_memory() really require an ordered

Subject: Re: [Boost-users] does pool::release_memory() really require an ordered
From: Lang Stefan (SLang_at_[hidden])
Date: 2010-09-02 11:57:53

-----Ursprüngliche Nachricht-----

Message: 5
Date: Wed, 1 Sep 2010 17:32:46 -0400
From: Mark Rajcok <mrajcok_at_[hidden]>
To: boost-users_at_[hidden]
Subject: [Boost-users] does pool::release_memory() really require an
        ordered	pool?
Message-ID:
        <AANLkTim0t9KTDJowTbn2viBu+RSTqnwfKA1c7qRbv_X2_at_[hidden]>
Content-Type: text/plain; charset=ISO-8859-1

On page http://www.boost.org/doc/libs/1_44_0/libs/pool/doc/interfaces/pool.html
there is this precondition for release_memory():  "t must be ordered".

Does that mean that ordered_malloc() must always be used, if I want to
use release_memory()?

Looking at the implementation for release_memory(), it appears to be
iterating through chunks in each block, which I wouldn't expect if
ordered_malloc() were always used.

What I'm really after:  I want to use object_pool, but periodically
I'd like to reclaim/release any memory blocks that are no longer in
use.  In my application, I may have traffic spikes, where I allocate a
lot of memory, but then later (after spiking) I'd like to release it.
(The object pools will persist for the life of the application, and
there will probably always be some "active objects" -- i.e., allocated
from the pool and not free()d yet.)

(I'm hoping the documentation may be out of date, and release_memory()
can be used on pools that don't use ordered_malloc() and on
object_pools.)

-- Mark

------------------------------

Mark,

I cannot check the repository right now, but last time I did there were no changes to the version of boost::pool since I last tried to work with it, about three years ago. 

Back then I found that memory wasn't released at all due to a relevant part of the code being commented out. But even uncommenting it didn't help all that much: just like you, I found that the effort of releasing a single object was, essentially, proportional to the size of the pool, at best at an order of O(log(N)), maybe even worse. So just using standard new and delete operators would at some point outperform this pool implementation! 

I've done my own implementation in the meantime, with all operations at constant time, and using shared pointers to objects from the pool, which would make sure unused memory blocks can be released ASAP. Never got around to actually use it though, so I cannot say for sure if it has errors still. The tests and benchmarks I ran did look rather good, but I found that using malloc/free instead of new/delete got me about the same performance boost, which is why I ultimately discarded it. (malloc and free were already being used anyway, not that I was happy with it. But unfortunately I ran out of arguments to replace them...) 

Cheers,
Stefan