Allocator tuning parameters

[Stefan Olsson]

Loren James Rittle wrote:

>>1) The following piece of code is taken from ext/pool_allocator.h:
>>     if (_S_force_new == 0)
>>       {
>>         if (getenv("GLIBCXX_FORCE_NEW"))
>>           __atomic_add(&_S_force_new, 1);
>>         else
>>           __atomic_add(&_S_force_new, -1);
>>       }
>>Should all allocators support this?
>>    
>>
>
>I will state MHO.  Any allocator, to be made the default, should
>support the above construct internally.  The reason is that people
>will compile their application normally against the default allocator.
>We want to ensure that people can always disable memory caching within
>the library.  Also, many people have tools which directly hook to
>malloc/new, free/delete to look for programming errors.  The use of a
>pool hides various application-level testing developers could
>otherwise do.
>
>There is also the issue that the default pool allocator has some cases
>where its performance profile truly stinks (for single-threaded, we
>think it beats most per-platform malloc implementations; however I
>have test cases where that is not always true).  Since we never
>figured out the best way to set the default allocator on a
>per-platform basis, the compromise was to always allow one to disable
>the pool cache.
>
My suggestion then is that we make this functionality "mandantory" in 
each of the ext/*_allocators as well.

I haven't looked at the code behind getenv (on Linux/glibc) but I guess 
that there is some kind of overhead since it can't be evaluated at 
compile time. Therefore I believe that the actual implementation of this 
functionality could vary between allocators. I.e. in mt allocator the 
getenv call would be done only once in _S_init() instead of on each 
allocate() call.

>
>  
>
>>2) If so, is this a approach that should be standardized and used to 
>>i.e. pass the threshold value to mt allocator? If a naming convention 
>>could be thought out it could be a simple and easy way for 
>>administrators to tune already compiled applications to suit their 
>>memory restraints and/or preferences. As an example, _S_init() in mt 
>>allocator could then check for the value of GLIBCXX_MT_ALLOC_THRESHOLD 
>>and if that value can be validated (in terms of type and range) that 
>>would be used instead of the preinitialized value of the global static 
>>variables.
>>    
>>
>
>I'd support work in that area, if you are willing to enhance your
>allocator with externally settable parameters.
>
Ok. I will prepare a small patch that implements this idea for reviewing.

Brgds

/Stefan

>
>Regards,
>Loren
>  
>