MT allocator, part 2...

[Phil Edwards]

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>


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


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams