Hacker News Reader

Comment by pmoriarty | Hacker News Reader

"Some languages (like C) require programmers to manually manage memory by specifying when to allocate resources, how much to allocate, and when to free the resources."

This is not required of programmers in C, because the programmer could choose to delegate memory management to a memory management library, such as the Boehm-Demers-Weiser conservative garbage collector. [1]

[1] - http://www.hboehm.info/gc/

View on HN

You're still required to manage memory allocation.

Even having to explicitly delegate memory management to a garbage collector is arguably manual memory management compared to other languages (It's a choice you have to make and adhere to, not a decision that's already been made for you).

Conservative garbage collection like Boehm inevitably leads to memory leaks in long running applications. It's awesome for some use cases but isn't a complete solution by any means.

Wrong. Only if the system failed to identify a root, which is a grave developers mistake, but in the general case boehm-gc does not generate any leaks.

Unlike manual memory collection which inevitably leads to memory leaks.

Failing to identify a root would cause the GC to free too much memory. Memory leaks happen when too little memory is freed. Boehm GC is called conservative because it can't distinguish pointers from other memory content, so it will determine some allocations to be reachable even if there's no pointer to them, because some random integer looks like a pointer into that allocation.

I see, that's what you meant. You are right. You need to use boehmgc in precise mode, which is not the default. You need to tag your pointers. Also use incremental mode for shorter pause times.

Conservative collection is unfortunately terrible when you're dealing with data that looks random, like cryptography. It generates many false "pointer live" positives, which ends up retaining a lot more memory which looks like it's leaking.

True if you don't cooperate at all with the collector, but easily avoided in many cases. E.g., when using Boehm, try using gc_malloc_atomic() for data that you know cannot contain pointers, like your encryption buffers.

Neat. Doesn't really change anything, except that you aren't required to manually manage memory but, practically speaking, you will end up manually managing memory. Especially if you're choosing C for performance requirements.

Not necessarily.

My first experience with the boehm-gc was a long time ago, when I was using a very performance-intensive AI library. As an experiment, I modified it to use the boehm-gc and, surprisingly, it actually became faster.

I've since learned that such a speed improvement when manual memory management is replaced with the boehm-gc is not uncommon.

'Performance' isn't just raw averaged throughout, but often includes worse case latency. There's a lot of perf sensitive applications where a GC isn't a great fit.

This is true, but a lot of those latency sensitive applications are hard latency requirements, where you have to do something in X time, but doing it faster than X isn't actually useful.

There are realtime GCs that can meet these hard requirements.

Those hard real time GCs everytime I've seen them come with overall throughput compromises. Many times real time constraints and overall throughput aren't mutually exclusive.

And even on the soft real time side, like rendering modern GUI, GC pauses causing frameskips (you have ~16ms to render each frame) makes your app look janky.

Totally, that could absolutely be the case. But it probably won't be. The reality is that most C programs do use manual memory management, by a very wide margin.

Unfortunately the defaults are insecure, and so are most of the programs written in C.

Reply on news.ycombinator.com