A colleague and I were speaking about browsers (using a browser control object in a project), and it appears as plain as day that all browsers (Firefox, Chrome, IE, Opera) display the same characteristic or side-effect from their usage and that being 'Leaking Memory'.

Can someone explain why that is the case? Surely as with any form of code, there should be proper garbage collection?

PS. I've read about some defensive patterns on why this can happen from a developer's perspective. I am aware of an article Crockford wrote on IE; but why is the problem symptomatic of every browser?
Thanks

... not to be an arse, or pedantic... but it's because the developers aren't deleting/freeing memory that they're allocating... that's pretty much the reason in every case of a memory leak. It's not specific to browsers (though, I guess it's remotely curious that they all appear to do it... but not that curious).
–
Steve EversNov 5 '12 at 5:19

Not all programming languages support garbage collection. And, you can easily have memory leaks even in those languages that do have it. Stackoverflow and this site probably have lots of information about why that is true.
–
MatrixFrogNov 5 '12 at 6:02

1

Why do any programmes leak memory!Its not as if browser are a special case or for that matter simple. Modern browsers are probably the most complex piece of user orientated software on a home computer. Not only do they need to understand correctly formatted code but also badly formatted code (and still provide a reasonable interpretation). Note only do they need to execute arbitrarily complex software internally but also cope with deliberately malicious code while providing at least the illusion of security (not looking at your ie).
–
Loki AstariNov 5 '12 at 6:13

1

@MatrixFrog You can easily have a memory leak even in garbage-collected languages like Java, JavaScript, etc. The language itself is not the cause. It is always the developer who should be held responsible for memory leaks. There are lots of features and techniques in not garbage-collected languages that facilitate efficient memory management. And let's not forget that garbage-collected languages have their runtimes written in not garbage-collected ones. The only difference in terms of memory management between them is that in languages like Java it's automatic and C/C++-like ones it's manual
–
akhillessNov 5 '12 at 10:57

2

What do you mean by "appears as plain as day"? Did you use some leak-detection tool on web browsers?
–
Nemanja TrifunovicNov 5 '12 at 14:58

3 Answers
3

In modern browsers this is fully up to the web developer. Garbage-collected environments don't collect memory that is still being referenced to, and there are a lot of ways to keep referencing memory without meaning to (e.g. create a closure to attach as an event handler and accidentally include a bunch of variables in that closure's scope). A web developer can solve these leaks completely by properly handling variable references in their code. A page reload typically frees up the memory.

Add-ons

If add-ons are also written in a garbage-collected language (like javascript), then they suffer from the same issue. However a page reload will typically not free up this memory, so it appears as if the browser is leaking memory whereas it's actually the add-on developer's fault. To my knowledge this is the biggest cause of browser leaks (which is why the default recommendation is to test whether the leak occurs without add-ons).

Browser engine

All modern browser engines are written in C++. C++ is not garbage-collected, but uses explicit memory allocation instead. If developers allocate memory and then forget to deallocate it, the engine leaks memory. To my knowledge all the browser makers do a lot of testing and code review to find and solve these kinds of leaks. It's not 100% fixed, and never will be, but it's not a huge problem anymore.

Non-leaks

Finally there are a range of caching features that mean the browser's process will grow in scope while using it. These aren't leaks, they're intended to optimally make use of available RAM. Typically the memory footprint grows to a maximum and then hovers there.

In C++ you get automatic dealloation with RAII. You do not need to remember to deallocate anymore than you would in a garbage collected language like Java. But of course you must remember to set up your destructor and use smart pointers to get that benefit. The prep work is manual, but the deallocation is automatic.
–
mike30Nov 5 '12 at 20:12

1

@mike However, even with full setup like that, I highly doubt RAII is a catch-all. It's easy to have memory leaks in garbage collected languages like Java, after all
–
IzkataNov 5 '12 at 21:15

@Joeri can you put some code snippet to demonstrate memory leak while using closures ?
–
GeekNov 6 '12 at 6:49

@Joeri Why does page reload typically free memory of a web page but not in an add on ?
–
GeekNov 6 '12 at 6:57

@Geek: see the example at the bottom of flightschool.acylt.com/devnotes/… (and note that the variable that is closed over doesn't need to be a DOM node, it can be anything). Add-ons may free memory on page load, if the add-on itself is reloaded by the browser on every page, but most add-ons are longer lived. See this article for firefox's challenges with add-on leaks: blog.mozilla.org/nnethercote/2012/07/19/…
–
Joeri SebrechtsNov 6 '12 at 8:38

The above pattern will leak due to the circular reference created
between a DOM node and a JS element.

Since the JScript garbage collector is a mark and sweep GC, you may
think that it would handle circular references. And in fact it does.
However this circular reference is between the DOM and JS worlds. DOM
and JS have separate garbage collectors. Therefore they cannot clean
up memory in situations like the above.

While that's certainly not the reason for all memory leaks in browsers, it's an interesting illustration on how it can go wrong.
–
Joachim SauerNov 5 '12 at 8:05

you'd think it's not that hard to combine these GCs, the DOM with its tree structure can use a simpler GC which if not linked to a root node would then depend entirely on the JS GC (recursively)
–
ratchet freakNov 5 '12 at 8:15

I wouldn't be surprised if what you are categorizing as "leaks" is instead some aggressive cacheing. Even today, network round-trip time is "expensive" (time-wise) compared to fetching something from an in-memory cache. I'd recommend grabbing the source for Firefox or Chromium and taking a look at how they manage their caches. I know that Firefox at least supports re-opening recently-closed windows/tabs, so even completely closing a site doesn't necessarily mean that the cached images and scripts are evicted.