Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!uxc.cso.uiuc.edu!uxc.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!johnson
From: johnson@p.cs.uiuc.edu
Newsgroups: comp.sw.components
Subject: Re: Real-time Garbage Collection
Message-ID: <130200011@p.cs.uiuc.edu>
Date: 19 Sep 89 14:53:00 GMT
References: <6488@hubcap.clemson.edu>
Lines: 46
Nf-ID: #R:hubcap.clemson.edu:6488:p.cs.uiuc.edu:130200011:000:2734
Nf-From: p.cs.uiuc.edu!johnson    Sep 19 09:53:00 1989


> Written  6:21 am  Sep 18, 1989 by billwolf%hazel.c@hubcap.clemson.edu 
>  Now the advocates of GC frequently claim that space management is
>  too heavy a burden to be placed on the application programmer, and
>  this may well be true.  However, there is a much better way to deal
>  with this problem.  All that is necessary is to encapsulate the
>  details of storage management within abstract data types, such that
>  the destruction algorithm is integrated into the block exit mechanism.

>  By doing this, we place a level of abstraction between the application
>  programmer and the details of storage management.  The use of pointers
>  is confined to the ADT's implementation, and the application programmer
>  is shielded from all the resulting complexities.  The interface also
>  simplifies the work of the ADT's implementor; the destruction algorithm
>  is usually quite straightforward.

Bill Wolfe is being hopelessly idealistic.  I've used C++ a lot, which
takes the approach that he advocates, and there are many times when it
is very hard for an ADT to figure out when to destroy an object.  Moreover,
memory management is the source of many bugs and takes a lot of programmer
time to get right.  In general, we want to avoid programming language
features that encourage bugs and cause programmers to spend a lot of time.
C++ programmers tend to minimize using dynamic memory management as much as
possible, and it is probably partly for this reason.

Moreover, there are times when memory management would be more efficient
if it were implemented by the compiler instead of by the programmer.
For example, C++ programmers use reference counting a lot, and there are
a number of algorithms by which even stupid compilers can eliminate a
lot of reference counting.  Of course, programmers can perform these
optimizations by hand, but I believe that compilers should be in charge
of optimization, not programmers.  Most languages with garbage collection
are implemented by interpreters or by very simple compilers, and so we
haven't seen much optimization of memory management, but we will in the
future, as more and more languages include garbage collection.

Many garbage collection systems are quite efficient.  For example,
some generation scavenging systems have a 3% to 5% overhead.  The
problem is that the efficient systems are not real-time, and the
real-time garbage collection algorithms are not efficient.  The
algorithm by Appel et. al. in the '88 SIGPLAN programming language
implementation conference is supposed to be both, but I am not sure
that it has been ever been used in a real-time environment.  In any
case, there were no timings given, and "real-time" is always relative.

Ralph Johnson