Re: [boost] request for interest in a garbage collection library

Subject: Re: [boost] request for interest in a garbage collection library
From: jbosboom_at_[hidden]
Date: 2009-04-13 17:50:04

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