A conservative garbage collector for C and C++ providing automatic memory management without requiring language changes.
The Boehm-Demers-Weiser Garbage Collector (bdwgc) is a conservative garbage collector for C and C++ that automates memory management by replacing standard malloc/free. It identifies and reclaims unused memory without requiring changes to pointer representations or language syntax, reducing manual memory errors and leaks. The collector is thread-safe and can be used incrementally to minimize pause times in interactive applications.
C and C++ developers building long-running applications, embedded systems, or software where manual memory management is error-prone. It is also useful for researchers and educators exploring garbage collection techniques in systems programming.
Developers choose bdwgc because it provides automatic memory management in C/C++ with minimal integration effort, no language extensions, and proven reliability over decades. Its conservative approach, leak detection capabilities, and cross-platform support make it a unique open-source alternative to manual memory management.
The Boehm-Demers-Weiser conservative C/C++ Garbage Collector (bdwgc, also known as bdw-gc, boehm-gc, libgc)
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
The collector identifies pointers without language changes or tagging, making it a drop-in replacement for malloc in existing C/C++ codebases, as noted in the overview.
Can be configured as a leak detector to identify inaccessible objects in programs using malloc/free, providing a valuable debugging tool alongside garbage collection.
Supports multi-threaded applications and offers incremental/generational collection to reduce pause times, which is crucial for interactive or long-running servers.
Runs on flat 32-bit or 64-bit address spaces across Windows, Linux, Solaris, and BSD variants, with extensive CI testing shown in the README badges.
Provides GC_debug_malloc functions to catch memory overwrite errors and log allocation details, enhancing safety during development.
Due to its conservative scanning, it may fail to reclaim some inaccessible memory, leading to potential bloat, as admitted in the README: 'does not attempt to ensure that all inaccessible storage is reclaimed.'
Dynamic library pointer scanning is fully supported only on specific platforms like Linux and Solaris; on others, manual configuration via GC_add_roots is required, adding complexity.
The collector does not guarantee to scan thread-local storage (e.g., pthread_getspecific), which can cause memory leaks if pointers are stored there without backup on the stack.
Offers multiple build systems (CMake, autoconf, Zig, etc.), but this variety can lead to confusion and integration hurdles, especially for non-standard environments.