Re: Ada GC

boehm@parc.xerox.com (Hans Boehm)
9 Feb 1996 14:40:17 -0500

          From comp.compilers

Related articles
[10 earlier articles]
Re: Ada GC redhawk@flash.net (Ken & Virginia Garlington) (1996-02-04)
Re: Ada GC rogoff@sccm.Stanford.EDU (1996-02-09)
Re: Ada GC lph@SEI.CMU.EDU (1996-02-09)
Re: Ada GC ok@cs.rmit.edu.au (1996-02-09)
Re: Ada GC boehm@parc.xerox.com (1996-02-09)
Re: Ada GC ncohen@watson.ibm.com (1996-02-09)
Re: Ada GC boehm@parc.xerox.com (1996-02-09)
Re: Ada GC eachus@spectre.mitre.org (1996-02-09)
Re: Ada GC kennel@msr.epm.ornl.gov (1996-02-09)
Re: Ada GC kweise@pluto.colsa.com (1996-02-09)
Re: Ada GC dewar@cs.nyu.edu (1996-02-10)
Re: Ada GC boehm@parc.xerox.com (1996-02-13)
Re: Ada GC yanowitz@mcet.edu (1996-02-13)
[6 later articles]
| List of all articles for this month |

From: boehm@parc.xerox.com (Hans Boehm)
Newsgroups: comp.compilers,comp.lang.ada
Date: 9 Feb 1996 14:40:17 -0500
Organization: Xerox Palo Alto Research Center
References: 96-01-037 96-02-028 96-02-043
Keywords: Ada, GC, realtime

dewar@cs.nyu.edu (Robert Dewar) writes:


>It is also telling that the ISO C++ standard, which is C++ plus a
>number of significant additions that people felt were essential, does
>not include GC, and as far as I know there was no significant pressure
>for this addition.


I only have second hand information, but my impression is that's not
quite accurate. At least one proposal for GC was made to the committee.
The issue was not considered in much depth primarily because it was
brought up late in the process, and it would have delayed the standard.
My impression is that there is some support for standardized, but
optionial, garbage collection in the future. Stroustrup's latest book
seems to take a position along these lines.


I agree that the politics surrounding this issue sometimes make it a
tough sell. Many people have had negative experiences with GC, both
because some early implementations were not so great, and because
processor speed / memory size ratios used to be much less favorable to
garbage collectors.


It also seems to be rare that people outside the research community
are willing to admit how much time they're spending tracking down
memory allocation bugs. Nobody wants to admit to making mistakes.


I believe that this is compounded by the fact that it is often
possible to avoid storage management problems by using naive
algorithms and data structures. That also gets you around the problem
that the nice library you should really be using probably uses an
incompatible storage management convention. We've all seen the
results of this in the software we use. But it's hard to get back
from "ftp crashes when I give it a long file name" to demand for a
garbage collector.


There are of course also a reasonable number of applications that
really aren't affected much by the presence or absence of a garbage
collector.


Hans-J. Boehm
(boehm@parc.xerox.com)
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.