Eich tells how to prevent JavaScript memory leaks

Infoworld - JavaScript is a staple of the Internet, serving as an object-oriented scripting language for Web development, implemented in browsers. Although JavaScript has automatic memory management, it can have issues with memory "leakage," which can harm program performance. The issue is widely known, but it still is a common failure in JavaScript apps.

To help developers, InfoWorld Editor at Large Paul Krill asked JavaScript founder Brendan Eich how to deal with and prevent these memory leaks.

[ How much do you know about this stalwart developer tool? Find out in the JavaScript IQ test. | InfoWorld's expert contributors show you how to secure your Web browsers in this "Web Browser Security Deep Dive" PDF guide. | Stay in touch on all the key issues in programming with InfoWorld's Developer World newsletter. ]

InfoWorld: What is your view on the issue of JavaScript memory leaks?

Eich: JavaScript has automatic memory management, typically via garbage collection. This does not preclude leaks in practice, but it makes them unlikely and relieves developers from having to worry too much. Memory leaks introduced by bugs in the JavaScript engine are rare, but they can still result from buggy JavaScript implementations that contain internal memory leaks. These are browser bugs to report and fix.

Mozilla and other browser vendors are diligent about fixing these as they come up. Internet Explorer 6 had notorious internal leak hazards (closures as DOM event handlers), but Microsoft fixed them in IE9 and IE10.

Leaks can also result from careless JavaScript code that creates new objects and stores them in a big table of all objects ever created or from similar mistakes. These types of leaks happen in Java and other languages due to developer error, not internal implementation bugs. Developers generally know to avoid them, but they can be hard to detect sometimes. That's where leak-finding tools can help.

InfoWorld: What problems result from these leaks?

Eich: In brief, a garbage collection must be able to find all "live" objects, then collect remaining unreachable objects, which are "garbage" and by definition "dead." If a garbage-collection implementation misses some dead objects due to a logic bug, the memory consumed by those unreachable objects will not be reclaimed [which can lead to slow or unresponsive programs]. The JavaScript-level leaks, where a developer unwisely saves every object created in a big and automatically grown table, for example, are easier to understand.

InfoWorld: How can developers prevent JavaScript memory leaks?

Eich: Developers shouldn't put all objects in a big table or other similar structure such as a linked list.

They should report to browser vendors any inevitable runaway memory growth if the developer can run that same JavaScript code successfully in other browsers without such growth. This probably means the ever-growing browser has a leak in its implementation code. But there could be a browser-specific JavaScript code path, so developers have to be positive that exactly the same code is in use on the control browser that does not grow.