Memory leak on new() and destroy() widget

[guest]

Just create a widget,and then destroy it.This will causes memory leak. I use procexp.exehttp://www.microsoft.com/technet/sysinternals/utilities/processexplorer.mspx to monitor the memory usage,and it's increasing. My OS is Windows XP and this memory leak occur in IE6 and IE7 both.

[guest]

test page.

[guest]

the widget written for test.

[bill]

Note: related to #4641 but this is failing on a trivial widget, so easier test case then using Menu. I'll try to address for 1.1.

[peller]

while it's entirely possible we have a memory leak here, I'm not sure increasing process size proves it. There's GC running and caches, so it's not always obvious. Does this growth continue linearly?

[guest]

memory usage graph(by procexp.exe)

[guest]

yeah,the memory usage is ebb and flow,but it's increasing obviously.I upload two memory usage graphs.One is near 5 minutes after IE browser running,and the other is near 10 minutes.The memory is 20M first,and it's 24M 5 minutes later,and 30M 10 minutes later.

[doughays]

can this be moved back into 1.1?

[peller]

I think it's out of 1.1 unless there's a patch to look at. Perhaps we can consider for 1.1.1 also with a patch.

[bill]

graph from sIeve

[bill]

Yup, I see the memory increasing, although sIeve says there are no DOM leaks... I guess it's a different sort of problem.

[haysmark]

Test demonstrating IE hash bug, which causes IE to fail to release the memory even on delete and CollectGarbage?().

[haysmark]

Result of running IE hash bug test in sieve.

[haysmark]

It's not a Dojo bug; it's an IE bug with deleting from hashes.

I've attached a very simple test with zero Dojo demonstrating this bug. Basically, delete from a hash does not clear the memory in IE. Even calling CollectGarbage?() after the delete does not clean it up! This bug affects many key Dojo and Dijit components, like dojo.connect and dijit.registry (dijit/manager.js), since they keep a hash for things like widget id.

For example, dijit/manager.js has some bugged code:

remove: function(/*String*/ id){
	delete this._hash[id];
},

Just creating and destroying dijit._Widget 500 times will increase the memory footprint by .5MB! The graph:

Fortunately I've found the workaround:

1. Make a new hash.
2. Mixin the old hash's contents.
3. Delete the old hash.
4. Replace the reference to the old hash with the new hash.
5. CollectGarbage?()

For instance, in dijit/manager.js:

remove: function(/*String*/ id){
	delete this._hash[id];
	// IE seems to leave remnants of the reference anyway in memory
	// need to delete the entire hash to clean up
	var newhash={};
	dojo.mixin(newhash,this._hash);
	delete this._hash;
	this._hash=newhash;
	if(dojo.isIE){
		// invoke the GC for best results
		CollectGarbage();
	}
},

This code creates a drastic improvement in memory footprint for plain _Widgets! Of course more complicated widgets, like Menu, will still eat up a lot of memory. My guess is that dojo.connects are also failing to be cleared from memory, whether they are hashing/being hashed, or are just using plain arrays. Basically, wherever we delete/splice/whathaveyou something from a hash/array, we have to paste in this workaround to keep memory down.

[bill]

Interesting (and depressing), particularly that this occurs on IE7 too.

I think recreating a hash every time an element is added would be unacceptable because of the CPU cost (and also btw I'm surprised it doesn't leak more memory than the current code). I suppose we could have some kind of Hash class that recreated the hash every 100 inserts or so... it's a pretty radical change though.

In any case it's good to know what's going on.