Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!hplabs!hp-pcd!hplsla!jima
From: jima@hplsla.HP.COM (Jim Adcock)
Newsgroups: comp.lang.c++
Subject: Re: GC (was Re: Eiffel vs. C++ (vs Smalltalk))
Message-ID: <6590163@hplsla.HP.COM>
Date: 21 Jun 89 17:58:52 GMT
References: <14739@duke.cs.duke.edu>
Organization: HP Lake Stevens, WA
Lines: 37

I started playing with Boehm's garbage collector yesterday, and found it
easy [dare I say "trivial"] to get it running with C++.  It took maybe 2 hours
for me to get up to speed on this with C++.  I think many people will find this
an entirely suitable GC for many C++ applications where traditionally one
would want to use GC.  Clearly, the 2.0 features ark has been talking about
in terms of "new" and "delete" overloading are what one wants to be able
to hook in various memory management schemes.  On my mid-range 68020 
system GC took 1-3 seconds on a couple meg of heap with a few thousand
"lost" objects floating around.  Your mileage may vary.  Boehm's GC worked
well even when I was deliberately very malicious to it -- filling up my
objects with random numbers many of which might very well look like pointers.

If you'd like a copy of the couple little files I needed to write to do
this, please ask. [These files are not "publication quality", but would
provide good hints to get you started.]

Boehm's GC clearly isn't the solution for people with strict real-time
needs.  It would be nice if some C++ specific hooks could be placed in the
GC to allow a virtual destructor to be called [where applicable] when such
a C++ object is found.  Right now when a "lost" object is found, no destructor
is called [which is really pretty reasonable, since you lost the object in
the first place.]  Even if the GC was modified to call the appropriate
destructor, you'll still have no guarantee that destructors are called in
the order you might like.  So destructors with side effects might still 
be problematic.  Still, I think this is about what one can reasonably expect
from a GC.  As it stands, the GC is fine for traditional situations where
one loses track of objects -- lisp-like cells, binary math ops that need
to create temporaries, etc.

"Obviously," Boehm's collector is exactly what one needs to "solve" [patch]
the problem that Johnson mentions where a program runs for a couple days,
months, or weeks, and "suddenly" springs a leak. 

On my system the entire GC archive is about 32K.  In a program that just
filled objects with random numbers then "lost" track of them, memory 
allocation, management and garbage collection took about 10% of the total
execution time, with the GC's marking routine taking most of the time.