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

From: Larry Evans (jcampbell3_at_[hidden])
Date: 2001-05-10 20:58:21

John Max Skaller wrote:

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

See .../drivers/crc/NoSubjProx.hpp:class Subj2.  At main.cpp:59 it's instantiated
with GcMethod == SubjTop_test == subjtop_lazy_crc.

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

OOPS.  Sorry, I didn't look hard enough for that.

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

Yeah I thought of that too, but was afraid people would think it too restrictive or
too easily forgotten.   It just seem too easy for a programmer to declare:

     vector<ProxOwnBtm<simpmsw_zomsafe,int> > x;

On the other hand, I guess you could warn the programmer (as I think you've
said above), to place a pointer to x inside a designated root pointer.  However,
this is similar to the idea behind the subjprox_vec template class.  Note the comment
below the protected cont_elem CTOR.

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

OOPS.  Are you using gnu make?

To help you make your own makefile,
just take the .cpp files from the 2nd column of the release.log files in the
drivers subdirectories.

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

My "gc_sel_ssp" method can't do integers.  It can only do something derived from
a template class.  For example, the  simple Subj2 class mentioned above
or the Subj1 class.  An example of a vector of Subj2 is shown at main.cpp:22.

I think it would be easy to adapt gc_sel_ssp to allow any class to be
gc'ed by using the Felix  method, but instead of having the programmer
specify the offsets, they could be calculated automatically as explained in
my previous post.

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

Yes.  I've received comments before about starting a line with
';', but it really makes more sense because it more closely reflects
the tree structure of the code, if have trees growing left to right instead
of bottom to top.

>
>
>         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 guess I'll just use release.log to generate a more acceptable
Makefile for my next boost upload.

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

I don't understand.  I'm thinking you mean root_handle store's a pointer
to itself in a set of roots (i.e. add it as root on acquisition).  By
"decrementing the root count" do you mean remove the pointer for handle
from the set of roots?  If so, then this is what the
ProxBtm<  ,  ,boost::gc_sel_ssp::root> specialization does.  See
boost/gc_sel_ssp/general/detail/off_root.hpp.

You may be confused by the differences between the class names
in the documentation and that in the code.  The documentation was made
before I "boostified" the code (e.g. by making all class names lowercase).
I'll boostify the documentation too, but I don't know when.

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

Root pointers are not needed by the code in the crc test directory.  For
the other gc method, simpmsw_zomsafe, they are, since simpmsw_zomsafe
is the classic mark sweep method.