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]

pe**********@gmail.com wrote:

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).

<snip>

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.

[drclue]

pe**********@gmail.com wrote:

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?

What better answers there might be, sorta depends on your development
context and your overall goals with browser background transactions.

We ourselves have some rather far reaching goals so there is likely to
be some digressions , but it is a rather large canvas that spawned our
approach

I'll give you the nickel tour of the direction we took
in developing reliable interfaces, and others I'm sure
will have additional thoughts that should give you some options
and inspirational input.

Our basic day to day browser background transactions
revolve around MySQl,WSDL,REST,RSS,General XML, XSLT and I guess
this season we are adding ATOM and NNTP transactions too.
[ no rest for the wicked :) ]

All the interfaces on our server return JASONized XML
as javascript including a user definable javascript callback function.
and our javascript *throbber* callback mechanism that manages
retry cycles. (Defaults to 3 retries)
I program via Direcway satellite so the connection can get sketchy
and thus the throbber code gets a good workout

The requests themselves are not made via AJAX, but rather
simple xbrowser DOM manipulations involving dynamically created
<scriptnodes with the queries encoded into the src attribute. invoked
by code like new LAMPtransact({id:"WSDL",cgi:"F1WSDL.cgi",args:szAr gs})
we use this one javascript class to call any of the services we interact
with

Being as all our returns are JASONized XML we use a lot of
dynamic in browser XSL transforms to sling the XML against
an XSL file and fill the target divs with pretty UI
without hard coding same.

(in the voice of a late night infomercial ) "But thats not all !!!"

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 <scripttag*.

We load our widgets via class attributes as in this simple
example that puts a WSDL based Google search in a page, anywhere
on any server including yours (cross domain javascript like Googlemaps).

<div class="wPoint_search" />

(in the voice of a late night infomercial ) "But thats not all !!!"

We are also installing some other CSS legal trickery to cue
forms field validation and UI augmentation to support XML data types
and other UI stuff like HTML capable <textarea>s with but
that same single script tag and simple CSS entries.

[Randy Webb]

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

<snip>

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

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

<snip>

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 <scripttag*.

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
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[drclue]

Randy Webb wrote:

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

<snip>

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

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

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

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.

On the other side of that nice trivial yawn evoking interface
things get at least a little more interesting where a single
object orientated set of C++ source code manifests it self
as various WSDL,XML,MySql and other interfaces to local and remote
resources. Some of these take the form of forking servers with
shared memory run level , and virtual domain support.

While I'm sure this is probably trivial to you as well,
for many it is not so trivial, and for many it's impossible.

Also it was clearly expressed that there were probably
many folks like yourself that would have other positive thoughts to
contribute.

I'm sure you've probably already posted that positive,
and constructive reply to the original posters question. :)

[Randy Webb]

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

Randy Webb wrote:

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

<snip>

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

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

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?

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[drclue]

Randy Webb wrote:

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

>Randy Webb wrote:

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

<snip>

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

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

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.

Well, if one can convert the small stuff to yawns, then
that leaves more room for the really fun stuff where nobody
would be yawning!

>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?

Either one is possible, although the more common use for me
is to have <element class="wPoint_xxxx" /result in
the post page load injection of library wLIB_xxxx.js with flags
in said file resulting in the loading optional wLIB_xxxx.(xml,css,xslt)
imports if indicated. Another variation involves form field validation
and UI augmentation for xml scheama and specialty controls
like HTML editors.