Re: [boost] Shared_ptr "mini garbage collector"

From: Greg Colvin (Gregory.Colvin_at_[hidden])
Date: 2003-01-07 12:19:12

At 09:23 AM 1/7/2003, Peter Dimov wrote:
>From: "William E. Kempf" <wekempf_at_[hidden]>
>>
>> I think that extending it to free memory in cycles would be a great idea.
>Of course, this opens a large can of worms about how to handle destruction
>of objects which refer to each other...<
>
>One possible approach is to return a list of references to the "offending"
>shared_ptr instances to the user, who can then reset() them as appropriate.
>Actually it's not as simple as that since a reset() can invalidate some of
>the returned references; the shared_ptr instances would first need to be
>copied to a temporary container, the originals reset(), and the temporary
>container destroyed, but the general idea is the same.

Finalization semantics is of course a very big can of worms
that has kept a lot of GC experts arguing for years.  But I
take the success of Java as evidence that getting it right
might not be all that important.

>> I think that full GC is one of the major things missing from the C++
>language, and the appeal of a smart pointer approach, where I pay for GC
>only when I want/need it, is a great idea.<

A smart pointer approach is the only way I know to write a
portable collector, but it is not really the best way to
write a high-performance collector.  My preference is to
have a special new(gc) allocator for collectable objects,
and compiler support for a collector that can scan all
objects for pointers to collectable objects.  If new(gc)
is never called there need be no overhead.

>Making a real "zero overhead" collector is a bit harder, and I'm not sure I
>have the time to do it.
>
>The main requirement is the ability to discover all active counted_base
>objects; currently I maintain a global std::map of their addresses, and
>that's probably not acceptable for production code. A dedicated allocator
>that provides the ability to enumerate allocations may help here.
>
>An additional requirement is to be able to discover shared_ptr subobjects
>and to distinguish a shared_ptr from a weak_ptr; I've used a "magic
>constant" but this increases sizeof(shared/weak_ptr) from 8 to 12 on a
>typical implementation. It is possible to "mangle" the object pointer (by
>XOR-ing it, for example) in weak_ptr and replace the magic constant test
>with a valid pointer test, but I'm not sure whether this is a good idea. :-)

My old cyclic_ptr code is still somewhere on the Boost pages,
and might offer a better solution to these problems.  But I
just haven't had time or motivation to integrate it with
shared_ptr.