Welcome Guest Search | Active Topics | Sign In | Register

Browser Memory Management Options
Kyrian Willis
Posted: Wednesday, May 25, 2016 4:33:07 PM
Rank: Newbie
Groups: Member

Joined: 4/4/2016
Posts: 5
I have a web app being hosted inside of an EO Browser control. Unfortunately the web app has a memory leak. My team is working on tracking down this leak but we need an immediate solution/work around. One proposed solution was after a certain amount of time the EO Browser control could be destroyed, recreated, and the page reloaded.

My question is would destroying the instance of the control release the memory? If this were a tab in a browser the memory might still not get released if the tab were closed.

thanks
eo_support
Posted: Wednesday, May 25, 2016 4:41:21 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,203
Hi,

If you only have a single WebView in your application then destroying that WebView will release all memory. If you have multiple WebViews, then the safest way is to restart the Engine object, even though most of the time destroying the WebView will release all the memory, but it is not guaranteed in this case since the engine can house several WebViews inside a single process and a large portion of the memory is managed by the garbage collector, which does not necessary release the memory right away after the object that uses the memory is destroyed.

Thanks!
Kyrian Willis
Posted: Wednesday, May 25, 2016 4:47:45 PM
Rank: Newbie
Groups: Member

Joined: 4/4/2016
Posts: 5
There are multiple webviews involved but reloading the other ones would be more of a challenge because they would interrupt the users. Is there a single garbage collector managing all of the webviews? Does it separate out the memory from one WebView to another?

I'm hoping restarting the one WebView will be enough but if the memory is all heaped together and my app is leaking it I don't think just reloading a single WebView would fix it. It seems the GC would still not be able to detect the memory should be deallocated. But if the memory management is segregated by WebView and the instance was disposed then it seems like a better bet.

Any thoughts on this?
eo_support
Posted: Wednesday, May 25, 2016 5:07:32 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,203
Hi,

Restarting one WebView should be sufficient most of the time and it may be good enough for practical purpose. The reason that we say that it can not be guaranteed is because of the GC's non-deterministic nature by design and we do not have control over that. In practice, even though GC is non-deterministic, the objects that lives in the GC heap are primarily DOM tree related objects and JavaScript object. Both will be completely destroyed when the WebView is destroyed. This hopefully will trigger GC pretty soon to reclaim the memory.

Even if GC does not kick in right away, destroying the WebView may be sufficient enough if there are no other WebView in the same Engine that loads pages from the same domain. By default, render process (which houses the DOM tree and JavaScript engine) are isolated by domains. So if you have two WebViews, one loading page from www.site1.com and the other from www.site2.com, then each WebView will have their own rendering process and destroying the WebView will destroy the corresponding render process thus freeing up everything. This provides a process level guarantee since terminating the process will free up everything.

If you must have the process level guarantee but still want to have multiple WebViews, then you can consider creating multiple Engine objects and creating only one WebView for each Engine object. Each Engine object is completely isolated --- including cookies and cache, so it may not be what you wanted.

Hope this gives you some insight and helps you making the right choice for your application. Please feel free to let us know if you still have questions.

Thanks!
Kyrian Willis
Posted: Wednesday, May 25, 2016 8:36:15 PM
Rank: Newbie
Groups: Member

Joined: 4/4/2016
Posts: 5
that's very helpful. The pages all come from the same domain so it sounds like a separate Engine object is the way to go. Thanks for the quick response and the thorough explanation.
eo_support
Posted: Friday, May 27, 2016 11:51:03 AM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,203
You are very welcome. Please feel free to let us know if there is anything else.


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.