What’s a memory leak? I forget
This week, Sho and I gave a presentation on JavaScript’s concept of closure at Flatiron School Presents. While doing the research, we came across one disadvantage of using closures: memory leaks.
A memory leak happens when a program requests for and takes up the memory, but doesn’t actually use it. Computer memory is stored in and retrieved from Random Access Memory (RAM), just like how human’s short term memory gets stored in the hippocampus, a very specific region of our brain. The memory that RAM temporarily stores is the data of running applications.
Luckily, JavaScript is a “garbage collecting” language that automatically frees objects and strings that are not in use anymore. Therefore local variables in a function are released when the function returns them, and clears the space for other memory to be allocated.
But, what if a function is a closure?
To allow the understanding of memory leaks in JavaScript, I would like to point out the most prominent attribute of a closure. However, I won’t go too into the concept of closure in this post since closure itself is a huge topic of discussion.
A closure is a child (inner) function that has access to the scope of its parent (outer) functions. To be more clear, closures in JavaScript can access the information in the outer functions because they carry references to the outer functions’ variables, not the actual value. For example, if the value of the var y changes from 15 to 5, function g() would hold the updated value of 5.
Since a closure’s job is to hold on to the reference to the outer function’s scope, instead of getting released, it takes up extra RAM space in your system. This phenomenon sounds much like the definition of memory leaks, doesn’t it?
This is just one example of different potential causes of memory leaks in your system. Other JavaScript related causes may include the following:
- Using timers or callbacks that make reference to data that is no longer required
- Not explicitly removing the EventListeners when they are not needed outside of the local scope
To check how much memory space your currently running applications are taking up, you can Spotlight Search ‘Activity Monitor’ and click on the ‘Memory’ tab.
In this specific example, I had happened to have about 29 tabs open in Chrome with some of other applications. The Activity Monitor shows that whatever I’m doing with my computer at the moment, it’s taking up 7.01 GB / 8.00 GB RAM space.
When the RAM is full, contents get saved onto the hard disk to free up space in RAM. This process is called “swapping.” In the example above, 227.MB of my RAM space was swapped for that amount of space in my hard drive. While accessing data stored in the RAM can be instantaneous, it takes longer to retrieve the data from the hard disk. Unlike the RAM that’s temporarily storing data, the data in the disk first needs to be located, read and sent to the RAM before it gets processed.
So how do you know if there is a memory leak? Memory leaks don’t result in physical or permanent damage. Since it’s a software issue, it will slow down the applications or even your whole system. However, a program taking up a lot of RAM space doesn’t always mean its memory is leaking somewhere. The program you’re using may really need that much space.
Earlier in the post I mentioned that JavaScript is a garbage collecting language. Garbage collection runs when memory is allocated and lost. It looks for memory that is not in use and releases it back to the system, decreasing the likelihood of memory leaks (that are not caused by closures!)
Find out more on using developer tools to locate memory leaks:
