Hi, > I'm curious to see the patch (just to give an idea how big the changes > would be). Do you have it somewhere?
we made a patch for JavaScriptCore under linux-qt. (See: https://bugs.webkit.org/show_bug.cgi?id=20422 ) Related for this, we also made patches to switch between custom allocators (TCmalloc, JEmalloc). (See: https://bugs.webkit.org/show_bug.cgi?id=21272 ) Regards, Zoltan Ariya Hidayat wrote: > > 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? _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev