This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: RFC on mt_allocator.h
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