I used this and had a good experience with it. The project I used it on was ~150K lines of C and had lots of developers from different organizations contributing code. That made it a pretty good example of a project that was having trouble growing because of manual memory management. On such a project, just defining and documenting who should call free() for a given data structure is hard and actually enforcing those rules (and figuring out what component broke them) is much harder.

We were able to pretty easily integrate it into the project (we already had macros indirecting all calls to malloc() and free()) and initially use it as a leak detector. After that we were able to trust it to handle deallocation where it made sense.

A neat feature of this collector is that you can tell it during allocation that a block is guaranteed to have no pointers in it for those cases where you can know that (blacklisting big chunks of floating point data or images). This improves the performance and accuracy of the conservative collection as it doesn't need to scan those blocks. That makes it less objectionable if you are accustomed to the level of control you get with C.

If I were to build a big system in C again, I would use it from the beginning. But I am unlikely to build such a big system in C these days.

Exactly ! :)

Ever single (good) programmer I know is aware of Hans-Boehm GC, but doesn't use it for any projects. In fact I am yet to see a project that uses it and I've seen quite a lot of them to date.

This is probably the most famous and widely-used C/C++ garbage collection system in the world.

(Yeah, I've used it, in a scripting language I wrote for a commercial product in the '90s. No troubles.)

i'm curious as well.

personally, i am of the opinion that RAII-style object lifetime management as implemented in C++ is already far superior to garbage collection. but maybe somebody can convince me otherwise.

ECL (a mature, stable Lisp which compiles to C) uses it.