[webkit-dev] WebKit memory management?

[Paul Pedriana]

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

You are correct; delete would still need to be done differently 
(assuming you don't define a deleteWTF macro).

The fact that operator delete cannot be overridden is one of the 
limitations of the C++ language. The primary reason why is that the 
compiler needs to generate delete calls for objects that throw during 
construction, and there isn't an easy means to convey to the compiler 
which delete in particular you want it to generate.

Paul


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