mt allocator documentation (draft)

Felix Yen fwy@alumni.brown.edu
Wed Feb 4 09:09:00 GMT 2004


When allocating:
 >  A quick look at _S_bin[ bin ].first[ thread_id ] tells us if there 
are any blocks
 >  of this size on the current threads freelist. If this is not NULL - 
fine, just
 >  remove the block that _S_bin[ bin ].first[ thread_id ] points to 
from the list

When deallocating:
 >  always add the block to the end of the current threads freelist

If a thread consumes all the memory it allocates, it allocates or 
recycles some blocks in order to satisfy its first allocation request, 
and then uses all of the blocks in this initial allocation before it 
reuses the first one.  That might be the best approach, but it's also 
plausible to put the deallocated blocks at the head of the free list so 
they're reused first.  The documentation should explain why one 
approach was chosen over the other, and should address scenarios where 
sequences are constructed and destroyed.  (This request may lead to 
complications.)

Still deallocating:
 >  In order to reduce lock contention (since this requires this bins 
mutex to
 >  be locked) this operation is also made in chunks of blocks (just 
like when
 >  chunks of blocks are moved from the global freelist to a threads 
freelist

When the allocator reuses blocks from the global free list, it's 
reasonable to take a chunk's worth of blocks if possible, and as many 
as possible otherwise.  You have to acquire a lock to accurately 
measure the global free list's size, and once you've done this, it 
would be strange to allocate from the heap in the case where there is 
enough memory to satisfy the request, but less than a chunk's worth.  
There's also no point in leaving a block in the global free list in 
order to satisfy another thread's request.

The corresponding deallocation scenario is more complicated.  When a 
thread's free list reaches its maximum size, you can try to move a 
chunk's worth of blocks to the global free list, which could erase the 
thread's free list (potentially inefficient), or do something else, 
e.g. refer to chunk size in the maximum size computation.  The 
documentation should provide more detail about this aspect of the 
algorithm.


Felix



More information about the Libstdc++ mailing list