custom allocators, pool_alloc release_memory() seems to be broken
I tried contacting Stephen the pool_allocator author, but his e-mail is invalid (shouldn't the docs be updated?) Here is what I wrote in case someone else here can offer some help: I'm trying unsuccessfully to use your Boost::pool_alloc. In the documentation at the boost website: http://www.boost.org/doc/libs/1_42_0/libs/pool/doc/interfaces.html it says: // Exiting the function does NOT free the system memory allocated by the pool allocator // You must call // boost::singleton_pool<boost::pool_allocator_tag, sizeof(int)>::release_memory() // in order to force that release_memory() does not seem to work. Not sure why. I called a function in my code to verify my processes memory usage, and see that indeed memory was not being released. I also google searched and found that others experienced the same: http://groups.google.ms/group/boost-list/browse_thread/thread/7d350f4c30d76d... http://article.gmane.org/gmane.comp.lib.boost.devel/179196 http://lists.boost.org/Archives/boost/2008/08/141468.php http://archives.free.net.ph/message/20080827.184624.21654313.en.html Your help on this is requested. Thanks.
AMDG B Hart wrote:
I tried contacting Stephen the pool_allocator author, but his e-mail is invalid (shouldn't the docs be updated?)
Here is what I wrote in case someone else here can offer some help:
I'm trying unsuccessfully to use your Boost::pool_alloc. In the documentation at the boost website: http://www.boost.org/doc/libs/1_42_0/libs/pool/doc/interfaces.html it says:
// Exiting the function does NOT free the system memory allocated by the pool allocator // You must call // boost::singleton_pool<boost::pool_allocator_tag, sizeof(int)>::release_memory() // in order to force that
release_memory() does not seem to work. Not sure why. I called a function in my code to verify my processes memory usage, and see that indeed memory was not being released. I also google searched and found that others experienced the same:
The problem is not release_memory per se. The problem is the interaction between singleton_pool, pool_allocator and std::set. The example is using vector, which (probably) allocates exactly the type that you give it. std::set is allocating a different type. pool_allocator uses multiple singleton_pools, one for each size of object. release_memory would work if you could find the size of the object that std::set is actually allocating. Without knowing that, the best you can do is something like // assume that the sizes are multiples of 4 bytes. boost::singleton_pool<boost::pool_allocator_tag, 4>::release_memory(); boost::singleton_pool<boost::pool_allocator_tag, 8>::release_memory(); boost::singleton_pool<boost::pool_allocator_tag, 12>::release_memory(); boost::singleton_pool<boost::pool_allocator_tag, 16>::release_memory(); boost::singleton_pool<boost::pool_allocator_tag, 20>::release_memory(); boost::singleton_pool<boost::pool_allocator_tag, 24>::release_memory(); boost::singleton_pool<boost::pool_allocator_tag, 28>::release_memory(); boost::singleton_pool<boost::pool_allocator_tag, 32>::release_memory(); // hope that's enough... In Christ, Steven Watanabe
nope, continued upwards and release_memory() always returns false. Also, I would say that release_memory is broken, or needing revision, if one has to guess what the pool size is. On Thu, Mar 18, 2010 at 7:14 AM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
B Hart wrote:
I tried contacting Stephen the pool_allocator author, but his e-mail is invalid (shouldn't the docs be updated?)
Here is what I wrote in case someone else here can offer some help:
I'm trying unsuccessfully to use your Boost::pool_alloc. In the documentation at the boost website: http://www.boost.org/doc/libs/1_42_0/libs/pool/doc/interfaces.html it says:
// Exiting the function does NOT free the system memory allocated by the pool allocator // You must call // boost::singleton_pool<boost::pool_allocator_tag, sizeof(int)>::release_memory() // in order to force that
release_memory() does not seem to work. Not sure why. I called a function in my code to verify my processes memory usage, and see that indeed memory was not being released. I also google searched and found that others experienced the same:
The problem is not release_memory per se. The problem is the interaction between singleton_pool, pool_allocator and std::set. The example is using vector, which (probably) allocates exactly the type that you give it. std::set is allocating a different type. pool_allocator uses multiple singleton_pools, one for each size of object. release_memory would work if you could find the size of the object that std::set is actually allocating. Without knowing that, the best you can do is something like
// assume that the sizes are multiples of 4 bytes. boost::singleton_pool<boost::pool_allocator_tag, 4>::release_memory(); boost::singleton_pool<boost::pool_allocator_tag, 8>::release_memory(); boost::singleton_pool<boost::pool_allocator_tag, 12>::release_memory(); boost::singleton_pool<boost::pool_allocator_tag, 16>::release_memory(); boost::singleton_pool<boost::pool_allocator_tag, 20>::release_memory(); boost::singleton_pool<boost::pool_allocator_tag, 24>::release_memory(); boost::singleton_pool<boost::pool_allocator_tag, 28>::release_memory(); boost::singleton_pool<boost::pool_allocator_tag, 32>::release_memory(); // hope that's enough...
In Christ, Steven Watanabe
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
AMDG B Hart wrote:
nope, continued upwards and release_memory() always returns false.
I stepped though #include <boost/pool/pool_alloc.hpp> #include <set> int main() { { std::set<int, std::less<int>, boost::pool_allocator<int> > s; for(int i = 0; i < 100; ++i) { s.insert(i); } } boost::singleton_pool<boost::pool_allocator_tag, 20>::release_memory(); } and the call to release memory does seem to work.
Also, I would say that release_memory is broken, or needing revision, if one has to guess what the pool size is.
It isn't broken. release_memory works fine if you can find the right pool. Because std::set does not expose the type that it actually allocates there is no portable way to do so. In Christ, Steven Watanabe
So, I see likewise that 20 is the number per uint...I guess I missed it earlier. So, once I determine that I guess I can safely use 20? Another question: If I don't release but the set is destroyed then that pool's memory will get re-used if I create another set? I assume yes, but confirming. A comment: I strongly encourage whoever keeps up the documentation put in some additional notes about this behavior, and update the author's contact e-mail. It is difficult when it is new and one already has one's own code to deal with...e.g. while trying to figure this out I had another issue with MSVS 2008 not showing local variables in the debugger under Windows 7 64-bit. The VS issue only reared it's ugly head in my pool_alloc test program. And running into multiple issues at once is typical in my experience. On Thu, Mar 18, 2010 at 3:23 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
B Hart wrote:
nope, continued upwards and release_memory() always returns false.
I stepped though
#include <boost/pool/pool_alloc.hpp> #include <set>
int main() { { std::set<int, std::less<int>, boost::pool_allocator<int> > s; for(int i = 0; i < 100; ++i) { s.insert(i); } } boost::singleton_pool<boost::pool_allocator_tag, 20>::release_memory(); }
and the call to release memory does seem to work.
Also, I would say that release_memory is broken, or needing revision, if one has to guess what the pool size is.
It isn't broken. release_memory works fine if you can find the right pool. Because std::set does not expose the type that it actually allocates there is no portable way to do so.
In Christ, Steven Watanabe
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
AMDG B Hart wrote:
So, I see likewise that 20 is the number per uint...I guess I missed it earlier. So, once I determine that I guess I can safely use 20?
Well, if you don't care about portability it's safe. I only tried it msvc, I haven't tried any other std lib implementation.
Another question: If I don't release but the set is destroyed then that pool's memory will get re-used if I create another set? I assume yes, but confirming.
Yes.
A comment: I strongly encourage whoever keeps up the documentation put in some additional notes about this behavior, and update the author's contact e-mail.
I don't think anyone's keeping up the documentation now. If you create a trac ticket at svn.boost.org, I'll take care of it eventually.
It is difficult when it is new and one already has one's own code to deal with...e.g. while trying to figure this out I had another issue with MSVS 2008 not showing local variables in the debugger under Windows 7 64-bit. The VS issue only reared it's ugly head in my pool_alloc test program. And running into multiple issues at once is typical in my experience.
In Christ, Steven Watanabe
Thanks! I'll enter the ticket soon. On Thu, Mar 18, 2010 at 4:06 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
B Hart wrote:
So, I see likewise that 20 is the number per uint...I guess I missed it earlier. So, once I determine that I guess I can safely use 20?
Well, if you don't care about portability it's safe. I only tried it msvc, I haven't tried any other std lib implementation.
Another question: If I don't release but the set is destroyed then that pool's memory will get re-used if I create another set? I assume yes, but confirming.
Yes.
A comment: I strongly encourage whoever keeps up the documentation put in some additional notes about this behavior, and update the author's contact e-mail.
I don't think anyone's keeping up the documentation now. If you create a trac ticket at svn.boost.org, I'll take care of it eventually.
It is difficult when it is new and one already has one's own code to deal with...e.g. while trying to figure this out I had another issue with MSVS 2008 not showing local variables in the debugger under Windows 7 64-bit. The VS issue only reared it's ugly head in my pool_alloc test program. And running into multiple issues at once is typical in my experience.
In Christ, Steven Watanabe
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (2)
-
B Hart -
Steven Watanabe