comp.lang.ada
 help / color / mirror / Atom feed
From: rfb@lehman.com (Rick Busdiecker)
To: mg@asp.camb.inmet.com (Mitch Gart)
Subject: Re: Reference Counting (was Re: Searching Method for Incremental Garbage Collection)
Date: Sun, 4 Dec 1994 01:06:01 GMT
Date: 1994-12-04T01:06:01+00:00	[thread overview]
Message-ID: <RFB.94Dec3200602@cfdevx1.lehman.com> (raw)
In-Reply-To: mg@asp.camb.inmet.com's message of Fri, 2 Dec 1994 13:38:57 GMT

In article <D06r8x.JBy@inmet.camb.inmet.com> mg@asp.camb.inmet.com (Mitch Gart) writes:

   In Lisp everything is a pointer.

Ugh.  This statement is simply false.  You *could* implement a lisp
that way, but it would be a bad idea.

Which data types are direct or indirect and when data is boxed or
unboxed varies across implementations, but in any real lisp
implementation, considerable effort is made to manipulate certain
classes of data (numbers, for example) directly rather than indirectly
through a pointer.

   If the following points are true about a reference counting scheme:

   - protects against memory leaks
   - predictable, guaranteed to not stop a program while doing GC
   - costs a bit, in proportion to how heavily pointers are used,
     but the cost is predictable
   - relatively simple to implement

   then RC sounds like a reasonable memory reclamation scheme for Ada.

Yes, if those points were true of RC then it would be a reasonable
scheme.

--
Rick Busdiecker <rfb@lehman.com>      Please do not send electronic junk mail!
  Lehman Brothers Inc.
  3 World Financial Center  "The more laws and order are made prominent, the
  New York, NY  10285-1100   more thieves and robbers there will be." --Lao Tzu



  parent reply	other threads:[~1994-12-04  1:06 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <D06r8x.JBy@inmet.camb.inmet.com>
1994-12-02 17:32 ` Reference Counting (was Re: Searching Method for Incremental Garbage Collection) Henry G. Baker
1994-12-05 20:59   ` Robert Firth
1994-12-06 14:15     ` Robert Dewar
1994-12-04  1:06 ` Rick Busdiecker [this message]
1994-12-04 18:57   ` R. William Beckwith
     [not found] <CzHCvp.9rM@rheged.dircon.co.uk>
     [not found] ` <TFB.94Nov21091959@burns.cogsci.ed.ac.uk>
     [not found]   ` <RFB.94Nov27213114@cfdevx1.lehman.com>
     [not found]     ` <3be0mh$1p7@gamma.ois.com>
     [not found]       ` <3bfprn$okr@scipio.cyberstore.ca>
1994-11-29 21:27         ` R. William Beckwith
1994-11-30  2:27           ` Henry G. Baker
     [not found]           ` <DAG.94Nov30090717@bellman.control.lth.se>
1994-11-30 16:39             ` David Weller
1994-11-30 17:58               ` Erik Naggum
1994-11-30 23:14                 ` Michael Feldman
1994-12-02 23:41             ` Bob Duff
1994-12-03  8:16               ` Bill Birch
1994-11-30 18:59           ` Hans Boehm
1994-12-01  3:20             ` R. William Beckwith
1994-12-01  3:51               ` R. William Beckwith
1994-12-01 13:59               ` Henry G. Baker
1994-12-02  4:26                 ` R. William Beckwith
1994-12-02 21:37               ` Hans Boehm
1994-12-03 15:17                 ` Henry G. Baker
1994-12-09 22:07                   ` Bob Duff
1994-12-11 23:59                     ` Gary McKee
1994-12-12  5:04                       ` Henry G. Baker
1994-12-12 12:46                         ` R. William Beckwith
1994-12-16 19:35                         ` Bob Duff
1994-12-17 20:36                           ` Robert Dewar
1994-12-20  5:24                           ` Henry G. Baker
1994-12-12  9:36                     ` Robb Nebbe
1994-12-13 16:12                     ` Henry G. Baker
     [not found]     ` <3be0mh$1p7@ga <3bii2g$kn2@news.parc.xerox.com>
1994-12-01  4:58       ` Kevin Warne
1994-12-02 21:58         ` Hans Boehm
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox