[webkit-dev] WebKit memory management?

[Ferenc, Rudolf]

Paul Pedriana wrote:
>     >> 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).

Paul, do you have some idea how to #define such 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
>>
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ferenc.vcf
Type: text/x-vcard
Size: 365 bytes
Desc: not available
Url : http://lists.webkit.org/pipermail/webkit-dev/attachments/20080916/980805c8/attachment.vcf