Re: is Ada dying?

[minyard@acm.org]

"Martin Dowie" <martin.dowie@nospam.baesystems.com> writes:

> > >Java is not high performance.
> > >It is simply faster than a dial-up network connection.
> >
> > Java these days is very fast, there are many places on the net that shows
> > Java performance getting close or better than C/C++ for some applications.
> > If you are interested I can show you the links, but any search on the net
> > can find you these sites. The performance thing is a weak argument these
> > days when it comes to java.
> 
> Do you have links on embedded, real-time Java performance? I've been
> searching periodically for a while but with little success. Actually,
> no success. :-(

Since I have some experience in this, I'll give my answer.

Real-time does NOT mean fast.  Real-time means guaranteed performance,
like "I can stop the robot arm +/- 100us", or "the air bag will
inflate between 1 and 1.5ms from impact".  True real-time systems tend
to have worse performance than non-real-time systems because providing
the guarantees requires system overhead.  As for performance, Java is
fast approaching C/C++.  Some tests we did on some platforms had C++
and Java within a few percent on just about everything.

Much theoretical work has been done on Java hard real-time
performance, I have a copy of the spec, and it looks reasonable.  You
could build a moderately hard real-time system in Java, if you are
willing to jump through all the right hoops.  But the hoops are
actually rather significant.

The main problem, though, is not with Java itself.  If you use any
third-party libraries, they will almost certainly violate your
real-time constraints.  So you can't use any third-party stuff in your
system, or if you do, it has to be carefully isolated from the rest of
your system.  We used several third-party libraries in our system.
They all were extremely sloppy with memory management; they threw tons
of garbage needlessly.  Plus, because of the slack Java package/class
usage rules, Java software tends to be a "big glob of software", you
generally cannot extract just the parts of the code you need because
everything uses everything else.  Because of lazy initialization
rules, it would be easy for hitting a new path in the code to cause a
mass initialization event.

So the bottom line, IMHO, is that it's not worth it to do hard
real-time in Java.  The big advantage of Java is all the stuff that
comes along with it, but you really can't use that stuff in a
real-time application.  To get true real-time in Java, you have to
manage your own memory and segment your application.  You have to be
very careful with garbage generation.  But if that's the case, why not
write the real-time portion in another language and interface it with
Java?

Note that soft real-time is a different story.  You can probably
implement a soft real-time system in Java if you are willing to do
some work.  Before what I was working on was cancelled, we had a
reasonable system working, and I knew of others that had at least
limited success.  But I know of no practical written material on this
subject, and I doubt any exists, because it's kind of a black art
right now.  And we did a lot of customization to our chosen compiler
to help us meet our goals, including a custom GC and some careful
analysis on how the libraries worked.  So it's still not easy, but it
might be better than using C/C++ due to Java's improved safety.  I
have a lot of knowledge on the subject, but in essence it's only
theoretical because we never actually delivered a product.

But then, I'd rather use Ada.  It has all the safety advantages of
Java (and more) without the baggage of GC, lack of call-by-reference,
etc.  But non-technical reasons often take precedence.  We did a
language analysis on the project in question.  Ada won by a
significant margin, but we chose Java anyway.

-Corey