[gclist] Two conservative collectors

Michael Spertus mps@geodesic.com
Mon, 22 Nov 1999 10:32:12 -0600


At 06:05 AM 11/20/99 -0500, gclist-digest wrote:
>
>Date: Fri, 19 Nov 1999 12:05:45 -0500 (EST)
>From: kragen@pobox.com (Kragen Sitaker)
>Subject: Re: [gclist] Two conservative collectors
>
>Charles Fiterman writes:
>> Its not good enough for a GC but C++ users use our GC primarily as a
>> debugging tool. We have multiple libraries some of which use debug info and
>> some don't.
>
>Someone posted here not long ago saying that 50% of Geodesic's
>customers buy GC planning to ship with it, and 90% actually do ship
>with it.  How does this relate to your statement above?
>
I posted that. The explanation is interesting. In fact, the majority of our
customers use GC both as a debugging tool and as a deployment tool.
However, they generally do not use it to program in a garbage collected
style. As a result, they try to manage memory by hand as well as possible,
and use our GC's debugging mode to help with that, then they deploy their
application with GC as an "insurance policy" against any remaining memory
leaks. This use of GC as an insurance policy against memory errors rather
than to support GC-aware programming idioms, is as far as I know unique to
C/C++.

>(As an aside, if you're using debugging info to decide what's not a
>pointer, and the debugging info is as bad as you and Hans say, then GC
>will erroneously free things.  This will change it from a debugging
>tool to an enbugging tool. :)
>
This is only one reason why using debugging info is only suitable for using
GC as a debugging tool only. For deployment, one would probably have to
revert to a conservative stack scan. As an interesting note, if one is
deploying with GC as an insurance policy, excess retention is not an issue
because only a small percentage of allocated memory needs to be reclaimed
by GC. i.e., elimination 99% of the remaining leaks will make the customer
very happy. However, any premature collection indeed makes GC an "enbugging
tool" as you point out. For this reason, our default configurations focus
much more effort on safety even at the expense of excess retention
(although we take both seriously).

Michael Spertus                            mps@geodesic.com
Geodesic Systems                           (312) 832-2039
414 N Orleans, Suite 410                   http://www.geodesic.com
Chicago, IL 60610