Re: Ada GC (Norman H. Cohen)
9 Feb 1996 14:18:55 -0500

          From comp.compilers

Related articles
[10 earlier articles]
Re: Ada GC (1996-02-04)
Re: Ada GC (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 (1996-02-09)
Re: Ada GC (1996-02-09)
Re: Ada GC (1996-02-09)
Re: Ada GC (1996-02-09)
Re: Ada GC (1996-02-09)
Re: Ada GC (1996-02-09)
Re: Ada GC (1996-02-09)
Re: Ada GC (1996-02-10)
Re: Ada GC (1996-02-13)
[6 later articles]
| List of all articles for this month |

From: (Norman H. Cohen)
Newsgroups: comp.compilers,comp.lang.ada
Date: 9 Feb 1996 14:18:55 -0500
Organization: IBM T.J. Watson Research Center
References: 96-01-037 96-02-003 96-02-023
Keywords: Ada, GC, realtime (Robert A Duff) writes:

|> Why do I say Ada 83 intended GC? Well,
|> RM83-4.8(7) explains that storage may be reclaimed when there are no
|> remaining pointers to it -- sounds like GC, although the RM calls it
|> "automatic storage reclamation". And the deallocator is hidden away
|> with the low-level junk in chapter 13. And it's called
|> Unchecked_Deallocation (a hint that it should be rarely used, like
|> Unchecked_Conversion) rather than a more neutral name like Pascal's
|> Dispose or C's free. And there's a pragma (pragma Controlled) for
|> turning *off* garbage collection -- to me, that implies that the
|> designers intended garbage collection to be *on* by default.

Indeed, the Ada-83 Rationale discusses garbage collection (using that
term) explictly and extensively.

Section 6.2.2, entitled "Reliability, Efficiency, and Implementation
Issues," asserts, "Unfortunately, there is no method of garbage
collection that is generally suitable to real-time applications." It
discusses the problems with sweeping all of storage once storage is
exhausted, with reference counts, and with a background
garbage-collection process that may be starved. It notes that
systems-programming languages such as Lis and Euclid provide for
explicit storage deallocation in a manner that is type-safe, albeit
vulnerable to dangling references. It even addresses the technique of
avoiding dynamic allocation in time-critical programs: "Confronted
with the dilemma between reliability and efficiency, a possible answer
is to choose reliability and accept the possibility that access types
might not be used in programs that are time-critical. However, there
are cases where access types should be used, precisely because the
application considered is time-critical."

Section 6.3.7, "Storage Management for Access Types," begins, "Unless
specified otherwise, the collection of dynamically allocated objects
associated with an access type will be allocated in a global heap and
may be garbage-collected in some implementations." The section then
goes on to discuss the use of fixed-size collections that can be
allocated on the stack and reclaimed for free when leaving the scope
in which the corresponding access type is declared. The Controlled
pragma is then introduced with the words, "If we want to ensure that
garbage collection is never performed by the run-time system, the
following pragma must be used," and finally unchecked deallocation is
discussed. The discussion ends, "The use of this form deallocation
may therefore be justified by efficiency, but it presents some danger,
and so programs that use it must be written with some care."

I seem to remember that an early version of Ada prohibited the use of
unchecked deallocation UNLESS pragma Controlled was used, but if so,
this must have been an earlier version than Ada 80. Does anyone else
recall such a restriction in Preliminary Ada?

In any event Henry Baker is far more in agreement with Jean Ichbiah
than he suspected in his disappointment that garbage collection did
not become ubiquitous in Ada-83 implementations.

Norman H. Cohen

Post a followup to this message

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