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@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
begin:vcard
fn:Ferenc Rudolf
n:Ferenc;Rudolf
org:University of Szeged;Department of Software Engineering
adr;quoted-printable:;;=C3=81rp=C3=A1d t=C3=A9r 2;Szeged;;6720;Hungary
email;internet:[EMAIL PROTECTED]
title:Assistant professor
tel;work:+3662544145
tel;fax:+3662546723
x-mozilla-html:FALSE
url:http://www.inf.u-szeged.hu/~ferenc/
version:2.1
end:vcard
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
