<div dir="ltr">As paul had mentioned, typically on an embedded platform you would want the webkit library to work in a bounded memory (&lt;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?<br>
<br>&gt;&gt; we found out that the Linux&#39;s standard malloc is good enough,<br>would it be the same if the memory manager (dlmalloc) gets the 10Mb initially and manages it with out going to the system allocator<br><br>
Also In point 1 above, i would like to know the recovery mechanisms generally employed without causing too much user annoyance.<br><br>thanks,<br>Zaheer<br><br><div class="gmail_quote">On Mon, Sep 15, 2008 at 5:01 PM, Mike Hommey <span dir="ltr">&lt;<a href="mailto:mh%2Bwebkit@glandium.org">mh+webkit@glandium.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">On Mon, Sep 15, 2008 at 11:21:31AM +0200, Ariya Hidayat &lt;<a href="mailto:ariya.hidayat@trolltech.com">ariya.hidayat@trolltech.com</a>&gt; wrote:<br>

&gt;<br>
&gt; &gt; our goal is to change standard malloc to tcmalloc under linux-qt port but<br>
&gt; &gt; we couldn&#39;t solve operator new and delete problems. &nbsp;As we see Paul&#39;s (<br>
&gt; &gt; <a href="https://bugs.webkit.org/show_bug.cgi?id=20422" target="_blank">https://bugs.webkit.org/show_bug.cgi?id=20422</a> ) solution can<br>
&gt; &gt; solve this, therefore if the community accepts this change then we would<br>
&gt; &gt; gladly help to replace all new and delete operators to the new ones.<br>
&gt;<br>
&gt; Because typically we build QtWebKit as a shared library, this raises the<br>
&gt; problem that the overloaded new/delete will be global, i.e. this would also<br>
&gt; affects the application that links QtWebKit, so not only at the library level<br>
&gt; (QtWebKit).<br>
&gt;<br>
&gt; The mentioned patch seems to solve this problem, but at the cost of reduced<br>
&gt; syntax readability because we can&#39;t use the familiar C++ new/delete<br>
&gt; constructs anymore (AFAICS we are not even allowed to use it anymore). I<br>
&gt; wonder whether this is a good compromise, i.e. what justifies it more than<br>
&gt; just providing the new/delete override at the application (I wasn&#39;t involved<br>
&gt; in previous memory management discussions before, so please point out what I<br>
&gt; miss here).<br>
&gt;<br>
&gt; Side note: we found out that the Linux&#39;s standard malloc is good enough,<br>
&gt; enabling the JSC&#39;s (tcmalloc-based) FastMalloc does not add any significant<br>
&gt; speed boost. This is however different on QtWebKit/Win32, where FastMalloc<br>
&gt; improves SunSpider by 30%.<br>
&gt;<br>
&gt; (Of course I might be wrong here, so feel free to provide corrections).<br>
<br>
</div>It might be beneficial on long term use, where memory allocation/deallocation<br>
will have created fragmentation, making the process need a lot of virtual<br>
memory because it can&#39;t fill the holes, making the whole thing be a memory<br>
hog. Tcmalloc has usually less fragmentation.<br>
<font color="#888888"><br>
Mike<br>
</font><div><div></div><div class="Wj3C7c">_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
</div></div></blockquote></div><br></div>