Re: Ada GC

bobduff@world.std.com (Robert A Duff) writes:
>Henry Baker decries the fact that real-time GC has been around for 20
>years, and yet Ada still doesn't require its use. Well, it may have
>been around for 20 years, but the fact is that it is not in widespread
>use among real-time folks (though there are exceptions).


Chicken-and-egg. They didn't use it because it wasn't supported and
it isn't supported because they didn't use it. Now, if there's a
program my life depends on, I want to be _sure_ that it won't run out
of memory, so there are places I don't want to see GC being used.
Apart from that, try giving real-time programmers a programming
*system* that supports GC with guaranteed bounds, and *then* draw
conclusions if they don't use it. Erlang has already been mentioned.


By the way, there is a possible compromise. Scheme is a language
which normally uses a garbage collected heap. The Stalin compiler
tries to turn as much of this into stack allocation as it can. One
could imagine writing in Scheme, then saying "this bit is safety
critical; turn 'had to use heap allocation' into an error message".
This brings us back to the theme of comp.compilers: garbage collection
is not just a RTS issue, it is not something could can bolt onto the
back of any old C compiler (pace Boehm, to whom be braise) because a C
compiler can legally do all sorts of horrible things to you. A
GC-aware compiler, like the Stalin compiler, can turn source heap
allocation into object static or stack allocation sometimes; can
generate code that relies on knowing what the garbage collector will
do (e.g. not bothering to initialise a field if the garbage collector
won't run until after the next assignment to that field), &c.
--
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
--

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