Re: Garbage Collection in Ada

[lars.farm@ite.mh.se (Lars Farm)]

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

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.

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.

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

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


-- 
Lars Farm, lars.farm@ite.mh.se