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

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-05-10 19:52:46

Larry Evans wrote:

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

        I'm using 2.95. (.3 I believe)

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

        Um, can you give an example?
 
> 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).  

        It could, but my 'set_shape' routine just changes the shape,
including the total size, finaliser, and offsets: if we have a store
of a union type, that seems right.

        On the other hand, in Felix collectable _objects_ do not
need to have any special base or virtual function: in principle,
they are derived from type 'frame_t', but the implementation
is just to glue that in front of the object.

        There is a safety problem in the Felix method, that you can
supply the wrong shape to operator new(collector, shape). 
I guess using a base class/virtual function, that this problem can be
avoided.

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

        I'm actually using an STL map now, since I now count how many 
times the user tells the collector to add a pointer as a root. But while
adding a root might be slow, it shouldn't happen all that often.

        In addition, the user can fix that problem easily.
Only ONE root is ever needed, it can be some container
which the user adds other 'notional roots' into. For example,
the user can make a pointer to a pointer to a singly linked list node
the sole root, and then add a new root by simply inserting the new
'root' at the top of the list. So I guess I wouldn't worry about
the cost of adding roots to a set.
 
> 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.

        OK, I'll have a look. HMMM:
---------------------------------------------
make usage
: No such file or directory
: No such file or directory.imk
: No such file or directory/tests/drivers/crc
Makefile:26: *** missing separator.  Stop.
-----------------------------------------
Just try 'make':
-----------------------------------------
root_at_pelican] ~/gcsel>make
: No such file or directory
: No such file or directory.imk
: No such file or directory/tests/drivers/crc
Makefile:26: *** missing separator.  Stop.
-----------------------------------------

        What I'd like to see is a simple example, not a test routine.
For example: how would I make a singly linked list of 10 integers?

        By the way: I kind of like your coding conventions,
but there is a risk you will turn other people off using them.

        Also, even if you use things like Perl while
building your system, it is better to use simple
shell script or makefile if possible when you package
things up for a library. This may not be so good for 
development, but most users just want to build and play. :-)
Remember, some people even use Windows or Mac, so they'll
need to hand compile things to try them out.

        I use a powerful literate programming tool myself,
but I don't expect users to run it to extract the sources
or doco.

> Wouldn't felix fail to garbage collect:
> 
>    vector<T*> x;

        Yes, it will not sweep any object which was not allocated
using new(collect,shape), including any STL part.
 
> 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?

        No, its much worse: STL doesn't use new(collector,shape),
so the dynamic length isn't a problem: fixed length nodes
in STL lists won't get swept either.

        One possible solution is to use a class I haven't provided 
yet: root_handle. This 'reference counts' its argument, by adding
it as a root on acquisition, and decrementing the root
count on release. The root_handle doesn't need to be swept
by the collector, although the object it points to must
be allocated by the collector.

        I haven't provided this yet, partly because I'm suspicious:
it somehow seems to beg the question: if you're able to reference
count like this, why do you _need_ the collector at all?

        In particular, if you ever got circular root references,
the the collector couldn't collect them, because they're 
roots, forever. :-)

        Anyhow, it still isn't clear to me how to _design_
for mixed ref counting/collector use. For the Felix code generator
it is reasonably clear, but that's only one application.

        [In that case, everything Felix constructs is managed,
and stack frames, but not other objects, are ref counted.
OTOH, any C++ primitives the client uses do whatever the client says,
they're not the code generators reponsibility: the client
is required to make them 'act like values']

-- 
John (Max) Skaller, mailto:skaller_at_[hidden]
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net