In computer science, the Boehm–Demers–Weiser garbage collector, often simply known as Boehm GC, is a conservative garbage collector for C and C++.^[1]

Boehm GC is free software distributed under a permissive free software licence similar to the X11 license.


The developer describes the operation of the collector as follows:

The collector uses a mark-sweep algorithm. It provides incremental and generational collection under operating systems which provide the right kind of virtual memory support. (Currently this includes SunOS[45], IRIX, OSF/1, Linux, and Windows, with varying restrictions.) It allows finalization code to be invoked when an object is collected. It can take advantage of type information to locate pointers if such information is provided, but it is usually used without such information.

http://www.hboehm.info/gc/#details

Boehm GC can also run in leak detection mode^[2] in which memory management is still done manually, but the Boehm GC can check if it is done properly. In this way a programmer can find memory leaks and double deallocations.

Boehm GC is also distributed with a C string handling library called cords. This is similar to ropes in C++ (strings are trees of small arrays, and they never change), but instead of using reference counting for proper deallocation, it relies on garbage collection to free objects. Cords are good at handling very large texts, modifications to them in the middle, slicing, concatenating, and keeping history of changes (undo/redo functionality).

Curio

• a small and unusual object that is considered interesting or attractive
• A Python library for concurrent I/O and systems programming.

Curio is a library for performing concurrent I/O and common system programming tasks such as launching subprocesses and farming work out to thread and process pools. It uses Python coroutines and the explicit async/await syntax introduced in Python 3.5. Its programming model is based on cooperative multitasking and existing programming abstractions such as threads, sockets, files, subprocesses, locks, and queues. You’ll find it to be small and fast.

Conclusion

The key takeaway from this investigation is that GCs are either optimized for lower latency or higher throughput. They might also perform better or worse at these depending on the heap usage of your program. (Are there a lot of objects? Do they have long or short lifetimes?)

It is important to understand the underlying GC algorithm in order to decide whether it is appropriate for your use-case. It’s also important to test the GC implementation in practice. Your benchmark should exhibit the same heap usage as the program you intend to implement. This will check the effectiveness of the GC implementation in practice. As we saw, the Go implementation is not without faults, but in our case the issues were acceptable. I would love to see the same benchmark in more languages if you would like to contribute :)

Despite some issues, Go’s GC performs well compared to other GCed languages. The Go team have been improving the latency, and continue to do so. We’re happy with Go’s GC, in theory and practice.