cc ... gc.a
Unlike the standard implementations of malloc, GC_malloc clears the newly allocated storage. GC_malloc_atomic does not. Furthermore, it informs the collector that the resulting object will never contain any pointers, and should therefore not be scanned by the collector. GC_free can be used to deallocate objects, but its use is optional, and discouraged. GC_realloc has the standard realloc semantics. It preserves pointer-free-ness. GC_register_finalizer allows for registration of functions that are invoked when an object becomes inaccessible.
It is also possible to use the collector to find storage leaks in programs destined to be run with standard malloc/free. The collector can be compiled for thread-safe operation. Unlike standard malloc, it is safe to call malloc after a previous malloc call was interrupted by a signal, provided the original malloc call is not resumed.
Debugging versions of many of the above routines are provided as macros. Their names are identical to the above, but consist of all capital letters. If GC_DEBUG is defined before gc.h is included, these routines do additional checking, and allow the leak detecting version of the collector to produce slightly more useful output. Without GC_DEBUG defined, they behave exactly like the lower-case versions.
On some machines, collection will be performed incrementally after a call to GC_enable_incremental. This may temporarily write protect pages in the heap. See the README file for more information on how this interacts with system calls that write to the heap.
Other facilities not discussed here include a C++ interface, limited facilities to support incremental collection on machines without appropriate VM support, provisions for providing more explicit object layout information to the garbage collector, more direct support for ``weak'' pointers, etc.
Boehm, H., and M. Weiser, "Garbage Collection in an Uncooperative Environment", Software Practice & Experience, September 1988, pp. 807-820.
The malloc(3) man page.