Hacker News Reader

There was an article on HN a few days ago about how the Digital Mars D compiler was using the null garbage collector and modified its allocation strategy to take advantage of this to yield a major speedup.

Here's the referenced article. It's quite interesting: http://www.drdobbs.com/cpp/increasing-compiler-speed-by-over...

The apache http server uses that allocation strategy, actually. For each request you have a separate memory pool and you allocate out of that. There's no function to free memory you've got from a pool and the entire pool is destroyed/released after the request has been served.

This sounds great if it's just a switch you can pull to turn off the garbage collector, but I wanted to pipe up to strongly recommend against this approach if you're working in an environment with manual memory management. It can be tempting to write code that calls malloc but never calls free, because you know that the process is short-lived and it's pointless. The problem comes when your requirements change or you reuse some code, and suddenly that memory needs to be cleaned up. It's far more painful to go back and insert the cleanup calls after the fact than it is to get them in the right place when you write the code. I did this once, and never again.

The QT C++ framework consciously decides to not deallocate the stuff that only get allocated once. The result is that running leaking catching tools is very hard. Not necessarily the greatest outcome despite being a logically defensible move.

QT is big and popular enough that I would expect tools to have support for it.

Wouldn't a creation of the equivalent of a permspace and instructing said tools to ignore it mitigate the problem?

It might but that would be a matter for whoever is now developing QT itself.

Can you be more specific? The common case in Qt (not QT) is that a QObject has a parent and when the parent is destroyed all of the children are too.

See: http://stackoverflow.com/questions/1593717/is-anyone-using-v...

When I googled that, I found QT apparent has created some suppression files to help with using Valgrind. But I'm pretty sure that's recent and users struggled for a while with QT's approach.

http://developer.nokia.com/Community/Wiki/Using_valgrind_wit...

>BTW, it's not unheard of for short-lived command line utilities or multiprocess apps to literally run with the null garbage collector.

If I am not mistaken, PHP scripts use precisely that.

And they can get away with it, because they are short-lived.

Erlang processes are green threads, not system processes. It is true that they each have their own heap, but the heaps are GC-ed.

I know that they're green threads. I thought the implementation was that the heap itself is malloc'd from the OS and then freed when the process terminates. Within the heap, of course, it uses GC, but if you set the heap size at process creation > the total memory allocated, then the GC never runs and the heap essentially becomes an arena.

> They just never free memory and deliberately leak it until they exit

Which is a great way to kill that process, or arbitrary processes, when a previously well-behaved program is run on a system that's a bit strapped for RAM at the moment, or run on a somewhat larger-than-usual input, or both.

That, or bring the system to a standstill as the swapping subsystem flogs the disk nonstop.

Possibly first one, and then the other.

Well, you never have guarantees that this won't happen even if you free().

Reasonable resource consumption is an engineering decision based on context (target, expected problem size, etc).

Deliberate leaking is IMHO a totally viable engineering strategy. If anything, behaviour is actually more reliable and predictable than the alternatives apart from "upfront static allocation".

If you ran into problems and want the entire system to behave predictably, you could on Linux disable vm overcommit, set oom_adj (so leaker proc gets killed preferentially), set strict ulimits and ensure abort() on malloc failure. However if you have to go to these lengths, leaking might not be appropriate ;)

For a lot of these simple command-line utilities, it wouldn't matter anyway. They often work by building up some data structure that's then used to process the rest of the input line-by-line, and then the program exits. If the data structure is never freed, so what? It's needed until the end of execution anyway.

Think of compiled regular expressions for grep, or total counts for wc, or a rotating line buffer for tail, or the previous line for uniq.

It's quite possible to get pathological behavior even with GC or careful RAII, as anyone who's ever leaked memory in a Java program could tell you. Simulating a computer with infinite memory breaks down when the working set you're touching exceeds the physical RAM of the machine. Actually, leaking memory is the least of your concerns in that case, as leaked memory just gets paged out and doesn't cause any problems unless it exceeds the computer's address space.

Actually, with tail -f that could become a problem.

I don't see how it could. Tail doesn't use more memory as it reads more lines. It sets up a fixed-size buffer and then continually re-uses it. Yes, "tail -f" could be a long-running process, but its memory usage should remain constant over its entire lifetime.

If your five orders of magnatude below system RAM and the OS runs out of memory then it's someone else's problem. Granted the system might runout of swap space due to say the 100kb you allocated but reolistically other things that take up ~100,000 times as much space collectively are the actual problem.

What kind of systems are you running where a few hundred kilobytes of allocation on a machine with gigabytes of memory can "bring the system to a standstill"?