Are you using Objective-C and relying on the garbage collector?
|What distracts me is, that compiling and running my program on linux,|
and watching its memory consumption with either "top" or "ps -eo vsz,cmd"
it looks like the program is always using its peak memory (ie. a couple of GB).
|3. I use a Java IDE all the time. When I load a few huge projects, the memory usage goes up. If I close them, it drops back to the previous level. I can't see this behaviour on e.g. Firefox. Open 50 tabs, close 50 tabs and memory usage goes over the roof. Also, simply use Firefox for a week without closing - it eats more and more, while Idea keeps the same level of around 200-400 MB (depends on what I actually do).|
|There are 4 places a browser can leak memory:|
The web page
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.
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.
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.
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.
Is it? It is fairly trivial to place objects that are to be released together in contiguous chunks of memory.
|in production code, in which you may have to call through 10 abstractions layers, in 5 different libraries where you have no control over how they manage memory internally|
|What parameters can you tune for malloc/new? Nothing.|