GWT applications memory management

[Lex]

Hello all.

I'd like to ask the question about the approaches normally used to
manage memory in GWT applications. Till the moment I wrote this post,
I read most of discussions on the group related to this topik, but
unfortunately have no answer on my question.

What I'm actually looking for: is some guide or list of rules "What is
necessary to be done in GWT code, to prevent GWT application to
consume more and more memory". This problem occurs in Internet
Explorer.

Currently we are developing rather big application using GWT. During
developement process we had noticed that Internet Explorer consumes
memory more and more and never release it. We had also noticed that
after we press refresh button in IE, it finally releases most of
consumed memory (but not all). We try to check out pages with IE leak
detectors, sIEve, and Microsoft JS Memory Leak Detector. Those tools
are not detect any memory leaks in our application.

After this we create very simple test. We create SimplePanelwidget,
and put some FlexTable on it. After this we put in this flex table
different widgets (Buttons, checkboxes, etc.). After we add
SimplePanel to the rootPanel, and remove it from root panel. Do this
several times (using timer). After each cycle (add, remove SimplePanel
from RootPanel) some amount of memory ~200 KB is not released.

So my questions are following:
- Does the situation when IE is not released all memory it consumes
is know issue or not?
- Does anybody know what may be done to reduce or remove at all
memory leaking?
- Does anybody have URL to some guides of memory management in GWT
applications?

Any help will be highly appreciated

[Bob Stachel]

Try this article as a starting point in understanding IE memory leaks.
Internet Explorer is far worse than other browsers in memory
managment.

http://msdn.microsoft.com/en-us/library/bb250448.aspx

If your application uses "pure" GWT you will be somewhat protected
from leaks, but perhaps you have some native methods that employ
function closures (by far the easiest way to incur major leaks).

[Lex]

Hello Bob,
Thanks for answer, I'll check the article on Microsoft.

Considering the natives, we have prepared test application, where we
exclude all natives, DOM class method calls, and even eventListeners.
Sometimes browser frees some memory, but not all (after memory
release, total browser's memory allocation is greater then before
allocation).

So the problem seems still exists.

[buz...@gmail.com]

Hello Alexey,

Unfortunately this is a typical situation in large GWT application
which uses a lot of custom Widgets and DOM/native code.

We have found no tooling which would efficiently show us the exact
places of memory leaks and the only approach left is to cut you
application into two halves and see how the memory behaves.

We have succeeded in reducing the memory leak by carefully analyzing
the code and unlinking custom event listeners and object hierarchies
by overriding onUnload() methods of custom widgets. Splitting your
application into several and providing hard navigation by changing
window.url from time to time, instead of relying on GWT History
mechanism also helps.

Memory leak situation is a lot better in Firefox and Opera, but Chrome
went further by providing separate memory space for each tab, thus it
guarantees that if you close the tab everything is "garbage
collected", because process is killed. I guess Google took the only
right way to solve the problem :)

I hope it will help you to deal with your problems.

Dmitry

[Lex]

Hello Dmitry,

We are also thinking about splitting application into several. So now
we will try this approach starting with creation some "proof of
concept" demo application.
Thanks a lot for your explanation.

> > Any help will be highly appreciated- Hide quoted text -
>
> - Show quoted text -

[Arthur Kalmenson]

As others have mentioned, this is pretty specific to IE (especially in
IE 6). I'm not sure how much you can really do about it aside from
what others have mentioned here. You can recommend for users to use a
better browser, but I know that a lot of the time this is not
possible.

--
Arthur Kalmenson

[Adligo]

Hi All,

I have been writing GWT assuming that it did garbage collection
similar to the way that java does, or in other words it looks for
Objects (chunks of memory) which don't have any active references
pointing to them and removes those from the heap via the garbage
collector. Is this general assumption correct?


Cheers,
Scott

[Arthur Kalmenson]

Your assumption is pretty much correct. The problem is memory
management in Javascript is very dependent on the browser's
implementation. However, in most cases I don't think it's as efficient
as Java's memory management. Unfortunately, you can't really do much
about this since it's a browser issue.

--
Arthur Kalmenson

[Алексей Циунчик]

  Hello Scott

It seems your statement is not correct in general. First of all, garbage collection for UI part (Javascript) is provided by Web Browser, and it is highly depends on web browser internal implementation.

We've spend more then 2 weeks for internal testing, and have following results

The worse case in Internet Explorer 6 and 7. The problem is that IE uses not mark-and-sweep algorithm, but the count references to the objects so in case of cyclic references A->B->A IE does not release memory. See hyperlink provided by Bob Stachel  few posts before.

Things goes better in FireFox (we test on 3.x).

The best one is Google Chrome (unfortunately our customer refuse it, he prefers IE).

Except this you should pay attention to native functions, DOM manipulation, event listeners especially when you set your listener to objects like Window, and not release them when widget detached (in our case we found few place when this problem occurs, after code inspection).

Ex:

   /**

     * Initialize the handlers.

     */

    private void initHandlers() {

        Window.addWindowResizeListener(new WindowResizeListener() {

            public void onWindowResized(int x, int y) {

                recalculateHeaderWidth();

            }

        });

    }

In this case outer class will be never released since Window class will have reference to it's inner class, and inner class reference to outer class.

2009/1/17 Adligo <sc...@adligo.com>