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

Subject: Re: [boost] request for interest in a garbage collection library
From: Achilleas Margaritis (axilmar_at_[hidden])
Date: 2009-04-14 05:26:24

> 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)?

Yes, it is possible, by using a thread-specific ptr to hold a separate 
instance of the gc context per each thread. But it will complicate the 
collection process a little.

>
>> 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.

An object should not be collected if there is a pointer to anywhere in it. 
In other programming languages that pointers to the middle of objects are 
not allowed, this is not an issue.

>
>> 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.

Sure. If there is enough interest and if there are any specific topics that 
need to be addressed, please feel free to indicate them.

>
> 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)?

There are three ways to add garbage collection to an object:

1) inherit from gc_object<T>.
2) wrap your class in gc_wrapper<T>.
3) allocate your object with new(T_deleter)..

But you should modify your pointers to be gc_ptr<T> instances for this to 
work.

> Can classes that do inherit
> from gc_object still be stack-allocated

Yes. The member pointers of stack allocated objects will be considered as 
root pointers.

> or allocated on the free store
> without garbage collection?

Only if you use placement new/delete.

>
> 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?

If your object is stack allocated, you don't have to do anything.

If you want to customize the finalizer, you specialize the template 
gc_finalize<T> for your type,
and perform any finalization in the function. The default behavior of 
gc_finalize<T> is to invoke the destructor.

You can always delete the object at any time or manually collect garbage to 
release any resources.