Re: Re: [boost] Shared_ptr "mini garbage collector"

From: Greg Colvin (Gregory.Colvin_at_[hidden])
Date: 2003-01-07 15:08:32

At 11:04 AM 1/7/2003, William E. Kempf wrote:
>> From: Greg Colvin <Gregory.Colvin_at_[hidden]>
>> 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.
>
>The "Java solution" is to not have a solution.  Finalizers need never be called in Java.

Right.  You need finally clauses for most resource management.
A GC for C++ could just as easily never call destructors, and
provide a separate mechanism for optional finalizers.

>  I'd prefer to always call the destructors, with the knowledge that dereferencing a GC pointer that's participating in a cycle during the destructor results in undefined behavior.  I can usually avoid doing this.

That is one reasonable approach.  The collector can make it
easier by providing a topological sort of the soon-to-be-dead
objects, so that you can safely dereference pointers in the
destructors.  But then you have to do something else for cycles.
Like I said, the GC experts have been discussing this for years
without any clear resolution.

>> >> 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.
>
>Creating an efficient GC system is tricky, yes, but I don't see why a smart pointer approach can't be just as efficient as a compiler solution?

It probably can be, but the literature so far indicates that
it isn't.  A collector that has compiler support and knows
all about how the stack and heap are laid out and can take
advantage of the virtual memory hardware and so on has a big
advantage.  It's also nice to be able to use raw pointers to
collected objects.

Still, a portable smart pointer GC would be nice to have, as
it will take years of work to see GC added to C++, if it ever
happens at all.