Boehm-Demers-Weiser conservative C/C++ Garbage Collector
Garbage collection for C and C++—specifically the Boehm-Demers-Weiser conservative collector—prompts debate over where it makes sense compared to RAII, smart pointers, and manual memory management. Commenters weigh GC’s impact on latency and throughput, citing game engines, browsers, language runtimes, and real‑time systems as case studies where either GC or manual techniques can fail or shine. Several note that while Boehm GC is surprisingly easy to integrate and often competitive with malloc/free, its conservative nature, tuning complexity, and non-deterministic pauses limit its suitability for the most latency-sensitive workloads.
GC reputation and perceived performance
- Many comments link GC’s “bad rap” to old Mono/Unity pauses and slow languages like Python, but several argue Python’s speed issues are mostly due to its dynamic semantics, not GC.
- Stop‑the‑world collectors are seen as problematic for games and hard real‑time; others note modern generational/concurrent collectors can offer good throughput and acceptable pauses for GUIs and batch workloads.
- Ref counting is described as a GC algorithm with high overhead (especially with atomics) and cycle problems; in early Rust, refcount ops made up a large fraction of binary size.
C++ memory management vs. GC
- One camp: modern C++ (RAII,
unique_ptr/shared_ptr, STL containers) removes most need for GC; reference counting plus careful design is “good enough” and deterministic. - Counter‑camp: large object graphs with complex lifetimes, lock‑free data structures, and language runtimes are difficult to manage safely with only RAII/smart pointers; GC can simplify logic and sometimes be faster than intrusive refcounting.
- Cycles, cascading deletes, and refcount overhead are recurring concerns; some consider these rare or design smells, others argue they appear naturally in real systems.
Boehm-Demers-Weiser (BDW) GC experiences
- Praised as surprisingly fast and easy to integrate for C/C++ projects needing a GC (e.g., language runtimes); often competitive with or faster than naïve
malloc/free, and significantly simpler than more advanced collectors. - Critics emphasize its conservative nature: pointer “guessing,” complex configuration, blacklisting, and non‑portable register scanning. Some report bad experiences and eventual removal; others have used it successfully for years.
- Its conservative design prevents moving/compacting objects and complicates advanced techniques like precise generational or incremental collection.
Memory layout, value types, and design patterns
- Lack of value types in Java‑like GCs leads to “webs of objects,” extra indirection, poorer cache locality, and awkward parent/child relations; value types and struct‑of‑arrays/ECS designs are promoted as better for performance.
- Older GC languages already had value‑like aggregates; Java is framed as an outlier now being retrofitted.
Low‑latency, real‑time, and research
- For ultra‑low‑latency and hard real‑time, commenters favor arenas, fixed‑size allocations, and strict design constraints; some argue allocators and RAII can still cause large pauses.
- Others point to concurrent/incremental GC designs, specialized allocators, and resources like the Garbage Collection Handbook and specific low‑latency collectors as active areas of work.