Something about the mt_allocator.

[Stefan Olsson]

Dhruv Matani wrote:

>>Does this cost outweigh the benefit?  It depends on how 
>>recycling is done, how often it's used, and other factors including the 
>>quality of the underlying allocator.  So we just need test results 
>>demonstrating that the new allocator outperforms new_allocator (and 
>>pool_allocator).
>>    
>>
>
>AFAICS, the allocator (mt_alloc) makes no effort to make sure that the
>block of size (4K-4*sizeof(void*)) is 4K aligned. It may very well being
>in the middle of an existing page, which may be needed by 2 threads
>running on 2 different processors at the same time. Also, for systems
>where the default malloc does not have a 4*4 byte overhead (maybe a 2~3
>*4 byte overhead), then the new memory will not exactly be page aligned
>always even if the first request was page aligned. Also, in the middle
>of 2 requests by mt_alloc<>, the user may ask for 8 bytes? What to do
>now?
>
>  
>
My 2 cents on this specific issue: the default chunk_size value should 
be defined per platform and possible to override with a tuning parameter.

Brgds

/Stefan