This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: mt allocator documentation (draft)


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".  

>               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 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.  

-- 
------------------------------------------------------------------
Brad Spencer - spencer@infointeractive.com - "It's quite nice..."
Systems Architect | InfoInterActive Corp. | A Canadian AOL Company


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]