Multithreaded garbage collection for C++

LibGC 1.0 (C) 2005 Achilleas Margaritis
axilmar@b-online.gr


Introduction
------------

LibGC is a very small library (less than 500 lines of code) that adds multithreaded garbage collection to C++.


Documentation
-------------

Here is how to use the library:

1) include files "gc.hpp" and "gc.cpp" in your project.
2) use namespace "gc".
3) inherit your garbage-collected classes from class Object.
4) Use Pointer<T> for pointers to garbage-collected objects where T is your class derived from class Object.
5) Adjust the garbage collected memory with macro GC_MEMORY_SIZE. The default is 64 MB.
6) Adjust the multitasking capability with macro GC_MULTITHREADED set to either 1 or 0. The default is 1.
7) do manual collection with the function collectGarbage().
8) use operator new to allocate garbage-collected objects.

The file "_main.cpp" contains some examples.


Platforms
---------

LibGC has been tested under Win32 on MSVC++ and DevCpp 4.9.9.2.

For using it on other platforms, you have to fill the relevant locking functions:

a) the function 'initLock()' initializes the serialization primitive; called at startup.
b) the function 'deleteLock()' deletes the initialization primitive; called at exit.
c) the function 'lock()' is called to lock the collector from multithreaded access.
d) the function 'unlock()' is called to unlock the collector.


Technical details
-----------------

LibGC uses the stop-and-copy algorithm: when there is not enough memory, then:

a) the collector is locked.
b) the live objects are copied to the beginning of memory space, one after the other (the memory is defragmented).
c) pointers are adjusted accordingly.
d) the collector is unlocked.

If, during the collection, there is not enough memory, then the process exits with a console error message.

Other points to be aware of:

a) garbage-collected objects can be declared on the stack.
b) garbage-collected pointers must be used only with objects allocated with operator new;
   otherwise if a pointer is assigned from a member object or a stack object, the process
   will die a painful death.
c) if new objects are not assigned to pointers, they will not be freed. This is necessary because
   creation of an object can not be done as an atomic operation in C++. It is actually the pointer
   that unlocks the object for collection. Practically, there is very rare need to create objects
   on the heap that are not assigned to any pointers, since in C++, they can be declared as stack-based
   objects. If an object is not unlocked, then it might be overwritten at some point in the future.
d) it is only the special Pointer<T> class that must be used with garbage-collected objects. Normal
   pointers can become dangling any time.
e) garbage-collected objects can still be deleted with operator delete.
f) maximum size of a garbage-collected object must be a little less than 256 MB(if the collector's
   memory is set to more than that, that is).
g) upon exit, all remaining objects will be finalized in the reverse order they were created.
   

Performance
-----------

I've run the following test both in Java 1.4 with Hotspot optimization and C++:
65000 complex objects are allocated 100 times. The average time it takes to allocate the objects was measured.
I found the result much better than Java: it was around 77 milliseconds on my Athlon 64 with 1 GB RAM,
while it was around 100 milliseconds for Java 1.4 with Hotspot compiler.
Of course speed is relative to applications...

Notes
-----

If it does not work for you, don't blame me. I've tried to do my best, but I am sure more testing
is needed. I've never actually done a bigger hack in my life!