[webkit-dev] WebKit memory management?

[Maciej Stachowiak]

On Sep 16, 2008, at 4:56 AM, Ferenc, Rudolf wrote:

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

This is better done with template functions than macros in my opinion.

  - Maciej

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