Allocator tuning parameters

[Loren James Rittle]

> 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.

> 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.

Regards,
Loren