GWT Garbage collector.

[Luciano Broussal]

Hi all,

Suppose i have a variable set with a GWT Widget.
this variable is added into a GWT containe => the widget is added to
a parent container.

The question is. If i remove the widget from the parent and set the
variable to null, Does the Js or GWT collector frees in the right way
the resources ?

If it is not the case? What is the best practice ?

Best Regards.

Luciano
--
http://www.gwtwindowmanager.org

[David Evans]

A quick Google Book Search for "javascript garbage collection" comes
up with very vague info on Garbage Collection the most detailed of
which (at best) says "Just ignore it" but suggests that hinting by
setting variables to null is sufficient.

Now I'm bothered. A few webpages seem to suggest that (big surprise)
IE leaks with closures. No one has a great solution other than to "be
careful" so I assume that also means set things to null.

On Feb 20, 7:00 am, "Luciano Broussal" <luciano.brous...@gmail.com>
wrote:

[Luciano Broussal]

Thank you David,

It is a precious and important response for me.

Luciano

[Dan Morrill]

Ahhhh, the garbage collector.  Let's start with some quick answers:

First, the general answer:  unless you are doing some rather low-level things in JSNI that you probably ought not to be doing (such as registering your own event handlers) then GWT will handle all this automatically.  That is, GWT tracks all the JavaScript references and makes sure your app manages objects in such a way to avoid having the GC leak them.

To Luciano's point:  if you are working purely in GWT/Java code, you should be totally safe.  Even if you are working in JSNI (which I believe is not the case here) then nulling out the references as you describe should work, too.

To David's point, which addresses the more general GC question:  yeah, it's gross, but GWT handles it.  More detail follows, if you're interested....


It is definitely true that the conventional wisdom tells you to "just ignore it" and not worry about it.  Unfortunately that just doesn't work, and most JavaScript apps leak memory incredibly badly as a result.  Also, as near as we have been able to tell, every browser out there leaks, one way or another.

The key issue with the GC is this:  in all browsers we have tested, a circular reference between a native object and a JavaScript object will prevent both from being GCed.  The reason is that the JavaScript VM has no visibility into the native code, which is usually C or C++.  As a result, the JS garbage collector essentially just punts and says "I can't figure out what to do so I'll just wait and hope that link gets broken.  Then I'll handle it later."

The problem is, native objects include pretty much anything useful to work with.  They include native widgets (buttons, list-boxes, and other UI elements) as well as DOM objects.  So, if you build an AJAX app that is at all useful, the GC will ignore your objects unless you are very careful.

Of course, the solution is "easy" -- just break the circular references and the GC works fine.  Actually putting this "easy" fix into practice requires extraordinary developer discipline, but fortunately GWT does it automatically.  As long as you use GWT's widget library and don't do anything intrusive in JSNI, GWT will break such circular references for you, during the un-attach handling.

- Dan Morrill

[Luciano Broussal]

Thank you Dan for this accurate response.
I hope to play with the GWT 1.4 soon.

Regards

Luciano
---
http://www.gwtwindowmanager.org

[Ian Petersen]

> The key issue with the GC is this: in all browsers we have tested, a
> circular reference between a native object and a JavaScript object will
> prevent both from being GCed. The reason is that the JavaScript VM has no
> visibility into the native code, which is usually C or C++. As a result,
> the JS garbage collector essentially just punts and says "I can't figure out
> what to do so I'll just wait and hope that link gets broken. Then I'll
> handle it later."
>
> The problem is, native objects include pretty much anything useful to work
> with. They include native widgets (buttons, list-boxes, and other UI
> elements) as well as DOM objects. So, if you build an AJAX app that is at
> all useful, the GC will ignore your objects unless you are very careful.

I just wanted to chime in here with some of my own experience. In the
case of the Mozilla browsers, the problem is that DOM objects are
"garbage collected" by reference counting, rather than a real garbage
collector. As with all reference-counting implementations, this one
breaks when it encounters a cycle. (The Mozilla DOM code may include
some kind of cycle breaking logic--I'm not sure--but if such logic
exists, it doesn't--or didn't--bridge the DOM-Javascript divide.)

The Javascript garbage collector is of the mark-and-sweep variety, I
think, so it will handle cycles, but, as Dan pointed out, when the
Javascript engine and the DOM interact, the solution is to punt. This
usually rears its head when you have an event listener that closes
over the DOM node that it's attached to because you end up with a
Javascript object (the listener) that references a DOM node (the
listened-to) which refers back to the Javascript object (the
listener).

You can look at this Mozilla bug for some more detail:
https://bugzilla.mozilla.org/show_bug.cgi?id=241518

Ian

--
Tired of pop-ups, security holes, and spyware?
Try Firefox: http://www.getfirefox.com