[webkit-dev] Regarding cache memory leaks

Wed Oct 20 05:56:40 PDT 2010

 Hi Holger,

Thank you for your valuable suggestions. We have tried the 2 solutions which you have proposed:

Verify that you are not leaking memory. Create a sample page, reload it in a loop, repaint it and see what happens to your memory.. 

We have tested with attached sample page(memtest.html) by reloading with Webkit default cache model ( WEBKIT_CACHE_MODEL_WEB_BROWSER ) then we observed no memory leaks. When we set the webkit cache model to WEBKIT_CACHE_MODEL_DOCUMENT_VIEWER then observed leak for every reload. ( the leak is image size equivalent for every reload )

Ask the VM to overcommit the memory, and see how far you can push things...

We are using 2.6.22.19-19 so we are unable to set the overcommit flag from /proc file system.
$echo 2 > /proc/sys/vm/overcommit_memory (strict overcommit) -- When we set like this, the browser is crashing.

As per previous comments from Webkit-dev mailing list, we understood that the cache limit is only applied for other than current page. In that case, how can we set cache limit for current page.

We have also tried with the below mentioned approach and observed some memory regain:

Opened the attached Picasa sample html page and running in slideshow mode.

Displayed almost 100 random images, which consumed almost 80% of RAM.
At this condition, we redirected to another web page (google.com). Due to this RAM free memory is regained approximately 10MB, but not the entire consumed memory used by previous loaded page (i.e. Picasa page)
After this, we dropped the kernel cache by using below command and observed around 4MB memory gain.
$echo 3 > /proc/sys/vm/drop_caches
Could you please suggest is there any way to strictly limit the cache size for current page. Even though when we call removeLRUList, pruneLiveResources() the cachedResource references are not freeing. How can we properly remove these cachedResource references.

Thanks,
Suman

-----Original Message-----
From: Holger Freyther <zecke at selfish.org>
To: sumanrapolu <sumanrapolu at aim.com>
Cc: webkit-dev <webkit-dev at lists.webkit.org>
Sent: Tue, 19 Oct 2010 12:48 am
Subject: Re: Regarding cache memory leaks

On 10/18/2010 02:55 PM, sumanrapolu at aim.com wrote:

> Hi Holger,

Hi,

(please keep the mailinglist in the loop)

> We have applied the

> patch(https://bug-44806-attachments.webkit.org/attachment.cgi?id=68154) to

> remove the "deadResources", which is working fine. Because of this patch the

> duration to consume the entire available RAM has increased. But still the

> "liveResources" are not freeing, due to which its again consuming the entire

> available RAM. 

my time is limited right now so I can not help you in my spare time. But if

the encoded data of the current page is more than fits into your RAM there is

not much you can do, you can either wait to get killed by the kernel, or you

can stop loading the page. Just imagine you would throw away images you have

already downloaded, you would need to download them again.. in most cases

where you have limited RAM you also have limited bandwidth...

The two things that I can propose are:

	a) verify thay you are not leaking memory. Create a simple page, reload it in

a loop, repaint it and see what happens to your memory...

	b) ask the Linux VM to overcommit memory and see how far you can push things.

I just can't commit more of my spare time to look into memory usage of

WebCore, I wish I could spend more time on WebKit...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20101020/a9471086/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PicasaNew_redirect.tar
Type: application/x-tar
Size: 20480 bytes
Desc: not available
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20101020/a9471086/attachment.tar>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20101020/a9471086/attachment-0001.html>