[webkit-dev] WebKit memory management?

Paul Pedriana ppedriana at gmail.com
Mon Sep 15 13:53:23 PDT 2008

Regarding purpose:

The primary benefit of being able to override operator new is to be able 
to redirect all allocations for a library to a user-specified heap. With 
global operator new, allocated WebKit memory is mixed in with the rest 
of the application memory and there is no practical way to tell them 
apart or sequester them. This makes it impossible to correctly shut down 
WebKit at runtime, since you don't know where its memory is. A side 
benefit related to this is that this allows for better memory metrics 

A related problem is that parts of WebKit currently make the assumption 
that operator new == tcmalloc; this includes using them interchangeably 
in the code (see JSVariableObject for example). tcmalloc is a fine heap 
for some platforms but in most cases is not the best option for embedded 
or console platforms. Currently WebKit heap memory is allocated by at 
least four means: operator new, malloc, fastMalloc, and mmap. We would 
like to see all memory allocation going through a single controllable 
API (such as the proposed operator new), though for Unix platforms I can 
see the benefit of mmap for the JavaScript VM.

Regarding syntax:

The proposal provides for a base class that overrides global operator 
new. So any allocated classes use the same syntax as usual. Most of the 
source code would fall under this.

For the case of non-class-based memory allocations (e.g. raw char 
array), the proposal provides a newObject and newArray template 
function. So instead of 'new int' you would way 'newObject<int>' and 
instead of 'new char[32]' you would say 'newArray<char>(32)'. However, 
there is an alternative approach which is to provide a custom operator 
new type, like so:
    struct WTF{};
    void* operator new(size_t size, WTF);

and so 'new char[32]' becomes 'new(WTF()) char[32]'. This is the 
conventional solution to namespacing operator new, where the C++ 
standard doesn't allow for operator new being in a C++ namespace. 
Perhaps this syntax is preferable. This can be #defined to simply newWTF 
if desired, then it is practically identical to existing global new syntax.

FWIW, I have been testing the proposed patch in my copy and so far it 
has been fine, but that of course includes only my uses.


>> If I understand Mr. Pedriana correctly, you are incorrect in assuming that
>> we would get "reduced syntax readability". You may use the regular "new"
>> syntax that C++ programmers are accustomed to when allocating objects and
>> arrays of objects that inherit from AllocBase. Pedriana proposes that we
>> eventually add AllocBase as the base class of all root classes in WebKit,
>> thus making AllocBase the only root class.
>> The only time when you would need to use newObject/newArray is for some
>> stray new/new[] calls when allocating something that does not inherit from
>> AllocBase, i.e. a simple datatype.
> I'm personally happy if we won't have the reduced syntax readability :-)
> Still, I'm curious to see the use cases where it makes more sense to do this 
> instead of global new/delete overrides at the application level. Feel free to 
> enlighten me here...
> (BTW, no need to CC me. I'm on the list).

More information about the webkit-dev mailing list