How to ensure memory leak protection?
in [JavaScript]
|
From: John G Harris on 22 Jul 2010 10:16 On Thu, 22 Jul 2010 at 00:24:04, in comp.lang.javascript, David Mark wrote: <snip> >ISTM that the term instances is associated with classes, of which >there are none in JS. 'Instance' is associated with anything that is one of many. You have said, I seem to remember, that there are no singleton objects in JS, so every object must be one of many somethings. <snip> >I would have called it an Array object. You are using 'Array' as an adjective here. This is just a short way of saying that it's an object that was created by the constructor named Array. Either way, the object is a member of the class of all possible such objects. >Doesn't that make more >sense? Like all JS objects, it is constructed, not instantiated. I don't believe there is any substantial difference between construct and instantiate. Occasionally you might want to distinguish between construction, which does not include allocating space for the object, and instantiation which often does, as in a factory method. John -- John Harris
From: Gregor Kofler on 22 Jul 2010 11:02 Am 2010-07-22 15:48, Josh Russo meinte: > Ok now you lost me. The lines in question are these: > > var clickHandler = function(event){ //do something }; > this.myfield.bind('click', clickHandler); > > This is not within a jQuery method. jQuery merely stores the reference > that I pass to it. The clickHandler function right there outside of > the jQuery object, or am I missing something? You are passing a reference, but it will not get "merely stored". Instead it will be wrapped and fiddled with by jQuery (for cross-browser "normalization" and such stuff). >>> var X = []; >>> var Y = []; >> >> Bad form? :) But seriously, the X and Y variables refer to Array >> objects. > > Why is this bad form? It is recommended to use upper case variable names for constructor functions only. > I always want to know how things really work and in that it helps to > speak the language so everyone is on the same page. With this attitude, you will never become a good script kiddie... Gregor -- http://www.gregorkofler.com
From: Josh Russo on 22 Jul 2010 11:15 On Jul 22, 2:02 pm, Gregor Kofler <use...(a)gregorkofler.com> wrote: > Am 2010-07-22 15:48, Josh Russo meinte: > > > Ok now you lost me. The lines in question are these: > > > var clickHandler = function(event){ //do something }; > > this.myfield.bind('click', clickHandler); > > > This is not within a jQuery method. jQuery merely stores the reference > > that I pass to it. The clickHandler function right there outside of > > the jQuery object, or am I missing something? > > You are passing a reference, but it will not get "merely stored". > Instead it will be wrapped and fiddled with by jQuery (for cross-browser > "normalization" and such stuff). Ok, but the important part for this discussion is that it still maintains it's original variable scope, and I believe it does. I will have to confirm that. > > >>> var X = []; > >>> var Y = []; > > >> Bad form? :) But seriously, the X and Y variables refer to Array > >> objects. > > > Why is this bad form? > > It is recommended to use upper case variable names for constructor > functions only. LOL Is that all he was referring to? Ok. I thought it was the square braces instead of 'new Array()'. > > > I always want to know how things really work and in that it helps to > > speak the language so everyone is on the same page. > > With this attitude, you will never become a good script kiddie... Damn! My life's dream shattered!
From: Gregor Kofler on 22 Jul 2010 12:03 Am 2010-07-22 17:15, Josh Russo meinte: >>>>> var X = []; >>>>> var Y = []; >> >>>> Bad form? :) But seriously, the X and Y variables refer to Array >>>> objects. >> >>> Why is this bad form? >> >> It is recommended to use upper case variable names for constructor >> functions only. > > LOL Is that all he was referring to? Ok. I thought it was the square > braces instead of 'new Array()'. The square bracket notation is the preferred way to define array values. Gregor -- http://www.gregorkofler.com
From: Richard Cornford on 22 Jul 2010 13:34
On Jul 22, 2:48 pm, Josh Russo wrote: > On Jul 22, 9:50 am, David Mark wrote: >> On Jul 22, 5:08 am, Josh Russo wrote: <snip> >>> What matter is the scope of the event listener function >>> when it's declared. > >> In the case we have been discussing, the listener attached >> by jQuery is not declared at all. It's created with a >> function expression inside of a jQuery method. What do >> you figure its scope to be? That's right, you will have to >> slog through jQuery's code again to determine whether it is >> minding its business with regard to avoiding circular >> references. What your code does is actually immaterial. >> Confusing and time-consuming isn't it? > > Ok now you lost me. The lines in question are these: > > var clickHandler = function(event){ //do something }; > this.myfield.bind('click', clickHandler); > > This is not within a jQuery method. jQuery merely stores the > reference that I pass to it. The clickHandler function right > there outside of the jQuery object, or am I missing something? <snip> Not looking does tend to be quite a good way of missing things. Take a look at JQuery source code and you find that the - bind - method (more or less indirectly) calls a - jQuery.event.add - method. This is its source code form the current (1.4.2) version (or at least pertinent highlights from the code) (and re-wrapped a little to avoid it being broken by Usenet posting):- | jQuery.event = { | | // Bind an event to an element | // Original by Dean Edwards | add: function( elem, types, handler, data ) { .... | var events = elemData.events = elemData.events || {}, | eventHandle = elemData.handle, eventHandle; ^^^^^^^^^^^ ^^^^^^^^^^^ I don't like the form of variable declaration statement that uses a single - var - but spreads numerous declarations across multiple lines, terminating each in a comma (rather than using multiple variable declarations, terminating each line with a semicolon). I frequently find myself miss-reading them, and so think of them as not being particularly clear in source code terms. Above there is evidence of this lack of clarity in the fact that - eventHandle - has been declared twice in the same variable declaration statement. There is no good reason for doing that (ever) and the intention cannot have been to write the equivalent of - eventHandle = (elemData.handle, eventHandle) - (as that would be obviously wrong given the next line of code), so presumably this 'oddity' has resulted (and survived (presumably many observers)) from a failure to comprehend the source code as presented. | if ( !eventHandle ) { | elemData.handle = eventHandle = function() { | // Handle the second event of a trigger and when | // an event is called after a page has unloaded | return typeof jQuery !== "undefined" && | !jQuery.event.triggered ? | jQuery.event.handle.apply( eventHandle.elem, arguments ): | undefined; | }; | } | | // Add elem as a property of the handle function | // This is to prevent a memory leak with non-native | // events in IE. | eventHandle.elem = elem; ^^^^^^^^^^^^^^^^^^^^^^^ Here the function either retrieved or created above and assigned to the variable - eventHandle - has a property added to it with the name 'elem' and a reference to a object that is likely to be a DOM Element assigned to it. JQuery comments never seem to explain the more unexpected aspects of what JQuery code does. IE has memory leak problems (or at lest older versions of it do), but what does "non-native events" mean, and how is this going to prevent the memory leaks? Possibly the idea is that if the variable - elem - where referenced in the - jQuery.event.handle.apply( ... - line above, and not nulled at the end of this method, then there would be an obvious circular chain of reference, which there would be. But what follows rather negates any effort taken to avoid that circle. | | // Handle multiple events separated by a space | // jQuery(...).bind("mouseover mouseout", fn); | types = types.split(" "); | | var type, i = 0, namespaces; | | while ( (type = types[ i++ ]) ) { .... | | // Init the event handler queue | if ( !handlers ) { | handlers = events[ type ] = []; | | // Check for a special event handler | // Only use addEventListener/attachEvent if the special | // events handler returns false | if ( !special.setup || | special.setup.call( | elem, data, namespaces, eventHandle | ) === false | ) { | // Bind the global event handler to the element | if ( elem.addEventListener ) { | elem.addEventListener( type, eventHandle, false ); | | } else if ( elem.attachEvent ) { | elem.attachEvent( "on" + type, eventHandle ); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ And there the circle is closed. (on IE, which is where it will matter) The (likely DOM Element) referred to by - elem - is given a reference to the - eventHandle - function through the - attachEvent - mechanism, while the - eventHandle - has a reference to the - elem - object through the 'elem' property that was assigned above. That is a circular chain of reference, established (albeit only once, but once is enough) for each event type, for each unique - elem - passed into the - add - method. | } | } | } .... | elem = null; | }, .... Outside of JQuery you can do whatever you like to avoid the memory leak-inducing circular chains of references, but JQuery creates them for you when you use its - bind - method. Now the question is whether JQuery cleans these circular chains of reference up on its own, or whether you are going to have to take some remedial action to remove bound methods; time to "slog through jQuery's code again". And if it turns out that you have to take action yourself then maybe you don't have to avoid creating circular chins of reference as you would have the opportunity to break any you did create at the same time as you set about breaking JQuery's. Richard. |