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
>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
