Re: Garbage Collection in Ada

[John Howard <jhoward@sky.net>]

On Sun, 13 Oct 1996, Lars Farm wrote:
[snip]
> managing memory is a particularly nasty problem and GC solves it almost
> completely.
[snip]

GC just provides *automatic* deallocation of "unreachable" dynamically
allocated objects.  GC is not cost-free.  Ada 95 flexibly provides a
programmer with capable mechanisms to manually manage memory.  Plus the
safeguards of Ada help minimize creating slop to clean up and so the
deallocation can likely be managed easily enough manually.  I am not 
against using GC if its reliability is guaranteed and it saves me some 
money.  Otherwise I prefer to manually control the deallocation.

> Another common nonsense argument against GC is real time behaviour. GC
> is no different than ordinary allocators. They have no time constraints
> either. If one needs absolutely predictable timing one has to manually
> take over memory management for that section of code with GC and with
> ordinary allocators anyway.
>
> As for C++ the GC-dangerous constructs are very few and very obscure and
> luckily rarely used and easily avoided. Using them usually invokes
> "undefined behaviour" anyway (deliberately hiding pointers from the GC -
> on disk or with various xor tricks,...). In practice GC (conservative
> collector by Boehm) works very well with C++ and in my experience is
> faster than ordinary new/delete. If one also uses the fact that one has
> a GC in the design, things become faster still. Less need to copy
> datastructures (there is a lot of redundant copying in C++ out of fear
> that one wont know when to release memory otherwise). Granted, the speed
> is not just because of GC, but also because Boehms GC (that I have used
> in C++) is a much better allocator than the ones delivered with my dev
> systems.

You argue that GC is already worthwhile for the culture of C++ 
programming.  Perhaps it is most cost-effective if an operating system
does GC instead of having several programs doing their own GC.  That seems
to be a goal of the Java Virtual Machine.

[snip]
> Ada allows GC, C++ doesn't even acknowledge its existence.  One would
> have thought that the stricter Ada would be easier to adapt to GC than
> the "sloppy" C++.
[snip]
> Lars Farm, lars.farm@ite.mh.se

I argue that GC is far less worthwhile for the culture of Ada programming.
(Similarly Ada spared us from needing an equivalent C Lint program to 
clean up code).

From "Ada as a Second Language" (2nd ed.) by Norman Cohen, ISBN
0-07-011607-5, McGraw-Hill:
Section 8.2 p. 328
"
  The rules of Ada also allow "garbage collection"---automatic
  deallocation of dynamically allocated objects that are no longer
  pointed to by any other variables in the program, that are pointed
  to only by other dynamically allocated objects that are themselves
  no longer pointed to, and so forth.  Such objects are said to be
  unreachable because there is no way to refer to them. [...] Some
  implementations of garbage collection continually slow down a
  program's ordinary computations; other implementations are not
  invoked until the program needs more storage, at which point all
  ordinary computations are momentarily halted while the garbage
  collector does its work.  Either behavior is usually unacceptable
  in a real-time program.  Therefore, Ada provides a pragma allowing
  you to ensure---in the unlikely event that your compiler supports
  garbage collection---that the garbage collector will not get
  invoked.  The pragma Controlled ( access-type-name ); ensures that
  objects created by allocators for the named access type will not
  be garbage-collected. [...]

  There are many possible data structures and algorithms for managing
  the storage to be used for dynamic allocation and deallocation.
  One scheme may use up more space but take less time than another.
  The performance of some schemes may depend on the patterns of
  allocations and deallocations requested by your program.  [...]
  But certain highly tuned programs may require special
  storage-management schemes tailored to the application.
  Section 19.5.1 will describe advanced mechanisms for specifying
  programmer-defined subprograms to be invoked by the evaluation of
  an allocator or a call on an instance of Ada.Unchecked_Deallocation.
"
-- John Howard <jhoward@sky.net>               -- Team Ada  Team OS/2 --