Developers are turning to Ajax as a foundation for web application design for a number of reasons, but one of the most important is efficiency. The gains Ajax enables in client-server interaction just can’t be overstated.
It makes no sense at all to work with Ajax, and then lose all the efficiency you’ve gained by letting memory leaks corrupt your application’s performance. If you’re using Ajax, don’t slack off in your attention to memory management.
Not all of us use the term “memory leak,” which is somewhat misleading, so let me clarify: when developers say “memory leak,” they’re talking about memory that an application has made use of, then failed to release, thereby reducing the available resource.
Ajax’s Special Memory Management Considerations
Probably the most unusual piece of AJAX is the Document Object Model. Within AJAX and beyond, DOM is growing in popularity, but few developers really think about its memory management considerations. To do so effectively, it’s important to understand DOM’s position in the Ajax framework.
Remember that Ajax adheres to the MVC model – Model, View, Controller – and that the interaction between these ‘layers’ of an application is very explicitly defined. Within this framework, the MVC model plays out this way:
- The Model is made of JavaScript objects
- The View is populated (prominently but not exclusively) by DOM nodes
- The Controller is where the two interact
Here, memory management considerations happen in this third layer. In oversimplified terms, the Model layer and View layer are mutually referential, and the developer must sometimes manage the terminations of these references. In what cases would this be necessary?
Here’s an example. You instantiate a button using JavaScript. The button, a domain model object in the Model layer, references an object in the View layer. The object in View likewise references the button object. This is a typical mutual reference. In an Ajax application, the object in view is often a DOM element that is part of the document the Ajax application processes.
It’s important to note that any DOM element may be referenced via the document it is part of, even if there is no programmatic reference to it. How, then, would you deallocate the memory held by the button, if you wanted to be rid of it? It would not be enough to break the reference between the button and the DOM element. By nulling the button; the memory allocated to the button would remain taken. The reference must be broken in the other direction: null the DOM element, and null the button reference, as well.
When dealing with a really large Ajax application, you may need to create and destroy DOM nodes as your application progresses, rather than just creating the document tree at the outset and letting it sit there. If you do want to permanently remove DOM nodes, you have a dilemma: there’s no explicit way to do it. Remember that any DOM element remains in memory as long as it’s attached to the document tree, so your task is to detach the DOM node from the tree. That’s really all you can do. At that point, it’s up to the JavaScript garbage collector to catch it and deallocate the memory it is using. In other words, you can control the fate of your DOM nodes, but not the timing of their fate.
Don’t Rely on Garbage Collection
JavaScript, the backbone of Ajax, is a memory-managed language. On paper, this means that the language handles allocation and deallocation of memory for you. In practice, this means that memory management is handled by a few general rules that may or may not apply to how your application is handling its variables. This is what ‘garbage collection’ usually means.
What’s actually happening is that the garbage collector is tracking how variables are being used. If a variable can be immediately referenced, it is left as-is; if it can’t be, it is not considered necessary any longer and the memory it is using is tagged as available. The garbage collection process periodically ‘purges,’ releasing the tagged memory for use.
This process, left to itself, is certainly far better than the chaos of unmanaged memory and is far better for the programmer than having to track memory usage the hard way, by coding memory management into the application. But garbage collection has ‘holes’; memory-managed JavaScript, and your Ajax applications in turn, are susceptible to them, if you don’t watch for them. They’re similar in principle to the problems seen above in DOM, but they come about in more deliberate ways.
Here’s an example. An object modeler might create an object Parent, and give Child to Parent, such that methods exist to add Child and remove Child from Parent. Once added, Child can be accessed as long as Parent can be accessed; if Parent ceases to be accessible, so do all instances of Child. At this level, it’s simple and functional and nothing will go wrong.
But developers can, and often do, complicate such relationships: you can instantiate Child repeatedly under Parent and build backward references to Parent into our Child interface, as when Child is our object of interest and Parent is explicitly referenced in the interface. Developers are (perhaps unfortunately) free to use that explicit reference or not. You can null the Parent instance, and all Child instances that do not explicitly reference Parent are likewise nulled. However, if you explicitly reference Parent through one or more instances of Child, then nulling Parent does you no good; the memory allocated to Parent is untouchable, as long as one reference path through a Child exists. Only through actively nulling every instance of Child does Parent get deallocated.
Conclusion
Watch for these possibilities in your object modeling or your use of previously written objects. Carefully study the possible paths-of-reference, and if you need to actively release memory, by all means, do it! Otherwise you’re spinning your wheels working in Ajax to begin with.
About the Author
Scott Robinson is an IT consultant to the U.S. manufacturing, brokerage, healthcare, and biotech industries. He has managed design teams sponsored by the Department of Defense and the Department of Energy, and has worked with academic research groups. He is vice president of development at Quantumetrics, Inc.
