[webkit-dev] WebKit memory management?

[Paul Pedriana]

Thanks for the info. IMHO, tcmalloc is not appropriate for console, 
embedded, and mobile platforms. It trades space for speed, and that's 
the opposite of what you want outside the desktop. This is why the Nokia 
S60 people replaced tcmalloc, for example.

Unfortunately, overriding operator new and delete does not do the right 
thing. These operators are application-global functions and when you 
redirect them for one library you are thus redirecting them for the 
entire rest of the app. Needless to say, that is a bad thing. In console 
and embedded development, as I note in the aforementioned paper, it is 
typically verboten for a library to use operator new/delete. Neither 
will you see professional commercial software do this. It's also a 
problem to have any calls to system malloc at all, because often on 
these platforms there is little or no memory available, as the 
application has taken it all to distribute to private heaps as per their 
budget.

One simple and effective way to solve this problem is to provide a 
memory config header file which defines macros or templates which 
replace new/delete, malloc/free. Instead of calling global new, WC_NEW 
(e.g.) is called instead, and it has the same behavior as new but uses 
the user defined allocator instead. By default, WC_NEW can use 
fastmalloc and thus you have backward compatibility. What we do in game 
development is take this a step further and provide arguments to WC_NEW, 
in particular a name argument that identifies the system the allocation 
belongs to. Thus you could use WC_NEW("WebCore/page") to flag the memory 
as belonging to that subsystem. This is invaluable in identifying 
memory, producing subsystem metrics, optimizing memory coherence, and 
deducing memory leaks (though other means also help find leaks).
I would like to suggest that WebKit take some steps toward this or some 
similarly effective approach to memory management. This is how 
commercial-quality software is done, it would benefit all users, and it 
would greatly increase the attractiveness of WebKit to game, embedded, 
and mobile developers. And it's easy to do. I can offer to provide a 
straw-man implementation of it as well.

Game teams are chomping at the bit to have an in-game browser and could 
save a lot of money by using WebKit instead of a commercial solution. 
WebKit is best positioned to become the dominant browser in this arena 
and could see a large increase in effective installed base as a result. 
And there aren't many things beyond this memory management thing that 
are standing in the way.

Thanks.



> On 03/06/2008, at 19:58, Paul Pedriana wrote:
>> As I have mentioned recently on this list, I am investigating the
>> possibility of porting WebKit to work within games on gaming platforms.
>> Recent help on this has been greatly appreciated and I am going to try
>> to stick with WebKit as opposed to Mozilla/Gecko.
>>
>> A major consideration for the usage of libraries in general on gaming
>> and embedded platforms is that their memory usage be controllable. The
>> application should be able to set aside a block of RAM and have the
>> library use that block of RAM via a user-supplied memory allocator. At
>> no time should the library attempt to use any other memory nor use its
>> own means to access the user-provided memory. This pattern of library
>> development is very important, and most professional commercial library
>> software follows this pattern (including all commercial peers of
>> WebKit). I am wondering how I might achieve this with WebKit.
>
> WebKit uses a derivative of Google's high-performance Thread Caching 
> Malloc 
> (<http://google-perftools.googlecode.com/svn/trunk/doc/tcmalloc.html>) 
> for the majority of allocations.  We've tuned the allocator to add 
> further performance gains over the system allocators on Mac and 
> Windows, and have recently made further improvements to ensure unused 
> memory is returned to the system.  Within JavaScriptCore and WebCore 
> we overload "operator new" and "operator delete" in terms of our 
> "fastMalloc" and "fastFree" functions to ensure all C++ object 
> allocations go via this allocator 
> (<http://trac.webkit.org/browser/trunk/JavaScriptCore/wtf/FastMalloc.h>).  
> The few direct calls to "malloc" and "free" within JavaScriptCore and 
> WebCore are also made via our wrapper functions.  This should make it 
> straightforward to substitute your own custom allocator in place of 
> WebKit's if it would better suit your target environment.
>
> Kind regards,
>
> Mark Rowe
>