> 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.
Ah I see now. So you want to isolate the malloc from WebKit module.
Furthermore, you want to be able to "kill" WebKit *only* when something weird
happens, am I correct?
> 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.
Yes, that is true.
> 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.
>
> 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'm curious to see the patch (just to give an idea how big the changes would
be). Do you have it somewhere?
--
Ariya Hidayat ([EMAIL PROTECTED])
Software Engineer, Trolltech (a Nokia company)
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
