MT allocator, part 2...

[Stefan Olsson]

Phil Edwards wrote:

>On Sat, Jun 01, 2002 at 01:27:32PM +0200, Stefan Olsson wrote:
>
>>I forgot two other questions that has been on my mind for a while...
>>- operator new() always uses malloc() in libstdc++. Snip from the C++ 
>>standard 18.4.1.1 "Whether the attempt involves a call to the Standard C 
>>library function malloc is unspecified." Have there been discussions 
>>about using the default (or any other allocator such as the MT allocator 
>>that I am talking about) instead? And if so, how could this be defined 
>>without breaking the standard compliance?
>>
>
>I'm unsure what you mean by "using the default instead".
>
>Do you mean, have operator new use the default memory allocator?
>That would cause infinite recursion resulting in the universe imploding,
>because the default memory allocator uses the mem_interface hook, which
>uses operator new.  :-)
>
>Right now there are two choices for mem_interface:  malloc, or operator new
>(which right now calls malloc).  Bear in mind that user code is allowed
>to #include <new> and then define a replacement for operator new.  This is
>allowed inside the language.
>
>Outside the language, users can provide various replacements of functions,
>e.g., LD_PRELOAD=/home/me/lib/my_funky_malloc.so, or whatever.
>
>
>I am more than willing to have different allocators available -- actually,
>I'd very much like to rework the default pool allocator to make its
>parameters tweakable by the user -- but we must be careful of ABI changes.
>
>Making such "alternative allocators" a choice for operator new would be
>a little... odd.  If the user wants to replace operator new, it's better
>if he does it explicitly, instead of something like
>
>    #define _GLIBCPP_MAKE_OP_NEW_USE_WEIRD_ALLOCATOR_NUMBER_SEVENTEEN
>    #include <memory>
>
I agree. In the reply of the first email (sorry for the mess...) I argue 
that we probably should look at a unified way of dealing with memory to 
lower the amount of malloc() system calls, be able to improve locality 
and lower fragmentation. If new() could make use of the same memory 
management as the STL this could be accomplished - but then again: I 
would not like to be the reason for the universe imploding ;-)

>>- Basically the same question goes for allocation related to exception 
>>handling (see function __cxa_allocate_exception(std::size_t thrown_size) 
>>in libstdc++-v3/libsupc++/eh_alloc.cc). I fully understand that this is 
>>a much more complex issue to solve, but exception handling is one of the 
>>great features of C++ and if we can find a way to lower the performance 
>>penalty of using it...
>>
>
>Saying "solve" implies that there's a problem.  :-)
>
>There may /be/ problems, certainly, but some things to consider:
>
>1)  std::malloc is, after all, /the/ standard memory allocator, by definition.
>    That function is executed when your code is in the process of throwing
>    an exception, and that's not necessarily a good time to be playing
>    odd memory games in user space.  (What if it was your own allocator
>    that caused the exception in the first place?  Ouchies.)
>
>2)  Even more ABI issues here.
>
>3)  Exceptions are expensive.  That's okay, because they are only supposed to
>    occur in situations that are /exceptional/.  We're trying to make
>    'try' blocks relatively cheap, and run the expensive parts (like memory
>    allocation) only when an exception is actually thrown.  We're all for
>    speeding things up, but we must be careful not to penalize code that
>    doesn't actually throw an exception.
>
>Perhaps instead of __cxa_allocate_exception calling std::malloc directly,
>we follow the example of std::terminate, where a default function is defined,
>but can be replaced by the user.
>
Clearly I did not think this one through...
...thanks for the explanation!

Brgds

/Stefan

>
>
>
>Phil
>


-- 
In any organization there will always be one person who knows what is going on.

This person must be fired.