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

From: Bjarne Stroustrup (bs_at_[hidden])
Date: 2001-05-26 08:34:15

John Max Skaller <skaller_at_[hidden]> writes:

> 
> Larry Evans wrote:
> > I'm also thinking of raising the issue of why
> > Boehm's collector shouldn't be used.  The only reason I can think
> > of is the remote possiblity of misidentifying pointers.  
> 
> 	No. That isn't the reason. While it is a problem
> that some objects may accidentally fail to be finalised
> when Boehm accidentally decides that the object is
> reachable, a far more significant reason is that
> Boehm will delete objects which in fact ARE reachable,
> namely, objects for which the pointers are no longer
> held in main memory, but have been grabbed by an 
> external interface.

Isn't that true for every garbage collector? After its last pointer in the 
universe know to the collector is gone, an object can be recycled.

> 	Using Boehm, you can register these objects
> as roots, and unregister them. But that defeats the
> principal advantage of Boehm, namely, transparency.

But you can't be transparent if you want to keep live objects known only to 
external entities.

> 	A second problem with Boehm is that it is global,
> and as such uses 'world stop' collection. In particular,
> it stops the whole process to do collection, which 
> is very nasty in a muli-threaded environment.
> Last time I looked, there was no portable way to find the stacks
> of each thread (and Boehm was hassling the Posix people to
> fix that). 

Again, this is not a problem unique to a conservative collector.

 
> 	The other major problem is performance.
> Boehm is very space efficient compared to Felix GC.
> However, exact collectors (such as Felix) ought to be MUCH faster,
> since they only examine known pointers, these are assumed
> to point _at_ (rather than possibly _into_) objects,
> for manual collectors, not all objects are
> scanned, and, for instance based collectors, scans only
> cover subsets of memory.

This is theory. One thing that Boehm frequently points out is that conservative 
collector have repeatedly performed better than proponents of precise/moving 
collectors deemed possible. 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.

 
> 	More interesting: once you agree to do 'manual'
> collection, you might go further and be prepared to 
> use a generational collector. These are MUCH faster,
> since the minor cycles only scan recently allocated
> memory, but the cost is that you cannot simply
> store pointer values into variables (you have to tell
> the collector every time you write a pointer).
> 
> 	Generational collectors work well with functional
> programming languages where writes are impossible :-)

Generational collectors provides the largest gains when you produce a lot of 
short-lived objects. In a language like C++, many/most of the objects that a 
generational colletor finds quickly and cheaply are on the stack and therefor 
automatically "collected" even without a garbage collector.

        - Bjarne
Bjarne Stroustrup, http://www.research.att.com/~bs