Re: Ada GC

bobduff@world.std.com (Robert A Duff) writes:


>Henry is unfair, I think, to criticize the designers of Ada 83 for
>ignoring GC. In fact, it is clear from the Ada 83 Reference Manual,
>that it was intended that GC be supported -- in the same sense as in
>Eiffel -- an intent, but not a formal requirement. However, the
>compiler writers did what their customers wanted, which was not to
>support GC. (Again, Henry may think those customers were foolish, but
>that's beside the point.) Why do I say Ada 83 intended GC? Well,
>RM83-4.8(7) explains that storage may be reclaimed when there are no
>remaining pointers to it -- sounds like GC, although the RM calls it
>"automatic storage reclamation". And the deallocator is hidden away
>with the low-level junk in chapter 13. And it's called
>Unchecked_Deallocation (a hint that it should be rarely used, like
>Unchecked_Conversion) rather than a more neutral name like Pascal's
>Dispose or C's free. And there's a pragma (pragma Controlled) for
>turning *off* garbage collection -- to me, that implies that the
>designers intended garbage collection to be *on* by default.


I agree that Ada83 compilers were supposed to have GC, its just that
the compiler writers slacked-off. And I think that customers didn't
want GC is a silly notion. I remember everyone saying "where's the
GC?" Its just that the compiler writers were struggling with all the
language features (like generics), getting performance and validation
and all the problems that come from making a compiler for an obese
language. Nobody implemented GC, thus you can't rely on it for
portable code, thus you didn't use it, thus there was no pressure to
implement it, ....


>Note that GC is not a panacea. You can still have dangling pointers
>and storage leaks. An example of the former: I've seen Lisp code that
>keeps a free list and reuses some objects (presumably for efficiency).
>It's possible to put something on the free list, and reuse it
>incorrectly, when somebody else is still pointing at it for its
>previous use.


This is not "really" a dangling pointer. Its called not using GC and
doing your own memory management.


>An example of the latter: I've seen Lisp and Smalltalk
>code that incorrectly hangs on to a pointer to a data structure that
>is no longer in use; since it doesn't get collected, the system
>eventually runs out of memory. The advantage of GC is not that it
>absolutely prevents these kinds of bugs -- the advantage is that it
>makes them much less likely in practise.


I am fuzzy on this. In an Ada context, is it like programmer is
keeping around data structures that he no longer going to use.
Technically this is not a "really" a storage leak.


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


Thinking about it, my memory of Lisp programs and emacs going away for
long periods during which a "Garbage collecting" message was
displayed, is probably a big psychological (irrational due to there
are better GC implementantions) reason why I and others have not been
jumping up and down and screaming for GC.


I want GC. It would be cool if ARPA would fork over the bucks to put
GC in GNAT.


Jay
--

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