This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: MT allocator, part 2...
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.