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

Marshall Clow mclow.lists at gmail.com
Mon Sep 30 10:45:29 PDT 2013


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?

-- Marshall

Marshall Clow     Idio Software   <mailto:mclow.lists at gmail.com>

A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).
        -- Yu Suzuki

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130930/12380518/attachment.html>


More information about the cfe-commits mailing list