Hi Paul,
Microsoft memory leak detector tool v2 which you mentioned, the download
link does not work any more. Do you know if the same tool or a later
version(which can work for newer IE versions like IE11, IE10) available
elsewhere? Will really appreciate your help as my team struggles with IE
memory leak issues with our GWT app today.
Thanks & regards
Niranjan
On Sunday, November 7, 2010 at 1:40:09 PM UTC+5:30, Paul McLachlan wrote:
>
> I’d like to chronicle my experiences fixing a memory leak in our
> enterprise GWT application when running on Internet Explorer.
>
> A few facts getting started:
>
> 1. Using a click-recording tool, QA could get our application to
> leak hundreds of megabytes of memory in Internet Explorer.
> 2. No leak measured using Java memory analysis tools in hosted mode.
> 3. Non-trivial application - we have over 100K SLOC just for GWT
> (ie, not counting server side or any non .java files)
>
> Reproducibility was handled by QA, but the first problem was working
> out what was going on. We didn't see these kinds of problems with
> Firefox & this strongly implies some kind of Internet Explorer
> circular reference strangeness between DOM elements and javascript.
>
> We spent some time playing with Drip and sIEve, but we were advised
> not to use these tools (misleading output) and didn't have wonderful
> success with them in any case.
>
> A bit more googling found a javascript memory leak analyzer from
> Microsoft at:
> http://blogs.msdn.com/b/gpde/archive/2009/08/03/javascript-memory-leak-detector-v2.aspx
>
> . That's actually the v2 and most google hits send you to a (now
> removed v1), so it's a little difficult to find.
>
> In any case, the results of using Microsoft's javascript memory leak
> detector are basically unintelligible in a regular production mode GWT
> compile. I had more luck when compiling with -style PRETTY
> (obviously), and I also turned on -draftCompile. I think I remember
> that -draftCompile did less inlining, which made the generated
> javascript closer to our Java code. This was important because the
> output of the tool is basically a series of leaks, like:
>
> DIV leaked due to onclick from stack XYZ
>
> where "XYZ" is a javascript stack trace of where the onclick event
> handler was set. By clicking back up the stack you can generally get
> a reasonable idea of which widget in your application is causing the
> problem.
>
> At this point, I didn't actually trust the tool - so from a
> methodology perspective my first step was to validate the tools
> output.
>
> I commented out code and otherwise configured our application down to
> a bare-bones "login, display a couple of things, logout" script that I
> could run in a loop. Having done so, I could demonstrate that:
>
> a) that operational loop actually leaked in IE
> b) the tool reported about 15 elements as being leaked
>
> Then, I proceeded to ... try to "fix" those leaks.
>
> First attempt was to click the ClickListener (or ClickHandler or
> KeyPressHandler or whatever). I mean, calling Handler.remove(), or
> removeClickListener() during onDetach(). My theory was that my
> ClickHandler was a Java inner class and it somehow just had an inline
> reference to the parent object and etc.
>
> No joy. The tool still reported it as a leak. I've since spent a lot
> more time going through GWT's implementation of event handling and
> it's pretty clear that:
>
> a) the intent is to not have to do this; and
> b) it doesn't set element.onclick = null
>
> I understand the argument with b) is that you don't have to. I wasn't
> feeling very trusting at this point (I had a memory leak tool from
> Microsoft that seemed to disagree with that), so I thought I'd test
> it.
>
> Reading http://javascript.crockford.com/memory/leak.html gave me an
> idea, so I wrote a little helper method:
>
> public native static void purgeEventHooks( Element elem, boolean
> recurse ) /*-{
> try {
> elem.onclick = null;
> elem.ondblclick = null;
> elem.onmousedown = null;
> elem.onmouseup = null;
> elem.onmouseover = null;
> elem.onmouseout = null;
> elem.onmousemove = null;
> elem.onkeydown = null;
> elem.onkeypress = null;
> elem.onkeyup = null;
> elem.onchange = null;
> elem.onfocus = null;
> elem.onblur = null;
> elem.onlosecapture = null;
> elem.onscroll = null;
> elem.onload = null;
> elem.onerror = null;
> elem.onmousewheel = null;
> elem.oncontextmenu = null;
> elem.onpaste = null;
>
> if (recurse) {
> var a = elem.childNodes;
> if (a) {
> l = a.length;
> for (i = 0; i < l; i += 1) {
> purgeEventHooks(elem.childNodes[i], recurse);
> }
> }
> }
> } catch( e ) {
> // ignore
> }
> }-*/;
>
>
>
