RFC on mt_allocator.h

[Felix Yen]

Re: Item 4 (maximum block size).  First, I'd say that there are 
actually two questions here: (1) how should this limit be encoded, and 
(2) what should be its default value?  I think the current encoding 
technique is adequate, but a more dynamic solution would be justified 
if such a thing were introduced to address another allocator 
configuration issue.

As for the default value of 128, I agree that many applications 
routinely allocate larger objects, but it's not clear that they do so 
via an STL allocator.  In my work, the most common container element 
type is some sort of pointer, especially a smart pointer.  While this 
style of representation makes it harder to ensure locality of 
reference, widespread use of smart pointers makes it difficult to 
create memory leaks.  Furthermore, pointer elements can be freely 
copied between containers of different types, so this approach 
facilitates optimizing an application by changing the type of a 
container.  From this perspective, 128 is quite generous.  I can also 
provide a data point demonstrating that this view is shared: Loki's 
small object allocator uses 64 as its default limit.  (Perhaps 
small_allocator would be a better name, since any allocator should 
support multithreading.)

On the other hand, I think people may begin to use STL allocators more 
often.  For example, any policy-based library might give its users the 
ability to customize memory management by specifying a template 
parameter, and I see no reason why this parameter shouldn't default to 
std::allocator.  So we might (should?) expect these allocators to be 
used by objects that are not STL containers.

In short, I'd say that doing nothing is a good tactical solution, but 
in long run 128 might be a little small, and dynamic configuration is 
always a good thing.


Felix