[libcxx] Patch/RFC: Avoid using ::operator new in the default allocator

Benjamin Kramer benny.kra at gmail.com
Mon Sep 30 11:23:16 PDT 2013


On 30.09.2013, at 19:45, Marshall Clow <mclow.lists at gmail.com> wrote:

> On Sep 25, 2013, at 2:21 PM, Chandler Carruth <chandlerc at google.com> wrote:
> 
>> I also know that regardless of the solution, Marshall has thoughts on the best way to factor this within the library, but those are orthogonal.
> 
> Benjamin --
> 
> Here's my suggestion.
> 
> No matter how this comes out, I think having one place in the library where we allocate memory "in a default" manner is a good thing.
> So let's do that first.
> 
> My suggestion is 
> 
> 1) Define two routines (probably in <new>):
> 
> _LIBCPP_ALWAYS_INLINE void *__allocate     ( std::size_t sz ) { return ::operator new ( sz ); }
> _LIBCPP_ALWAYS_INLINE void *__deallocate ( void * p )         { return ::operator delete ( p ); }
> 
> [ MIght need different names, since hash_table has a __deallocate and dynarray has an __allocate and __deallocate ]
> 
> and call them from the places in <memory> that you noted.
> 
> 2) Make sure that works, then switch them (__allocate/__deallocate) to use new char []/delete [] and make sure that your optimization still works.
> Then, switch them back while we figure out the correct way to solve this.
> 
> 3) Next, find all the places in libc++ where we call ::operator new/delete, and switch them over to calling __allocate/__deallocate.
> That way, when we figure out the best way to solve this, we'll reap the benefits library-wide.
> 
> How does that sound to you?

It sounds like a great first step! Howard probably has an opinion on where's the best place for the new functions.

- Ben





More information about the cfe-commits mailing list