Re: Garbage Collection in Ada

[bobduff@world.std.com (Robert A Duff)]

In article <199610132138291604607@dialup101-6-14.swipnet.se>,
Lars Farm <lars.farm@ite.mh.se> wrote:
>Jonas Nygren <ehsjony@ehs.ericsson.se> wrote:
>
>> Recently there has been some topics that has touched on the issue of
>> Garbage Collection, GC, in Ada. I peronally think it would be great to
>> have GC in Ada and I am not sure why there is such resistance. 
>
>Cultural bias or even prejudice is the most likely reason IMHO. Not
>technical reasons. On and off the same discussion comes up in the C++
>community. Those that control C++ and those that control Ada simply
>don't want GC :-( Being in the C++ world, I can't speak about
>technicalities in Ada, but the arguments from the GC detractors among
>C++ and Ada users appear to be similar. They say that no one wants GC.

Well, "GC is good" and "no one wants GC" are not contradictory.
(Assuming you take "no one wants GC" to be just an exagerated way of
saying "not enough people want GC".)  After all, in the PC world, I've
read several articles about how multi-tasking is useless from the user's
point of view.  Kind of like a driver who knows nothing about how cars
work, saying "Pistons are useless".  ;-)

IMHO, the cultural bias against GC is fueled in part by GC zealots who
claim that GC does more than it really does.  I know for a fact that I
myself took many years to come to the opinion that GC is good for many
(most?) programs, primarily because I didn't believe the zealous
claims.

And I *still* hold the opinion that GC is bad for some kinds of
programs.

>They say that GC is slow and that there are certain constructs in the
>languages that make GC impossible or useless or that this or that
>particular implementation of GC cant work and therefor any
>implementation of GC is out of the question.

This may be true of C++, but GC is quite compatible with Ada.

>One particularly annoying argument goes like: "Memory is a resource, GC
>manages memory so GC should be able to manage any resource. Since it
>only manages memory it fails and is useless". This is nonsense because
>managing memory is a particularly nasty problem and GC solves it almost
>completely. That it leaves all other problems is an advantage, not a
>liability. This is usually called good design, high coherence. GC does
>one thing, one thing only and does it very well.

This might be a symptom of what I was saying above -- if zealots claim
that GC solves all the worlds problems, then it's easy to disprove that,
and therefore write it off.

>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.

I don't understand what you mean by "ordinary allocators".  What you say
is certainly true of off-the-shelf general-purpose allocators, but it's
easy to write an allocator with predictable timing if the objects are
all of the same size, and that's exactly what some real-time programs
do.  And some real-time programs avoid using the heap at all, so of
course GC is just a waste of implementer's time, for *those* programs.

I know about Henry Baker's papers on real-time GC, but I remain somewhat
skeptical.  (I suspect most real-time programmers have never heard of
real-time GC, and would scoff at it.)

>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 Ada, this is true.  In C and C++, I don't believe it -- I've seen
lots of code that uses pointers/arrays in a GC-unsafe way.  Perhaps it
doesn't *need* to, but it does.

>... 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.
>
>For Ada one of the technical obstacles mentioned is something called
>"virtual origin". A block of memory held by a biased pointer that points
>at some distance outside the block. Presumably a compiler optimizer
>trick allowed by the language. That seems like a harder problem than the
>problems in C++ and that in turn is ironic. 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++. 

To me, this sounds backwards.  Virtual origins are a useful
optimization, and if they break your GC, then your GC is broken.  It's
not the compiler's fault.  It's certainly possible to implement a GC
that works in the presence of this optimization.  And there are many
other examples of optimizations that will break the typical
"conservative" GC, but a proper non-conservative GC can work properly.
The term "conservative" is bogus, IMHO, since if you do certain things
in your code, or your friendly compiler-writer does certain
optimizations, it makes the GC *liberal* -- that is, frees in-use data.
Avoiding certain things in my code is tolerable, but it makes me nervous
to think that the new version of a compiler, with a smarter optimizer,
might come along and break the conservative GC.

>None of the arguments above has convinced me that GC is a bad thing and
>I'm perfectly willing to avoid some weird C++ language constructs if it
>gives me GC. It would be interesting to hear what other arguments the
>Ada vendors could come up with.

No, Ada vendors are not typically part of the anti-GC crowd.  The
vendors tend to say, "GC is somewhat hard to implement, and we don't
have a lot of customers asking for it."  It's kind of unfortunate,
because there are probably quite a few people who *would* use Ada, if
Ada compilers with GC were commonly available.  Probably this situation
will change in the future.

>... It would be even more interesting if
>they could say something like "Sure GC is possible, but you'd have to
>sacrifice language feature this or that" and then leave the choice up to
>the users.

There's really not much you have to give up, unless you're dealing with
a so-called conservative GC.

By the way, the Intermetrics compiler that generates Java byte codes
supports GC (the non-conservative GC supported by Java), and I believe
somebody is working on a conservative GC for GNAT.

- Bob