Andreas Junghans schrieb:
> Am 01.08.2006 um 21:44 schrieb Erik A. Onnen:
>
>> Andreas Junghans wrote:
>>> 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?
>
> In the past, Firefox had some leak problems too, but I think they're
> mostly sorted out. Maybe it would really make sense to call the
> dispose code in IE only. The way it's handled now, it's a bit of a
> safety net in case other browsers have similar problems.
Mhh, have you any reference that tell us that? Firefox has many dramatic
memory leaks. The most ones are internally (also through extensions and
so on). But there are also some others. One main problem in Firefox
(tested for 1.0) was that objects which refers to objects which refers
to objects... are problematic. As this is also problematic in IE and not
just pure DOM-JS bindings as thought the most time, our disposer also
disconnect these connections.
>
> If you want to bypass the dispose on unload yourself, you should be
> able to do it this way:
>
> qx.core.Object.dispose = function() {};
Please test this and tell us if you found out any existing leaks in
Firefox then.
>
> (In a script block in your HTML page after the qooxdoo script tags.)
> You can surround this by a browser switch to still handle IE correctly.
>
>>> 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.
Yes, and this seems to be also true for Firefox in many cases - as
mentioned already above. It would be interesting to get more exact
patterns to reduce the dispose code the less possible content. Currently
we just disconnect all objects, all events, all dom noddes, ...
>>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.
>
> Maybe this would work. The problem is that it's quite easy to
> accidentally create cycles. A first step could be to not blindly null
> out everything but let the individual widgets decide what to get rid
> of. More manual work, but more efficient. However, I'm not sure how
> much faster it would be - maybe the gain is not worth it.
It's currently done this way. The only exception is for the properties.
But I think it's a good place to do this in Object/QxObject as currently.
>
>>> 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.
>
> This wouldn't cover the case of dynamically created and destroyed
> widgets. Over time, the leaks would grow until the application would
> become unusable. By sticking to a strict dispose concept, such
> applications can run for a long time without requiring a reload or
> browser restart.
Please remember however that "dispose" isn't a memory management tool.
To just dispose doesn't free up memory. This means that long-running
application could be problematic (these applications generally creates
even more objects while running: events, io-stuff, tooltips, ...). Just
dispose them, doesn't free up memory. So it will increase over the
runtime of the application. This is just normal I think.
Sebastian
>
> 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
