Re: [boost] Smart pointer status, directions, thoughts

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-05-26 18:09:10

From: John Max Skaller <skaller_at_[hidden]>
> Bjarne Stroustrup wrote:
> ...
> > >       A second problem with Boehm is that it is global,
> 
> > Again, this is not a problem unique to a conservative collector.
> 
> It remains a disadvantage, whether or not it is unique.
> It is also a disadvantage of Greg Colvins cyclic_ptr, on the other
> hand my Felix GC system is instance based, and so if one
> has an instance per thread (for thread local storage only),
> then only the thread gets stopped. 

At this point cyclic_ptr is a toy, whereas Boehm's collector
and it's commercial derivative (Great Circle) are serious
production tools.  I'm not sure where Felix fits on this
spectrum -- but I take it is more than a toy.

As for being global, that can be an advantage, as you don't
have to worry about passing pointers from thread to thread.
The last time I wrote a thread-safe global allocator (which
cyclic_ptr is not) there was almost no measurable overhead
for handling multiple threads.  But of course I needed some
assembly language to pull that off.

> I will add that the collector that comes with the Ocaml
> system I'm using is generational and incremental.

As for stop-the-world versus incremental, there are advantages
and disadvantages both ways.  Stop-the-world usually gives
better overall performance, incremental usually gives better
responsiveness.  But if the heap size can be bounded so that
the world is never stopped for too long then you don't need
incremental collection.

Ocaml, like many such languages, generates huge amounts
garbage in the normal course of operation, much of it short
lived, so generational collection is an advantage.

> [performance]
> > This is theory.
> 
> That is correct. I haven't done any measurements.
> 
> > One nice thing about a conservative collector is
> > that it doesn't impose a cost on ordinary use of objects - such as requiring
> > than every object be accessed through a pointer to its first element or
> > requiring that every object contain space for use by a garbage collector.

Or requiring the use of smart pointers in place of raw
pointers.

> Yes. I agree. And one of the nasty things is that
> you cannot rely on it to release objects, which makes
> resource release by finalisation problematic.

Resource release by finalization is always problematic, no
matter what language and no matter what collection strategy.
IMHO of course.

What you really want for C++ is to not call a destructor for
an object until everything that object points to has been
destroyed.  But that is impossible if there are any cycles.
Reference counting destroys in this order, which is a one of
nice things about it.  And reference counting won't collect
cycles, which is one of the not-so-nice things about it.

My cyclic_ptr is an experiment in combining reference counting
and mark-sweep to get some of the advantages of each, but it
is too soon to say how successful it is.  I take it that Felix
is a similar experiment.

As I recall, Ellis and Detlef's had a modification of Boehm's
collector that did a topological sort of the finalizable
objects that they proposed for standardization, but I'm not
sure what came of it.  My feeling is that the standard will
be hard-pressed to impose any requirements on finalization
order or timeliness without unduly constraining implementers.

I'm not sure this is really important, since I see big systems
succeeding in java with no useful finalization guarantees.  They
work either by limiting resources to method scope with finally
clauses, or by multiplexing a small pool of resources that are
released at program exit.  Garbage collection is for memory.