[webkit-dev] global new/delete operator in WebKit

[Yong Li]

Darin, thank you very much for writing this for my questions. I have another
question for "new int[10]", but I guess the answer will be "using Vector
instead".

I like the idea that webkit should allow using a custom memory allocator,
but I think for most platforms/compilers, overloading global new/delete
operators is much better than deriving all classes from FastAllocBase. I've
seen even the simple utility class "Noncopyable" is derived from
FastAllocBase, and the follwing code:
class A: Noncopyable
must be changed to:
class A: public Noncopyable
in order to make "new A" accessible.

As webkit provides the option of using custom allocator with FastAllocBase
for some special platform/compiler, why does it ban the option of using
global new/delete operators on other platforms/compilers? At least, when
USE_SYSTEM_MALLOC=1, FastAllocBase should just be empty or redirect to
global new/delete in my opinion.

-Yong

2010/1/13 Darin Adler <darin at apple.com>

> In the discussion in bug 32831, Yong Li asked me why we are planning, in
> the future, to remove the global new/delete operator in the Mac OS X WebKit.
>
> I decided it was worth answering here.
>
> Why does WebKit override operator new/delete? Historically on Mac OS X we
> got faster performance by using a custom malloc in the WebKit framework. At
> some future date we may discover that we no longer get a performance boost
> from this, and change this on Mac OS X.
>
> Ports to other platforms should not assume they need to use a custom
> allocator. It’s not a given that the FastMalloc code will be faster than
> using the platform malloc/free directly. But it was true in the first WebKit
> platform, Mac OS X, at the time.
>
> On Mac OS X, WebKit overrides the global operator new and delete to
> accomplish this. That was a big time saver — it made all new and delete use
> the faster allocator without code changes to all the classes. This
> particular technique works well for frameworks on Mac OS X. The inlined new
> and delete operator functions are marked “private extern”, which means they
> are visible inside the WebKit umbrella framework, but not seen by programs
> loading the framework. As long as we don’t have any new/delete allocations
> that cross the boundary between WebKit and the host application or other
> frameworks, this works fine. The new/delete invocations inside WebKit use
> the global new/delete defined inside the framework and the new/delete
> invocations outside WebKit are not affected.
>
> On some other platforms, though, this creates problems. An operator new and
> delete defined inside the WebKit library may not even work, depending on how
> C++ binds the symbols. The “private extern” extension may not work at all.
> Or the API for that platform might involve objects where the new is done
> inside the framework and the delete is done outside the framework. A simple
> solution would be to not override the global new/delete operator on those
> platforms.
>
> But some contributors want to use a custom allocator even though the global
> new/delete operator technique does not work on the platform they care about.
> So they began the massive task of adding code so that all allocations in
> WebKit were done through the custom allocator without relying on global
> new/delete. This project, see <
> https://bugs.webkit.org/show_bug.cgi?id=20422> began in 2008. The
> check-ins to put it into practice began las April <
> http://trac.webkit.org/changeset/42344>. We’ve still got a ways to go to
> get it deployed throughout the WebKit code.
>
> To keep this code maintained properly, I propose that no platform rely on
> overriding the global new/delete operator inside WebKit once the work is
> complete. Instead I think we can use global new/delete operator as a
> debugging technique to make sure people remember to use FastAllocBase and
> fastNew/Delete rather than invoking the built-in C++ new/delete by accident.
> This has no direct benefit for the Mac OS X version of WebKit, but I believe
> it’s helpful for the community to use that platform to support the others
> that wish to do this.
>
> Yong Li also asked about standard library functions calling new and delete,
> specifically STL. I believe we have been avoiding calling these functions in
> WebKit, but I may be mistaken.
>
> I haven’t discussed this tradeoff in detail with others at Apple, so I’m
> not absolutely certain what we’ll do in the Mac OS X version.
>
> If you have any questions or concerns, please bring them up here.
>
>    -- Darin
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100113/6150d570/attachment.html>