Thursday, December 27, 2007

GWT's solution to the JavaScript dynamic memory leak problem.

Any experienced AJAX developer should have seen this: You wrote a web application with a lot of JavaScript logic for the front end. It looks beautiful, it runs fast, it passes all feature tests. But there's one problem: it occupies more and more memory as it runs.

There's no way you can prevent it in Firefox, due to memory fragmentation at the very least (technically that is not memory leak, but that makes no difference to users), caches, and possible memory mismanagement by plugins. But memory leaks in IE are preventable, and it was one of the major topics for my FYP - WT Toolkit. The idea is trying to solve the memory leak problem as far as possible, and leave it to the browser developers (Firefox/Gecko, that is) if it isn't possible to solve in JavaScript.

WT Toolkit's approach is straightforward - since memory leaks in IE are usually made from circular references between DOM nodes and JavaScript objects (including functions), we try to eliminate the need to reference to any DOM nodes in JavaScript programming. It's simple in theory, but difficult to implement in practice.

Now I've graduated from college, but I'm facing the same problem in another project - FCKeditor. More precisely, I'm facing the problem in FCKeditor's floating dialog branch. Tools like Drip or sIEve, while excellent, can only help a bit in detecting JavaScript memory leaks - it is entirely possible that both of them do not detect any memory leaks but your application still contains dynamic leaks (i.e. increasing memory usage BEFORE page refresh), and I've talked about that in my FYP report.

So now I'm having to do the same research all over again. But this time the problem is harder - for WT Toolkit, I could simply look over the existing literature about the nature of the IE memory leaks, build the toolkit in a way that it can be mathematically proved that it cannot leak under certain circumstances (the "circumstances" here have to be flexible enough to make the toolkit practical, of course), and only develop web applications under the allowed circumstances. FCKeditor, on the other hand, does not have a toolkit built with such provisions.

Right... So I have to read the literature on JavaScript memory leaks all over again, and code again, how wonderful. While reading the literatures I found a piece of gem on this topic from the Google Web Toolkit team:

It discusses Google's solution to the very same problem that I tried to solve in WT Toolkit. It's not ideal, but it's simpler than WT Toolkit's approach. The only thing that it assumes is that the web developer won't call element.removeChild(widget) and won't make his own reference cycles in JavaScript - not a big problem for GWT since the web developer is supposed to write in Java.


Jesse Bethke said...

Thanks Martin, excellent insight.

Anonymous said...

Can anyone recommend the best Software Deployment software for a small IT service company like mine? Does anyone use or How do they compare to these guys I found recently: N-able N-central remote desktop
? What is your best take in cost vs performance among those three? I need a good advice please... Thanks in advance!