This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: mt allocator documentation (draft)
- From: Brad Spencer <spencer at infointeractive dot com>
- To: Stefan Olsson <stefan at xapa dot se>
- Cc: libstdc++ <libstdc++ at gcc dot gnu dot org>
- Date: Tue, 3 Feb 2004 00:52:14 -0400
- Subject: Re: mt allocator documentation (draft)
- References: <401CD9CC.8000306@xapa.se>
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