mt allocator documentation (draft)

[Stefan Olsson]

Brad Spencer wrote:

>On Sun, Feb 01, 2004 at 11:49:48AM +0100, Stefan Olsson wrote:
>  
>
>>Over time the allocator has evolved and been improved in many 
>>ways, one of the being that it now also does a good job in single threaded 
>>applications [hereinafter referred to as a ST application].
>>(Note: In this document, when referring to single threaded applications this 
>>also includes applications that are compiled with gcc without thread support 
>>enabled. This is accomplished using ifdef's on __GTHREADS)
>>    
>>
>
>I'd just like to register the fact that I greatly appreciate time
>taken to ensure that single-threaded performance is still "as good as
>possible".  
>
Bad choice of words...
...the goal is of course to get as good performance as possible in 
single threaded applications as well - my mind is just so set on multi 
threading right now =)

>
>  
>
>>              I.e. By default the allocator will deal with requests of up to 
>>    128 bytes (or whatever the value of _S_max_bytes is when _S_init() is 
>>    called). This means that there will be bins of the following sizes 
>>    (in bytes): 1, 2, 4, 8, 16, 32, 64, 128. 
>>    
>>
>
>I can't wait to tweak that value, BTW ;)  We tend to have lots of small
>objects and experience hasn't shown me that Solaris has the world's
>best malloc().
>
A getenv() based patch for this will soon be at a mailinglist near you...

>
>  
>
>>A single threaded example (and a primer for the multi threaded example!)
>>------------------------------------------------------------------------
>>Let's start by describing how the data on a freelist is layed out in memory.
>>This is the first two blocks in freelist for thread id 3 in bin 3 (8
>>bytes):
>>    
>>
>
>I don't quite follow how the single-threaded example talks about
>thread_id 3. :)  But, it does look like the memory for the thread_id
>used even when we're in "hard" single-threaded (i.e. when __GTHREADS
>is not defined).  It would seem that we could save a size_t per
>allocation in that case simply by wrapping block_record's thread_id
>declaration with the __GTHREADS guard.  
>  
>
I know that it is a bit confusing with the example thread_id = 3 - maybe 
the "drawing" should be in it's own paragraph/appendix...

You are quite right, when __GTHREADS is undefined we could also remove 
the thread_id var from the block_record struct.

The reason - which at the time when I am writing this I am no longer 
sure that it actually is a reason - was to keep the memory layout the 
same if a ST and a MT program somehow shared containers via some obscure 
IPC mechanism...
...not very likely huh? This should probably be changed to save memory.

Brgds

/Stefan