[webkit-dev] WebKit memory management?

[zaheer ahmad]

As paul had mentioned, typically on an embedded platform you would want the
webkit library to work in a bounded memory (<10Mb) and signal an OOM
condition if it crosses that and recover gracefully(either cleanup
caches/history, stop loading current page, restart the app if nothing
possible) without impacting the system. you dont want this to happen too
often in production build, but how can you guarantee with current
implementation?

>> we found out that the Linux's standard malloc is good enough,
would it be the same if the memory manager (dlmalloc) gets the 10Mb
initially and manages it with out going to the system allocator

Also In point 1 above, i would like to know the recovery mechanisms
generally employed without causing too much user annoyance.

thanks,
Zaheer

On Mon, Sep 15, 2008 at 5:01 PM, Mike Hommey
<mh+webkit at glandium.org<mh%2Bwebkit at glandium.org>
> wrote:

> On Mon, Sep 15, 2008 at 11:21:31AM +0200, Ariya Hidayat <
> ariya.hidayat at trolltech.com> wrote:
> >
> > > our goal is to change standard malloc to tcmalloc under linux-qt port
> but
> > > we couldn't solve operator new and delete problems.  As we see Paul's (
> > > https://bugs.webkit.org/show_bug.cgi?id=20422 ) solution can
> > > solve this, therefore if the community accepts this change then we
> would
> > > gladly help to replace all new and delete operators to the new ones.
> >
> > Because typically we build QtWebKit as a shared library, this raises the
> > problem that the overloaded new/delete will be global, i.e. this would
> also
> > affects the application that links QtWebKit, so not only at the library
> level
> > (QtWebKit).
> >
> > The mentioned patch seems to solve this problem, but at the cost of
> reduced
> > syntax readability because we can't use the familiar C++ new/delete
> > constructs anymore (AFAICS we are not even allowed to use it anymore). I
> > wonder whether this is a good compromise, i.e. what justifies it more
> than
> > just providing the new/delete override at the application (I wasn't
> involved
> > in previous memory management discussions before, so please point out
> what I
> > miss here).
> >
> > Side note: we found out that the Linux's standard malloc is good enough,
> > enabling the JSC's (tcmalloc-based) FastMalloc does not add any
> significant
> > speed boost. This is however different on QtWebKit/Win32, where
> FastMalloc
> > improves SunSpider by 30%.
> >
> > (Of course I might be wrong here, so feel free to provide corrections).
>
> It might be beneficial on long term use, where memory
> allocation/deallocation
> will have created fragmentation, making the process need a lot of virtual
> memory because it can't fill the holes, making the whole thing be a memory
> hog. Tcmalloc has usually less fragmentation.
>
> Mike
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20080915/e412518f/attachment.html