[pool] Improvements to boost.pool
Greetings, In the boost sandbox, under the /pool folder, I have committed a few small improvements and a few fixes for open tickets. Here is what I have changed : 1. I added boost::static_pool, a pool whose maximum size is known when initializing the pool; in which case all memory is allocated when calling the constructor. This is useful for software that must manage memory with great care. The implementation is a simple subclass of boost::pool. In the same vein, I also added boost::static_object_pool. 2. I also added boost::array_pool, a pool whose maximum size is known at compile time. The array_pool object hence already contains all memory it needs. Same for boost::array_object_pool. I am not sure that this is really useful and I am not sure I have picked a good name for it. 3. I handled ticket #3789 (https://svn.boost.org/trac/boost/ticket/3789). In short, releasing objects from a boost::object_pool was O(n) instead of expected O(1) and this constraint was required to keep the pool ordered so that the destructor of object_pool could destroy all objects that the calling program did not released. To solve this problem, I created an O(n log n) function which orders an unordered pool, a function that I called in the destructor. Thus, with my modification, releasing objects is O(1) and the destructor is O(n log n), or O(1) is the calling program was kind enough to release all objects. Although this does not change the API, it could have a negative impact on software that allocate large number of objects (using object_pool) but that never releases them. However, my modification greatly improves programs who repeatedly requests and releases objects. This modification also handles ticket #6610 (https://svn.boost.org/trac/boost/ticket/6610). 4. I added a pool.get_size() function (https://svn.boost.org/trac/boost/ticket/6865) that returns the current number of elements/objects for which the pool has allocated memory. 5. I clarified the meaning of the 'max_size' parameter, a recent addition to limit the amount of memory a pool can allocate with a single call to the allocator. See ticket #6867 (https://svn.boost.org/trac/boost/ticket/6867) for details. 6. I fixed miscellaneous minor tickets : #5902 (division by zero when requesting null sized buffers), #6561 (crash when releasing a null pointer), #6710 (integer overflows and possible crashes when requesting too many elements). 7. I added test cases for all modifications. I manually tested each case on Windows and used bjam on Linux, although I am not exactly sure that bjam did anything as it did not even report which test it ran. 8. I still need to update the documentation. Before doing that, I thought that I should submit my changes to the Boost community to see whether they are approved or not. And more prosaically, I still need to figure out how to generate the said documentation ! Now that these changes have been made in the sandbox, what is the next step to get them approved/amended/rejected ? Regards, Étienne Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute modification, édition, utilisation ou diffusion non autorisée est interdite. Si vous avez reçu ce message par erreur, merci de nous en avertir immédiatement. ATEME décline toute responsabilité au titre de ce message s'il a été altéré, déformé, falsifié ou encore édité ou diffusé sans autorisation. This message and any attachments are confidential and intended solely for the addressees. Any unauthorized modification, edition, use or dissemination is prohibited. If you have received this message by mistake, please notify us immediately. ATEME decline all responsibility for this message if it has been altered, deformed, falsified or even edited or disseminated without authorization. Note: To protect against computer viruses, e-mail programs may prevent sending or receiving certain types of file attachments.
Hi, I have a great interest in those enhancement, so first thank you very much for this work. I just wanted to know if you have been able to integrate those changes in a next version of boost? Joel Lamotte.
Now that changes have been made to boost::pool in the sandbox, what is the next step to get them approved/amended/rejected ? Regards, Étienne -----Message d'origine----- De : DUPUIS Etienne Envoyé : mercredi 16 mai 2012 12:43 À : boost@lists.boost.org Objet : [pool] Improvements to boost.pool Greetings, In the boost sandbox, under the /pool folder, I have committed a few small improvements and a few fixes for open tickets. Here is what I have changed : 1. I added boost::static_pool, a pool whose maximum size is known when initializing the pool; in which case all memory is allocated when calling the constructor. This is useful for software that must manage memory with great care. The implementation is a simple subclass of boost::pool. In the same vein, I also added boost::static_object_pool. 2. I also added boost::array_pool, a pool whose maximum size is known at compile time. The array_pool object hence already contains all memory it needs. Same for boost::array_object_pool. I am not sure that this is really useful and I am not sure I have picked a good name for it. 3. I handled ticket #3789 (https://svn.boost.org/trac/boost/ticket/3789). In short, releasing objects from a boost::object_pool was O(n) instead of expected O(1) and this constraint was required to keep the pool ordered so that the destructor of object_pool could destroy all objects that the calling program did not released. To solve this problem, I created an O(n log n) function which orders an unordered pool, a function that I called in the destructor. Thus, with my modification, releasing objects is O(1) and the destructor is O(n log n), or O(1) is the calling program was kind enough to release all objects. Although this does not change the API, it could have a negative impact on software that allocate large number of objects (using object_pool) but that never releases them. However, my modification greatly improves programs who repeatedly requests and releases objects. This modification also handles ticket #6610 (https://svn.boost.org/trac/boost/ticket/6610). 4. I added a pool.get_size() function (https://svn.boost.org/trac/boost/ticket/6865) that returns the current number of elements/objects for which the pool has allocated memory. 5. I clarified the meaning of the 'max_size' parameter, a recent addition to limit the amount of memory a pool can allocate with a single call to the allocator. See ticket #6867 (https://svn.boost.org/trac/boost/ticket/6867) for details. 6. I fixed miscellaneous minor tickets : #5902 (division by zero when requesting null sized buffers), #6561 (crash when releasing a null pointer), #6710 (integer overflows and possible crashes when requesting too many elements). 7. I added test cases for all modifications. I manually tested each case on Windows and used bjam on Linux, although I am not exactly sure that bjam did anything as it did not even report which test it ran. 8. I still need to update the documentation. Before doing that, I thought that I should submit my changes to the Boost community to see whether they are approved or not. And more prosaically, I still need to figure out how to generate the said documentation ! Now that these changes have been made in the sandbox, what is the next step to get them approved/amended/rejected ? Regards, Étienne Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute modification, édition, utilisation ou diffusion non autorisée est interdite. Si vous avez reçu ce message par erreur, merci de nous en avertir immédiatement. ATEME décline toute responsabilité au titre de ce message s'il a été altéré, déformé, falsifié ou encore édité ou diffusé sans autorisation. This message and any attachments are confidential and intended solely for the addressees. Any unauthorized modification, edition, use or dissemination is prohibited. If you have received this message by mistake, please notify us immediately. ATEME decline all responsibility for this message if it has been altered, deformed, falsified or even edited or disseminated without authorization. Note: To protect against computer viruses, e-mail programs may prevent sending or receiving certain types of file attachments.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of DUPUIS Etienne Sent: Monday, June 11, 2012 6:46 AM To: boost@lists.boost.org Cc: DUPUIS Etienne Subject: Re: [boost] [pool] Improvements to boost.pool
Now that changes have been made to boost::pool in the sandbox, what is the next step to get them approved/amended/rejected ?
Regards, Étienne
-----Message d'origine----- De : DUPUIS Etienne Envoyé : mercredi 16 mai 2012 12:43 À : boost@lists.boost.org Objet : [pool] Improvements to boost.pool
Greetings,
In the boost sandbox, under the /pool folder, I have committed a few small improvements and a few fixes for open tickets. Here is what I have changed :
1. I added boost::static_pool, a pool whose maximum size is known when initializing the pool; in which case all memory is allocated when calling the constructor. This is useful for software that must manage memory with great care. The implementation is a simple subclass of boost::pool. In the same vein, I also added boost::static_object_pool.
2. I also added boost::array_pool, a pool whose maximum size is known at compile time. The array_pool object hence already contains all memory it needs. Same for boost::array_object_pool. I am not sure that this is really useful and I am not sure I have picked a good name for it.
3. I handled ticket #3789 (https://svn.boost.org/trac/boost/ticket/3789). In short, releasing objects from a boost::object_pool was O(n) instead of expected O(1) and this constraint was required to keep the pool ordered so that the destructor of object_pool could destroy all objects that the calling program did not released. To solve this problem, I created an O(n log n) function which orders an unordered pool, a function that I called in the destructor. Thus, with my modification, releasing objects is O(1) and the destructor is O(n log n), or O(1) is the calling program was kind enough to release all objects. Although this does not change the API, it could have a negative impact on software that allocate large number of objects (using object_pool) but that never releases them. However, my modification greatly improves programs who repeatedly requests and releases objects. This modification also handles ticket #6610 (https://svn.boost.org/trac/boost/ticket/6610).
4. I added a pool.get_size() function (https://svn.boost.org/trac/boost/ticket/6865) that returns the current number of elements/objects for which the pool has allocated memory.
5. I clarified the meaning of the 'max_size' parameter, a recent addition to limit the amount of memory a pool can allocate with a single call to the allocator. See ticket #6867 (https://svn.boost.org/trac/boost/ticket/6867) for details.
6. I fixed miscellaneous minor tickets : #5902 (division by zero when requesting null sized buffers), #6561 (crash when releasing a null pointer), #6710 (integer overflows and possible crashes when requesting too many elements).
7. I added test cases for all modifications. I manually tested each case on Windows and used bjam on Linux, although I am not exactly sure that bjam did anything as it did not even report which test it ran.
8. I still need to update the documentation. Before doing that, I thought that I should submit my changes to the Boost community to see whether they are approved or not. And more prosaically, I still need to figure out how to generate the said documentation !
I can help with the docs (I translated the old Pool docs) but I have no more than superficial knowledge of Pool. But I am on holiday for a while, so mail me privately and I will reply when I get back.
Now that these changes have been made in the sandbox, what is the next step to get them approved/amended/rejected ?
Before any changes can be moved to boost-trunk, IMO we need input from pool library users. Some of the changes look very useful, but may break old code? Ask on boost-users list for support? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On Wed, 16 May 2012 12:42:46 +0200, DUPUIS Etienne <e.dupuis@ateme.com> wrote:
Greetings,
In the boost sandbox, under the /pool folder, I have committed a few small improvements and a few fixes for open tickets. Here is what I have changed :
1. I added boost::static_pool, a pool whose maximum size is known when initializing the pool; in which case all memory is allocated when calling the constructor. This is useful for software that must manage memory with great care. The implementation is a simple subclass of boost::pool. In the same vein, I also added boost::static_object_pool.
2. I also added boost::array_pool, a pool whose maximum size is known at compile time. The array_pool object hence already contains all memory it needs. Same for boost::array_object_pool. I am not sure that this is really useful and I am not sure I have picked a good name for it.
First thanks for working on Boost.Pool at all! That library really deserves some improvements. :) I'm not sure whether it makes sense though to introduce more pool classes if the algorithm to calculate the next chunk size is hardcoded into those classes again. If the existing classes in Boost.Pool would support a policy class, we could do everything what you described above without adding new classes? And if I wanted I could plug-in my own policy class if for whatever reason I want the sizes of all chunks to be prime numbers for example. I'm not a big fan of policy classes. But in this case it looks like it could be a really simple one. I think we need only one member function which returns the next size. Without that flexibility I (as a library user) either have to change code in Boost.Pool or open a ticket and propose boost::prime_numbers_pool to be added. ;) Boris
[...]
On Wed, 16 May 2012 12:42:46 +0200, DUPUIS Etienne <e.dupuis@ateme.com> wrote:
In the boost sandbox, under the /pool folder, I have committed a few small improvements and a few fixes for open tickets. Here is what I have changed :
1. I added boost::static_pool, a pool whose maximum size is known when initializing the pool; in which case all memory is allocated when calling the constructor. This is useful for software that must manage memory with great care. The implementation is a simple subclass of boost::pool. In the same vein, I also added boost::static_object_pool.
First thanks for working on Boost.Pool at all! That library really deserves some improvements. :)
I'm not sure whether it makes sense though to introduce more pool classes if the algorithm to calculate the next chunk size is hardcoded into those classes again. If the existing classes in Boost.Pool would support a policy class, we could do everything what you described above without adding new classes? And if I wanted I could plug-in my own policy class if for whatever reason I want the sizes of all chunks to be prime numbers for example. I'm not a big fan of policy classes. But in this case it looks like it could be a really simple one. I think we need only one member function which returns the next size. Without that flexibility I (as a library user) either have to change code in Boost.Pool or open a ticket and propose boost::prime_numbers_pool to be added. ;)
Boris
Greetings Boris, This is certainly a good idea. However, I consider that until there is a fix for ticket #3789 (https://svn.boost.org/trac/boost/ticket/3789), boost::pool is almost useless. Boost.Pool has no maintainer and I have no idea how to push through the fixes I made for open tickets (or get them amended or even rejected if they are bad). Any idea ? Regards, Étienne Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute modification, édition, utilisation ou diffusion non autorisée est interdite. Si vous avez reçu ce message par erreur, merci de nous en avertir immédiatement. ATEME décline toute responsabilité au titre de ce message s'il a été altéré, déformé, falsifié ou encore édité ou diffusé sans autorisation. This message and any attachments are confidential and intended solely for the addressees. Any unauthorized modification, edition, use or dissemination is prohibited. If you have received this message by mistake, please notify us immediately. ATEME decline all responsibility for this message if it has been altered, deformed, falsified or even edited or disseminated without authorization. Note: To protect against computer viruses, e-mail programs may prevent sending or receiving certain types of file attachments.
On Mon, Jun 18, 2012 at 9:34 AM, DUPUIS Etienne <e.dupuis@ateme.com> wrote:
This is certainly a good idea. However, I consider that until there is a fix for ticket #3789 (https://svn.boost.org/trac/boost/ticket/3789), boost::pool is almost useless. Boost.Pool has no maintainer and I have no idea how to push through the fixes I made for open tickets (or get them amended or even rejected if they are bad).
Any idea ?
I think Boost doesn't have that situation covered. If the 'current' maintainer can't be contacted you could volunteer to take over maintenance. -- Olaf
participants (5)
-
Boris Schaeling -
DUPUIS Etienne -
Klaim - Joël Lamotte -
Olaf van der Spek -
Paul A. Bristow