GWT Garbage Collection

Question

I am creating a new presenter like so:

new MyPresenter(new MyView());

It registers some event handlers and binds to the view and such. Eventually, I might "close" that view so that it is no longer rendered by the browser. I am not maintaining a reference to this instance of MyPresenter anywhere.

In the Google forums on this topic, the conventional response is to "set your references to null" and then don't worry about it. Unlike in Javascript, I can't just say this = null; in Java for obvious reasons. But in Javascript, it's very easy to null out object references that I know will no longer be used.

My question: How can I tell if this presenter has been garbage collected since I don't maintain a reference to it? It very clearly exists. Should I have faith that GWT and JS will take care of this? Or do I need to maintain my own reference to MyPresenter so that I can manually null it when I'm done with it?

It depends on browser. Basically if you don't have references to the objects, it will be collected, but there bugs, like famous bug in IE with cross references between DOM and JS objects (default components in GWT are usually protected from this), or some garbage collectors were unable to delete object islands. Since there are a lot of browsers, there is no universal trick or tool how to fight this problem. The only choice is to run performance tests, and check the memory usage. — jusio, Apr 23 '12 at 15:51
I don't **ever** have a reference to that object from within my (user) code, however it provably exists because it can handle events if I fire them. However, if I remove these event handlers and null out `MyView` is that sufficient to cause it to be GC'd? My fear is that it is not. — Travis Webb, Apr 23 '12 at 16:04
@TravisWebb it *should be* sufficient. But accidents happens. I can't fit in one comments all the GC related bugs, but they happen from time time. If you remove all the references to the object, it should be collected (adding something as event listener, counts as creating a reference, since some object somewhere have to know where to send events) — jusio, Apr 23 '12 at 16:22
Ok. Actually, the event handler is an anonymous class. Hopefully I can get some more concrete info. — Travis Webb, Apr 23 '12 at 16:56
There's some info about GWT's handling of the browser problems at https://developers.google.com/web-toolkit/articles/dom_events_memory_leaks_and_you — fgb, Apr 23 '12 at 17:05
Worth pointing out that `this = null` isn't going to do a lot in JS either - in FF you get `invalid assignment left-hand side`. And just as you can null out fields in JS, you can do this in Java. GWT compiled java objects end up being prototype-chained js objects, so the same JS gc rules should apply to them. — Colin Alworth, Apr 23 '12 at 17:40

score 2 · Accepted Answer · edited May 23 '17 at 12:12

There are two kinds of memory leaks:

DOM/browser level memory leaks
Application memory leaks.

DOM/browser level memory leaks typically last after you close the app. AFAIK only old browsers (IE6) are affected and that's the reason why GWT uses a special way to attach handlers.
This should be a non issue with modern browsers at least they will be a non-issue if you close the app. They can however become application memory leaks. (See here for more details). But in general modern Javascript GC are pretty good in freeing unused memory.

Application memory leaks might be an issue with long running applications and when you dynamically create a lot of views/presenters and keep reference via Eventhandlers. But here it really depends on the scope of the involved parties.
This post is a good reference with some more infos on that.

Finally to make sure that you really don't have any application memory leaks you should use the Dev Tools Heap Profiler to check the memory consumption over a longer period.
This blog post has some more infos on that.

GWT Garbage Collection

1 Answers1