Memory Leak when running GWT in an IFrame.
stuckagain
The Portlet Engine is written in GWT and the Portlet applications are
also written in GWT.
Every portlet is displayed in an IFrame. These IFrames can be
positioned by the user, new portlets can be added or removed (that
part is still under construction).
I've also implemented a communication mechanism so that the Portlet
applications can signal events to the Portlet Engines and also the
other way around (providing events for open/close/focus/blur/
notification/titles/menu system/... etc).
The problem I am now facing is that every time I open an IFrame with a
GWT application and close it afterwards, multiple megabytes of memory
are not released. After some time the IE process is consuming hundreds
of megabytes and everything starts working really slowly and finally
crashing the browser.
I first investigated my own code to see if I did not cause any memory
leaks in the portlet/engine communication JSNI code and managed to fix
a few issues there. But I still have big memory leaks.
I created a simple GWT test application, that adds/removes an IFrame
in a loop. There are 2 buttons, one shows a GWT application with label
and textfield and another button shows the same thing but in HTML (so
no fancy javascript there).
If I use the HTML IFrame, then I see that the memory consumption of IE
remains constant. When I use the GWT IFrame approach I see it growing
100-200KB per iteration.
Could it be possible that the leak happen because the event handlers
are never removed from the DOM tree in the GWT application ? Could I
maybe do something to "stop" a running GWT application so that it can
cleanup correctly ?
Emily Crutcher
"There are only 10 types of people in the world: Those who understand binary, and those who don't"
stuckagain
OK, I copied my post in a Bug report:
http://code.google.com/p/google-web-toolkit/issues/detail?id=1821
If you need more info let me know.
David
On Oct 30, 3:42 pm, "Emily Crutcher" <e...@google.com> wrote:
> Can you put a bug report in our issue tracker with your small GWT app and
> send the bug number out? We take memory leaks very seriously so I'd love to
> figure out what is going on...
>
> binary, and those who don't"- Hide quoted text -
>
> - Show quoted text -
Bruce Johnson
stuckagain
Take a look at the example code that I put in the comment in the bug
report. The entry page is index.html, which will show 2 buttons. If
you click on one of the buttons it will create and destroy an IFrame
in a small loop (just to exaggerate the memory leak a bit). One button
will do the loop with an extremely simple GWT application and the
other button with an even simpler HTML page. So there is no JSNI code
in play here (any GWT application will do).
When I use the GWT test it leaks 100-200K per click. When I use the
HTML test it does not. Since the JavaScript in the index.html is
shared that kinda proofs that the JavaScript in index.html itself is
not leaking (which it initially did when I did not clear the event
handler after removing the DIV block). I guess that maybe that also
gives a small indication of what the cause might be: you need to
remove event handlers when you remove a DOM element from a document
(as far as I can see the GWT widgets never do this...or maybe I did
not look deep enough).
David
On Oct 30, 5:14 pm, "Bruce Johnson" <br...@google.com> wrote:
> Hi David,
> Are you using any JSNI code? Handwritten JSNI is the easiest way to
> accidentally cause leaks.
>
> -- Bruce
>
Joel Webber
stuckagain
You probably missed my example I added in later notes.
There I show the same bug WITHOUT hand-written javascript but purely
using GWT and without custom JSNI and that shows the leak.
I know my original Javascript was not great, but that happens when you
start using GWT, your Javascript skills go downhill very quickly.
David
On Nov 21, 3:32 pm, "Joel Webber" <j...@google.com> wrote:
> This issue appears to be entirely related to a reference cycle in the HTML
> page's hand-written javascript. I've commented as such on the issue.
> If I've missed anything that could actually be a GWT bug, please let me
> know.
>
> joel.
>
stuckagain
looking at the solution instead of the problem. Just remove the
proposed solution from the attached testcode and watch IE leak like
hell... all this just with GWT classes.