I'm very interested in portable garbage collection.
1) it supports threads; a thread can allocate gc objects and send them to other threads.
You mention in the readme that performance suffers with large numbers of threads due to a global mutex. Would it be possible to have collectors specific to a thread or groups of threads (essentially giving each thread/group of threads a piece of the heap to allocate from/manage with GC)?
3) gc pointers can point to middle of objects and arrays.
I don't really understand how this works. Would the middle of an object/array get collected separately from the rest of it? That seems ridiculous, so I'm confused.
The zip file contains a set of unit tests, the API documentation and a readme file which explains the inner workings and the design of the collector.
As is often the case, the readme could be improved. Looking at gc_object, it seems that any class that wants to be gc-allocated needs to inherit from gc_object. Can this be avoided (e.g., so I can gc-allocate classes I can't modify)? Can classes that do inherit from gc_object still be stack-allocated or allocated on the free store without garbage collection? I'm a bit unclear as to how finalization works. Suppose I simply want to invoke the destructor to ensure that resources have been reclaimed (from a class that uses RAII when stack-allocated and an explicit close() method when heap-allocated) when the object is finalized. How do I do that? Despite these problems, I'm still excited to see the subject considered. --Jeffrey Bosboom