[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