[webkit-dev] WebKit memory management?

[Zoltan Horvath]

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?