Re: Ada GC (was about Java VM)

dewar@cs.nyu.edu (Robert Dewar) wrote:
> "As a non-expert in hard real-time systems, the last sentence strikes
> me as very strange. There are well-known GC algorithms that guarantee
> hard real-time bounds, as well as reasonable (linear) space bounds.
>
> During the design of Ada 95, it became abundantly clear that this view
> is NOT shared by most experienced practioners in the real time field.


Let's see, RT GC has now been around for almost 20 years (Wadler's
CACM paper was published in Sept. 1976 and my MIT AI working paper was
published in 1977 and received wide distribution). There have been
many different algorithms, and many different implementations.
Symbolics file servers ran for many years (in some cases, literally
without ever stopping -- 365x7x24). Perhaps this isn't real-time
enough for you, but it beats the heck out of many Ada programs that
couldn't run for more than an hour or two without leaking away all
their memory. A certain well-known Ada vendor's compiler (written in
Ada) was configured in the early 1990's for multiple compilations by
multiple users, but found this configuration essentially useless
because it had to be rebooted every 30 minutes or so due to memory
leaks (from TriAda show booth personnel). I asked the Rational people
several times (at a TriAda show) about the Rational (Ada) machine, and
was told it never did have any kind of GC, but simply got rebooted
from time to time when it ran out of memory.


The real-time people have no problem comprehending real-time GC -- you
simply schedule one more task with certain timing and latency demands.
Furthermore, the GC task is remarkably forgiving if you can't give it
its full slot every once in a while. It is true that the GC task does
have to receive a net fraction of effort over some period or the
system will crash, but the real-time designer is usually well aware
that if some of the other tasks don't receive their slots, then the
system will either fall out of the sky or be shot out of the sky, at
which point the success of the GC won't matter any more. So
scheduling the GC task is not particularly difficult or much of a
worry for them.


Now perhaps the experienced practitioners in the real time field were
not involved with the _implementation_ of Ada, but only happened to be
its users. But given the track record of Ada implementors at managing
memory in their own systems, I can easily understand why the real-time
practioners would be scared to death of losing control of this
process.


---


When I originally started looking at Ada, one of my academic friends
warned me against wasting my time. He assumed that it was obvious
that the Ada project was another one of those massive disinformation
campaigns mounted by the U.S. DoD to con the Soviets into spending
themselves to death. He felt that the Ada disinformation campaign was
in the same vein as the English WWII airfields full of mockup fighter
planes, and the 'invisible division' of the WWII U.S. Army (probably
recruited from Hollywood special effects houses) that played the
_sounds_ of tanks and trucks on loudspeakers to fool the Germans.
After all, if the Soviets had copied the IBM 360 and stolen its
(DOS!?!) operating system, then perhaps we could con them into
wasting their precious resources on Ada, as well. (The con must have
worked, too, because I have seen messages from Russians on Usenet
within the last year or two offering what sounded like sophisticated
Ada technology.)


Well, the Soviets have folded their cards, so I guess we can turn off
those loudspeakers now...


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

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