[webkit-dev] WebKit memory management?

[Maciej Stachowiak]

On Sep 15, 2008, at 1:53 PM, Paul Pedriana wrote:

> 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.

The problem with this syntax is that you can't do the corresponding  
thing with operator delete, as far as I know.

> 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.

I hope to look at your patch soon. I think we absolutely need to fix  
the broken overriding of the global operator new / operator delete,  
but I want to make sure the syntax we end up with is as friendly as  
possible, since it will be pervasive throughout the code.

Regards,
Maciej

>
>
> 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).
>>
>>
>>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev