Boost logo

Boost :

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
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:

Boost list run by bdawes at, gregod at, cpdaniel at, john at