From: | tmb@best.com--Internet |
Newsgroups: | comp.lang.java,comp.compilers,comp.lang.ada |
Date: | 30 Jan 1996 21:48:59 -0500 |
Organization: | home |
References: | 96-01-100 96-01-123 |
Keywords: | GC, realtime |
mg@asp.camb.inmet.com (Mitch Gart) writes:
| The reason for leaving it out is summarized in 2 words: REAL TIME.
| Ada is meant for real time programs and (pause, put on asbestos suit
| and flame-retardant helmet) GC isn't. [...]
| In the world of embedded real time systems GC cannot be relied upon.
It is pretty well understood how to write real-time programs in the
presence of GC, real-time or otherwise, and it is also pretty well
understood how to implement a real-time GC. Real-time programming
languages incorporating GC already exist and are in real-world use.
Manual storage allocators don't automagically give you real time
performance. Just like you need to implement special, real-time
versions of a garbage collector, you need to implement special,
real-time version of manual storage allocators. With a normal manual
storage allocator, you can get unpredictable, high latencies. Manual
storage allocators have gotten a bit better over the years, but it
wasn't unusual a few years ago for a widely used C malloc to go away
for minutes twiddling its thumbs if you had just the "right"
allocation pattern. In fact, Ada 95 doesn't make all that many
guarantees in these areas either, even though people like to call it a
"real time programming language".
I expect real-time and near real-time support for Java will be quite
good. Consumers get annoyed easily when Madonna gyrates out of sync
with the music, or when there are clicks and breaks in their sound and
animation.
Thomas.
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.