comp.lang.ada
 help / color / mirror / Atom feed
From: dog.ee.lbl.gov!overload.lbl.gov!agate!spool.mu.edu!yale.edu!jvnc.net!darw
Subject: Re: Garbage collection?
Date: 22 Apr 92 18:55:45 GMT	[thread overview]
Message-ID: <12320@ns-mx.uiowa.edu> (raw)

>From article <1992Apr21.160955.2523@titan.ksc.nasa.gov>,
by mcroberts@titan.ksc.nasa.gov:
>                          I'm curious as to the state of the
> art in automated garbage collection.

Simula 67 (dating from roughly 1968 -- they were optimistic about their
release date) supported garbage collection in a language not radically
different from the Algol to Ada family.  That is, it was in the Algol 60
tradition, with strong typing, block structure, and records and pointers.
(All right, it was also object oriented, with classes and inheritance,
but that doesn't really make the problem any worse.)

I saw a benchmark result in the mid 1970's that showed that Simula 67 on
the IBM System 360 was faster than PL/I on the same machine, and that the
speed advantage was due, in part, to Simula's use of garbage collection.
It seems that Garbage collection allows programmers to ignore the problem
of keeping track of when to deallocate stuff, and this can save more CPU
cycles than are taken by the garbage collector.

Ada and Pascal can clearly be used with similar garbage collection
methodology.

The trouble is that garbage collection cannot yet be used in hard
real-time environments.  The algorithms available today are far better
than the simple mark-sweep algorithms of the 1960's, but even opportunistic
generational garbage collection doesn't guarantee a worst-case response
time per allocation, it only gives an excellent average and a minimum
number of annoying interruptions.

Since Ada is intended for embedded systems, and since many of these are
real-time systems, and since the designers of Ada wanted to maximize
portability of code, there are good reasons not to allow users to rely on
the availability of a garbage collector.  These reasons are not compelling,
however, and the designers of Ada knew it.

The formal definition of Ada allows implementors to provide a garbage
collector if they want to do so.  The problem is that few if any bother to
do it.  Early texts on Ada seem to have assumed that more implementations
would support garbage collection, but the marketplace today doesn't demand
it, so it's largely unavailable.  As a result, later texts include specific
coverage of unchecked deallocation because it is a practical necessity
under most implementations.
					Doug Jones
					jones@cs.uiowa.edu

             reply	other threads:[~1992-04-22 18:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1992-04-22 18:55 dog.ee.lbl.gov!overload.lbl.gov!agate!spool.mu.edu!yale.edu!jvnc.net!darw [this message]
  -- strict thread matches above, loose matches on Subject: below --
2012-04-13 12:14 Garbage Collection ??? ldries46
2012-04-13 13:20 ` Dmitry A. Kazakov
2012-04-13 19:27   ` ldries46
2012-04-13 20:06     ` Dmitry A. Kazakov
2012-04-13 22:49     ` Brian Drummond
2012-04-14  3:21       ` ldries46
2012-04-14 18:21         ` Robert A Duff
2012-04-18  9:07           ` Julian Leyh
2012-04-19 14:36             ` Robert A Duff
2012-04-19 20:26               ` Randy Brukardt
2012-04-20  7:11                 ` Dmitry A. Kazakov
2012-04-21  0:46                   ` Randy Brukardt
1992-04-21 23:48 Garbage collection? Robert I. Eachus
1992-04-21 23:02 Rick Hudson
1992-04-21 21:09 titan.ksc.nasa.gov!mcroberts
replies disabled

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