Re: [boost] Re: GC [was:alignment]

From: Larry Evans (jcampbell3_at_[hidden])
Date: 2001-05-10 18:02:19

John Max Skaller wrote:

> jcampbell3_at_[hidden] wrote:
>
> > If you changed the collector to use smart pointers, then you
> > could use the method in
> > http://groups.yahoo.com/group/boost/files
> > /GarbageCollectByTmplSpecializa/
> > for collecting cycles.  What are the reasons for not using smart
> > pointers?
>
>         First, this is invasive.
>
>         Secondly, it adds complexity. Simple is good.
> I read the description in the above file,
> and I don't have the faintest idea what it is on about.
> I'm not sure how to use it, what it does, what compilers
> it works on, what the costs are, etc. Note that at

It will work on g++ [I'm compiling with gcc version 2.97 20010119 (experimental)].
The offsets calculated when the smart pointer template argument, OffRoot, is off_yes,
correspond to felix's gc_shape_t::n_offsets_a and gc_shape_t::offsets_a.  These offsets
are accessed using the class static method, mk_off_yes<T<GcMethod,off_yes> >::offsets(),
where GcMethod specifies the gc method, and T is the template class to be garbage
collected.

I'm currently working on comparing with other gc methods.  In that comparison,
I'll describe the costs.  Briefly, the cost is the same as felix except the pointee's
require a virtual function table to store the virtual function for getting the
offsets.  Maybe gc_shape_t could have a virtual function which allowed
dynamic change of offsets (see below reference to vector<T*> x).  One high
cost for pure mark-sweep (see drivers/simpmsw_zomsafe) is the set used to hold the
roots.   I could use some advice on how to alleviate that cost.

>
> present, the Felix gc depends ONLY on the C and C++ standard
> libraries: it doesn't depend on boost.
>
>         [It would be nice if someone could explain and demonstrate
> use of the above file, it may well be useful.]

There are test drivers demonstrating its use in the  zip file:
    http://groups.yahoo.com/group/boost/files/GarbageCollectByTmplSpecializa/gc_sel_ssp.zip
in directories below  the directory lib/gc_sel_ssp/tests/drivers.

>
>
>         Thirdly, the collector was originally designed for Felix.
> Felix has no problems generating the shape objects. It is possible
> a tool can help C++ programmers generate the shape objects,
> and it is possible that the amount of work is too much for some.
> I'm not sure.
>
>         Finally: I am about to release a replacement collector
> which also does reference counting. Again, the implementation
> works with _ordinary_ pointers.
>

Wouldn't felix fail to garbage collect:

   vector<T*> x;

since the offsets to the pointers in x are not a fixed vector, as required
by gc_shape_t::offsets_a, unless the user could modify the offsets_a each
time x.size() changed?