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
> 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 Stroustrup, http://www.research.att.com/~bs
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk