RFC on mt_allocator.h

[Stefan Olsson]

Benjamin Kosnik wrote:

>Hi Stefan.
>
>  
>
>>The main issue is how to set these values/settings since they are
>>"global" and cannot be passed as arguments but rather must be set at
>>compile time (using defines, commandline options, functions to be
>>called- I don't know) or at startup using some env variables?
>>    
>>
>
>I would imagine that you could set allocation size dynamically, with an
>accessor member function. This would probably best be in a base class
>that is not a template. Perhaps Gaby or others have more interesting
>design ideas?
>
Ok let's see if I understand this correctly:
A static var is defined somewhere and assigned a default value during 
library initialization and can then be altered by users by calling a 
function i.e. void/bool setfreethreshold( value );

In that case I basically understand how to do it - however I will need 
help to decide where to put these static vars and function and how they 
should be named.

>
>This is applicable to
>
>Item 1: Minimum memory in freelists
>Item 4: Maximum block size.
>
>Anyway. On to the other items!
>
>Item 2: Allocate chunks of memory directly to threads when freelist is
>empty
>
>  
>
>>One approach to improve this behaviour and to minimize global locking
>>would be to allocate chunks of memory directly to threads if the own
>>freelist is empty. Today, if the threads own freelist is empty the
>>global freelist for that size is locked, a block removed from this
>>list, the global list is unlocked and the memory is returned. When
>>there are no free blocks in the global list either, a chunk of memory
>>is allocated and a new list is created within that memory (based on
>>the blocksize). With this change, if a threads freelist for a certain
>>blocksize was empty, a chunk of memory would be allocated by that
>>thread, a list created and the memory returned. Subsequent requests
>>could then be satisfied without locking.
>>    
>>
>
>In general, anything you can do to reduce global locking and calling the
>underlying allocator the better. I'm not quite sure if this should be
>configurable, or just the default. Do you have performance numbers on
>this?
>
No, but I believe that this will radically improve overall performance 
of short-lived threads and agree that this should be default. I will 
implement this and produce some numbers.

>
>Item 3: Lingering freelists, reusing thread-ids.
>
>  
>
>>Q: Should the behaviour of the thread_id freelist be changed so that
>>thread id's
>>   are reused as soon as possible and make it possible not to return
>>   memory to global pool? 
>>    
>>
>
>I would think this would be the best approach to take, and fits in with
>2. Basically, after memory is allocated on a freelist, don't delete it
>and store it away.
>
>However, perhaps I'm missing something obvious. It would be interesting
>to try this approach vs. current approach with the performance tests for
>allocators.
>
Some applications may be very restricted in terms of memory usage, so I 
think that it should be possible to turn this off (on by default) using 
a function call as well.

>
>Item 5: Option to clear memory when it's deallocated 
>I think this is an interesting idea, and obviously useful, but couldn't
>you do this in another allocator, that wraps this one? See
>debug_allocator for more info.
>
Yes of course. We'll leave this for now.

>
>
>Issues not addressed in your RFC:
>
>1) Please come up with some names that aptly describe exactly what this
>allocator is doing. The goal is for people, when confronted with the
>allocators in ext/ to have an idea what each one does. 
>
>
>2) Please, I beg you, document this allocator. The concepts in your
>initial email is a good place to start.
>
Yes, I will try to write a document on this allocator along with some 
images to get a picture of how things are structured...

Brgds

/Stefan

>
>-benjamin
>  
>