Yahoo! UI AJAX IE memory leak workaround and justification

[petermichaux]

Hi,

Reading the Yahoo! UI AJAX library, there is a unique workaround for an
apparent IE 6 memory leak with binding a function to
onreadystatechange. Instead of binding a function to
onreadystatechange, the library polls the readystate of the request
object until it becomes 4. Then it calls the handler function. This
polling seems like a lot of work but maybe is a good approach? If bad
then what is better? Another person asked about this on the Yahoo! UI
mailing list. I am interested what some more experienced folks think
about the workaround justification from the author of the library.

<quote author="Thomas Sha"
url="http://tech.groups.yahoo.com/group/ydn-javascript/message/973">
In IE, JavaScript is managed by a "mark and sweep" collector, while
DOM/ActiveX is managed by reference counting. With onreadystatechange,
a closure is created which references the XHR object (e.g., XHR.event
-> closure -> callback -> XHR), hence they are pointing to each other.
IE fails to reclaim the allocated memory even though both the
JavaScript object and the DOM/ActiveX object are "dead".

The traditional fix for IE has been to point onreadystatechange to an
empty, stub function when the transaction is completed; you cannot
explicitly detach this event handler with "null" in IE < 7. I'm not
fully convinced this works.

The polling mechanism avoids explicitly binding onreadystatechange, and
instead looks at the readystate of the transaction. It is an
unorthodox attempt to avoid memory leaks in IE through the event
handler.
</quote>

Thanks,
Peter

 

[Richard Cornford]

Hi,

Reading the Yahoo! UI AJAX library, there is a unique
workaround for an apparent IE 6 memory leak with binding
a function to onreadystatechange. Instead of binding a
function to onreadystatechange, the library polls the
readystate of the request object until it becomes 4.
Then it calls the handler function. This polling seems
like a lot of work but maybe is a good approach? If bad
then what is better? Another person asked about this on
the Yahoo! UI mailing list. I am interested what some
more experienced folks think about the workaround
justification from the author of the library.

The usual approach to IE's circular reference memory leak problems is to
break the circles. The onreadystatechange property of the xml http
request object can be set to any harmless function from a scope above
the XML http request object after the handler handles the response, and
the reference to the xml http request object can be removed from the
handler's scope chain by assigning null to the variable that references
it. The same would have to be done if the page unloaded prior to the
completion of the request (along with aborting any pending requests).

The traditional fix for IE has been to point onreadystatechange
to an empty, stub function when the transaction is completed;
you cannot explicitly detach this event handler with "null" in
IE < 7. I'm not fully convinced this works.

It should work, but also removing the reference to the xml http request
object from the old handler's scope chain cannot do any harm. Any
breaking of the circle will do, but fully isolating the two object from
each other should make it clearer that the are both independently
available for garbage collection.

The polling mechanism avoids explicitly binding
onreadystatechange, and instead looks at the readystate
of the transaction. It is an unorthodox attempt to avoid
memory leaks in IE through the event handler.
</quote>

I would want to see code that demonstrated that there was an issue
following the removal of the onreadystatechange handler, it may (if
demonstrated) turn out to be related to some coincidental factor unknown
to the Yahoo developers. Saying something is so is not the same as
showing that it is so.

Richard.

 

[Randy Webb]

drclue said the following on 9/13/2006 9:25 PM:

The requests themselves are not made via AJAX, but rather
simple xbrowser DOM manipulations involving dynamically created
<script> nodes with the queries encoded into the src attribute.

Nothing fancy about that. It is so simple it is trivial to do.

Any page we automate in this fashion no matter how many widgets
it uses now or in the future nor what domain the page
only needs but *a single <script> tag*.

I hope that is not intended to attempt to be impressive or anything
because its not that impressive. The only reason to use more than one
script tag is to reference external files or inline document.write
statements. But, just for fun, I will trump you and say I can write a
dynamically JS driven page without a script tag at all in the HTML code
itself.

<body onload="
loadScript=document.createElement('script');
loadScript.type='text/javascript';
loadScript.src='someOtherJSFile.js';
document.getElementsByTagName('head')[0].appendChild(loadScript);
">

Then, someOtherJSFile.js could contain code that is used in the page.

As I said, it's trivial and boasting of "only needs but a single script
tag" isn't saying much.

 

[Randy Webb]

drclue said the following on 9/14/2006 12:22 AM:

Actually , that's the idea, to keep the javascript trivial,
so that those coding in javascript can yawn.

Just the idea of my programmers yawning while they type gives me the creeps.

Using CSS class and style entries for loading and running libraries
although trivial code , is important in allowing even those who
do just HTML to yawn at the effort required.

Using CSS to import JS, or, to execute server side scripts?