[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
gathering.
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.
Paul
>> 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