Re: [boost] request for interest in a garbage collection library

Subject: Re: [boost] request for interest in a garbage collection library
From: Gregory Peele ARA/CFD (gpeele_at_[hidden])
Date: 2009-04-21 09:33:39

To chime in with a couple thoughts (I'm not expert on the topic though.)

Doesn't Java deal with finalization issues in a sane way?  If I recall, they guarantee that finalize() will be run at most once on an object after it becomes unreachable, but an object in a reference cycle isn't actually destroyed and collected until all objects in that cycle have been finalized (or more technically when there are no more active references to that object, including other objects pending finalization.)  I have no clue how hard this would be to implement in C++ or even if it makes sense to try, especially as finalizers are intended to catch cases that are better addressed with RAII.  Even in Java, they are discouraged in favor of try / finally clauses.  Java also permits the finalizers to make the object active again, which I think is a rather pathological case.

In favor of garbage collection in general, though - for some use cases, especially those that don't use non-memory resources, it makes a lot of sense.  The Boehm guys claim that garbage collection can be a significant performance win for workloads involving large numbers of small objects, as compared to C++ new / delete - especially in multithreaded environments.  It can also greatly speed up prototyping complex geometric or graph data structures, where reference counting (especially non-intrusively) is a huge performance / memory hit and playing the game of "who owns the pointer?" takes more time than actually developing the algorithm for your problem domain.

Just my $0.02.

Gregory Peele, Jr.
Applied Research Associates, Inc.

-----Original Message-----
From: boost-bounces_at_[hidden] on behalf of Jonas Persson
Sent: Tue 4/21/2009 5:25 AM
To: boost_at_[hidden]
Subject: Re: [boost] request for interest in a garbage collection library
 
Achilleas Margaritis skrev:
> But gc'd objects are are not supposed to touch other gc'd objects in 
> their destructor (if you check the readme, I explicitly say that the 
> order of finalization is random). Is there a realistic need to call 
> another gc'd object from a destructor?
> 
This isn't about random finalization. It is about that if I have a 
reference to a gc object I want to be able to rely on that it is alive 
until I release it. I dont want it to be removed under my feet because I 
was choosen as the random victim in a circular dependency break up.

A gc object touching other gc'd object in the destructor may not be 
common, but the same problem appear even if that other gc object is 
accessed inside the destructor of any contained child object or indeed 
any function called by any destructor in any object in the dependency 
graph. This is not going to be easy to see.

I think you would need to add some sort of guards against this usage, 
like assert if any gc_ptr is accessed during garbage collection as Esben 
proposed.
But even then you have to be careful because that will not detect 
everything. For example shared_ptr members is often used to make sure 
that the lifetime of objects is extended long enough and never accessed 
directly. Dropping in gc_ptr in that case will bite you hard.

As I have seen so far, I think the only safe usage of gc is to require a 
no circular dependency design.
This is all general issues with garbage collection, and not specifically 
about your implementation. I dont really want to discourage you from 
continue your efforts to build a gc library, but to be useful in a C++ 
context all this has to be solved somehow.

   / Jonas

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost