Andreas Junghans wrote:
> Am 01.08.2006 um 20:08 schrieb Erik A. Onnen:
> 
> The problem with IE's garbage collector is that it has a major bug  
> (although Microsoft doesn't call it a bug ;-))  Every time a cycle  
> between DOM nodes (which are COM objects in IE) and JavaScript  
> objects is formed, no object involved in the cycle will ever be  
> garbage collected, not even when the current page is replaced by  
> another one. 

COM seems like a very heavy-handed approach for managing what are
effectively lightweight leaves and branches in a tree on a shared
stack space. I'm surprised this is their implementation.

> This is the one and only reason why dispose code is  
> necessary at all. 

Could there not be browser-specific code in the unload to skip the
mass disposal in FF? It's the Stop Script/Continue dialog that's
killing me atm. Or maybe default as is but provide a configuration
hook if users wanted to bypass it for certain browsers?

> To break such DOM/JavaScript cycles, qooxdoo (and I
> suppose similar frameworks too) remove all references when the page  
> is unloaded (or when a widget is no longer needed). Otherwise, there  
> would be major leaks that would make the browser unusable after some  
> time.

I did some additional google searching after my previous post and
found some authoritative articles on the subject like:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/IETechCol/dnwebgen/ie_leak_patterns.asp

This got me thinking though, is it really necessary to dispose *every*
object. Alternatively, would it be possible to track circular
references (say through property mutators on instances/singletons) and
simply dispose one half of a circular reference thereby freeing the GC
to clean-up the other half without blocking the unload operation? I
also thought you could potentially deal with the closure leakage issue
through the event subsystem detaching listeners on unload. It would
likely be a good bit of work and it's unfortunate that this behavior
by IE requires any attention at all, but the unload performance is a
bear for my current usage patterns and I'll take any improvement I can
get.

> 
> Besides the leak/cycle problem, IE's garbage collector has another  
> ugly deficiency: It gets awfully slow when there are lots of objects  
> on the heap. They don't have to be actively used, they just have to  
> be there (and reachable via reference chains). For example, a simple  
> "for (x in y)" loop can either be fast (when there are only a few  
> objects) or unbearably slow (when there are many objects). Again,  
> these objects don't have to be used in the loop at all to slow it down!

That sounds like heap compaction/fragmentation issues to me. Really an
old problem that I would have expected them to solve by now.

> 
> It seems that there are certain actions which trigger the garbage  
> collector, and since the collection happens in the main thread, it  
> brings the whole application to a halt until it's finished. "for (x  
> in y)" seems to be such a trigger. The wildly different times you  
> observed for deleting vs. nulling out seem to indicate that the  
> delete operator is another trigger, while simple "for (i=0;i<x;i++)"  
> loops don't seem to be affected.
> 
> Maybe it would be worth the effort to find and document all the  
> possible triggers. If they could be avoided (e.g. by caching hash map  
> keys in ordinary arrays to avoid "for (x in y)" loops), qooxdoo's  
> overall performance in IE could be greatly increased.

This could be used in conjunction with what I mentioned above. Keep
one half of a circular reference in a simple array and traverse that
at unload.

P.S. Keep up the good work, I love Qooxdoo!

-erik

> 
> Regards,
> 
>    Andreas
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
> 

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to