Comment by taylodl | Hacker News Reader

Comment by taylodl | Hacker News Reader

Parent Full thread

I learned Smalltalk in 1994, which was well past the Elder Days. I came from a strong C++ background. I had the same experience you had in that Smalltalk showed a completely different way of doing things. Unfortunately we were hampered by garbage collection. We tried to tune and optimize as much as the environment would allow to no avail - when it came time to garbage collect the system would freeze for several seconds, sometimes up to tens of seconds. That was completely unacceptable for commercial software. Marketing also wasn't thrilled the UI came bundled with the environment. It was rather ironic that Java would come out the next year and the entire industry would pour so many resources into solving the garbage collection problem. Nowadays on a multi-processor system with concurrent garbage collection enabled the garbage collection can run faster than on manually-managed memory! That sure didn't seem like it would ever be possible in 1994!

> [a] system with concurrent garbage collection enabled the garbage collection can run faster than on manually-managed memory

Maybe. But not predictably. It will have delays, they may be small, but there is know way to know when they will come. This can be managed but it is all overhead. Manual memory management has none of that run-time overhead (but a tonne of programmer overhead)

Manual memory management is much more predictable (which is really nice for interactive/real-time programs), it does have nontrivial runtime overhead: malloc and free aren't free (pun slightly intended), and often costlier than a bump allocator most moving/copying GCs use (just increment a pointer and have a very branch-predictable conditional to check OOM). Also, moving/copying GCs increase data locality by bringing live objects closer, which is more cache friendly.

I agree that manual memory management is much more predictable than garbage collection, I just wanted to touch on the nuances of the memory overhead of manual memory management.

Also, if the program creates lots of short-lived objects (which is often the case), a generational garbage collector would be pretty fast because it will reclaim/move a few objects rather than deallocating many objects. An arena collector or allocating on the stack might be better (and manual methods) in this scenario though.

> It will have delays, they may be small, but there is know way to know when they will come.

It was my understanding that C4 doesn't do pauses.

On the face of it, I do not believe it. "Mostly dosen't pauses" is believable. Great strides have been made

But what is it? Where can I find out about it? A deterministic garbage collector would (a) prove me wrong and (b) be a Very Good Thing

Reply on news.ycombinator.com