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