[webkit-dev] global new/delete operator in WebKit
Darin Adler
darin at apple.com
Wed Jan 13 09:19:17 PST 2010
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
More information about the webkit-dev
mailing list