Re: Ada GC and a bunch of other stuff

bobduff@world.std.com (Robert A Duff) wrote:
> Henry mentioned the Symbolics Lisp machines as an example -- he said
> they would stay up for years on end. Well, my experience was a bit
> different. I complained about certain programs being horribly slow,
> due to GC overhead (the GC would page in huge amounts of stuff from
> the disk (sometimes across the network) in order to collect that
> stuff!). The folks at Symbolics told me to do what they do -- turn
> off the GC, and when the machine starts getting close to running out
> of memory, reboot it. That meant rebooting *at least* once a day.
> (To be fair, the GC algorithm improved in later years, to the point
> where it may have been practical to use routinely, but I stopped using
> Symbolics machines around that time.)


I think you have to compare apples with apples, not with oranges. By
today's standards, early Symbolics Lisp machines were grossly short on
RAM. If I remember correctly, you could get one of the first machines
with only 2 Mbytes of RAM on it. If you can even find a workstation
with equivalent capability in terms of SW, etc., today, it will likely
have 64 Mbytes or more of RAM on it. With today's (slightly) faster
disks, and today's complement of RAM, I suspect that your experience
would be somewhat more favorable.


I have heard that the Sun machines used in Desert Storm had something
like 256Mbytes or 512Mbytes of RAM each. I don't know whose Lisp they
were running, but they were apparently used in a 'real-time'
situation.


I used the Symbolics example merely to point out that _within its
design parameters_, this file server was 'real-time'. As real
'real-time' people know, 'real-time' doesn't necessarily mean _fast_,
but _low latency_. In fact, there are many examples where _low
latency_ means _not so fast_. In other words, you often have to give
up absolute speed in order to guarantee short latencies.


------


Someone mentioned the issue of the interaction of GC with compiler
optimizations. David Chase has probably studied this more (at least
in the last several years) than most everyone else, and has published
papers on this (ACM PLDI, 1988??).


I would argue that many of the same issues come up with _any_ kind of
memory management, not just GC. For example, a _single_ bug in a
compiler optimizer for C++ constructors and destructors will either
lead to storage leaks or crashes. Yet I am constantly amazed by the
number of C++ bugs of this sort that I find. I can only conclude that
there are a lot of applications out there that leak or crash from this
one source alone. Assuming that a GC avoids the use of
constructors/destructors to keep track of 'roots', such a GC may be
more reliable than the same application using reference counts. Until
C++ standardized exceptions that unwound destructors correctly, a
program which depended upon reference counts was actually at a severe
disadvantage to one which depended upon GC. I suspect that even now,
there are many exception bugs in C++ compilers & run-time systems
which leave refcounted applications at risk, whereas a proper GC would
not require quite as much from the compiler.


------


I believe the fundamental flaw in Ada is not the language, per se,
since that is the necessary result from the _process_. _The
fundamental process that developed Ada is flawed_, because it
attempted to standardize something that very few people had any
experience with. The Ada95 process had a lot more testing than the
Ada83 process, but the rush to standardization was still a rush to
standardization. If _de facto_ standards are the important ones, then
why the rush to an ANSI/ISO standard?


The advantage to standardization is to avoid excessive variants of
_functional_ components. But this advantage is completely lost and
the community is in _worse_ shape if the components aren't even
functional. I'd rather have 3 functional choices and deal with a
little excess complexity from this source, than have _no_ functional
choices at all.


------


The problem with Ada not having GC is that languages like Ada which
incorporate both expression-orientation and statement-orientation
_must_ hide some mechanisms in order to provide the 'higher level' of
expression that 'expressions' provide. However, if you hide
something, then you are now responsible for it, and Ada83 abdicated
this responsibility. Ada83 had a 'catch-22' -- the programmer is
responsible for storage management, but the language didn't provide
him/her any mechanism to implement this responsibility with respect to
a wide variety of expressions in legal Ada83. For example, the
programmer has no control at all over the storage management of
Ada83's 'unconstrained' objects, and using these I have been able to
implement large complex data structures such as infinite precision
integers and algebraic data types without once calling 'new'.


It is no accident that Modula and Eiffel both chose garbage
collection, since the alternative of trying to specify 'hooks' for all
the places where the _language implementation itself allocates storage
dynamically_ would be a monumental job.


C++ should be lauded for trying to give the programmer control over
nearly everything that smacks of 'hidden mechanism', even though
providing this control allows for some of the most 'obfuscated'
programs ever written.


("Why doesn't C++ have an 'obfuscated C++' contest?" "Because every
single program would be a winner!" :-)


But if Ada is serious about providing both 'high level' _and_ control,
then it would appear necessary to give the Ada programmer precise
control over every previously hidden mechanism. If this means that
Ada programmers will have to be trusted to some degree, then so be it.


------


Ada83 got off on the wrong foot by trying to legislate programming
style. There are quite a number of restrictions in Ada that have
nothing to do with programming semantics, or safety, or anything
substantive. They were put there because someone thought that the
result would be more stylistically correct _in their opinion, at that
particular point in time_. For example, there are silly restrictions
on the spelling of identifiers that require additional code to check
for, and clutter up the manual and the compiler. There used to be
silly restrictions on the ordering of certain kinds of declarations,
but most of these were dropped in Ada95. I believe that there still
are in Ada95 silly restrictions on the ordering of 'private' and
'public' parts of a 'specification' (C++ people: think 'class
definition') whose rationale is incomprehensible to a C++ programmer
accustomed to putting 'public:' and 'private:' anywhere that is
convenient.


This last rule may appear to be merely a stylistic rule, with no
substantive effect. This is not true, however, since other ordering
rules conspire with this one to eliminate the ability to define
certain relatively simple types in a single package. By forcing the
programmer to utilize a number of subsidiary packages -- whose only
purpose is to get around the silly ordering rule -- the original
rationale of the ordering rule -- 'prettier programs' -- has now been
completely turned on its head. The public/private ordering rule
_forces_ the programmer to engage in the very behavior it was meant to
prohibit!


I didn't mean to be so long-winded, and there are plenty of other
examples of this kind I could bring up. The bottom line is that
_stylistic rules have no place in a language standard_. Styles change
at a very much more rapid pace than language standards do, and those
arbitrary stylistic rules do not wear well on competent programmers.


If you want to enforce stylistic rules, write a style-checking
compiler, but please don't clutter up the language standard or the
production compiler with this excess baggage. It's difficult enough
to get the compiler to do the right things without adding extraneous
work that _reduces_ the functionality of the language.


--
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html
--

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