CEF1: Add method to force V8 GC when idle

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Using CEF Client, load www.microsoft.com (or another site if you prefer)
2. Hit refresh a bunch of times (50+)
3. Monitor cefclient.exe memory usage in task manager

What is the expected output? What do you see instead?

I expect memory to stay relatively steady over time, and for memory to be 
cleaned up (garbage collected) when idle.

Additionally, I expect garbage collection to run when a frame is closed in an 
application containing multiple frames. (not seen using the steps above since 
cefclient.exe only contains a single frame).

What version of the product are you using? On what operating system?

Windows 7, CEF 1 revision 441

Please provide any additional information below.

I expect memory to stay relatively constant under the assumption that 
javascript garbage collection will kick in occasionally.  When I load 
www.microsoft.com and reload a bunch of times (~50), the memory continually 
rises from about 50 mb to about 100 mb and higher.  I notice that on some of 
the refreshes garbage collection cleans up a little bit, but it doesn't collect 
everything.  Additionally, there does not appear to be any garbage collection 
running on idle detection.

For testing purposes, I exposed a method ForceGarbageCollection() in 
CefBrowser, which just calls into v8::IdleNotification() in a loop until it 
indicates there is nothing left to collect.  I also added a menu option in 
CefClient to allow me to call into this method and force garbage collection on 
demand.  I've included a patch with these changes.  I found the 
ForceGarbageCollection() function on CefBrowser to be useful when testing the 
host application, so I wouldn't mind seeing this type of functionality added to 
CEF (similar to the "Purge memory" button in Chrome's Task Manager).

Using the patch, I was able to observe the following memory usage for 
cefclient.exe:

100 mb - Load www.aol.com first time, refresh about 50 times
 82 mb - After forced garbage collection
100 mb - After 15 refreshes
 85 mb - After forced garbage collection

For a single browser frame like in cefclient the 15-20 mb difference isn't a 
big deal, but for an application that hosts multiple browser frames, it adds up 
pretty quickly.  I noticed that chrome implements idle detection to do further 
garbage collection (see render_thread_impl.cc in chrome).  If you follow the 
same steps above in chrome and use the chrome task manager to view the memory 
for the tab, you can click on a different tab and see that it purges a good 
chunk of memory.  Additionally, the memory usage of the tab in chrome 
stabilizes after less than 10 refreshes.  In CEF, I've only seen GC kick in 
when a page is loading.  After a page has been loaded, there is no further 
cleanup when idle, even if I close a frame.  I noticed CEF 3 also includes 
render_thread_impl.cc from chrome, so this might only be an issue in CEF 1.

Original issue reported on code.google.com by avivr...@gmail.com on 14 May 2012 at 11:29

Attachments:

• cef_patch.txt

[GoogleCodeExporter]

Original comment by magreenb...@gmail.com on 3 Oct 2012 at 5:59

• Changed title: CEF1: Add method to force V8 GC when idle
• Changed state: Accepted
• Added labels: CEF1, NextRelease

[GoogleCodeExporter]

Why wasn't this fixed in the last release? Was it problematic? Seems
like there will never be a complete solution for CEF 1 memory problems,
as Chromium was never intented for single process architecture?

Original comment by czarek.t...@gmail.com on 17 May 2013 at 6:26

[GoogleCodeExporter]

@comment#2: May be you interested in this issue 
https://code.google.com/p/chromiumembedded/issues/detail?id=960 . It is also 
applied to CEF1.

Original comment by fdd...@gmail.com on 17 May 2013 at 8:29

[GoogleCodeExporter]

@comment#2: I spent some time testing various iteration counts for 
v8::V8::IdleNotification(). In my testing I was unable to identify a 
useful/consistent balance between performance (IdleNotification takes time to 
run) and memory reduction. Unless we can provide good guidance on usage I think 
there's a high probability of this function being used incorrectly.

Original comment by magreenb...@gmail.com on 17 May 2013 at 8:39

• Removed labels: NextRelease

[GoogleCodeExporter]

CEF1 has entered bug-fix-only maintenance mode. See 
http://magpcss.org/ceforum/viewtopic.php?f=10&t=10647 for details. If this 
issue applies to the current version of CEF3 please create a new issue.

Original comment by magreenb...@gmail.com on 11 Oct 2013 at 2:03

• Changed state: WontFix