Real-Time Java: Where the rubber meets the road in low-level embedded development
StoryApril 02, 2008
Dr. Kevin Nilsen
Atego Systems
As a high-level programming language supporting object-oriented abstraction and scalable composition of software components, Java is ideal for development of user interfaces and application software. However, it is less obvious how Java software can most effectively address low-level concerns that are typical of embedded software and often programmed in C. New hard real-time Java technology, however, is targeting the specialized needs of low-level embedded real-time development ? and beating out the hybrid C-and-Java mixed language approach.
Embedded systems vary as much as the people who build them
and as much as the underlying execution engines on which they execute.
Similarly, when it comes to selection of Java runtime environments for
low-level real-time computing (where the ìrubber meets the roadî), a
one-size-fits-all solution is not viable or practical.
Among existing virtual machines claiming support for
real-time garbage collection, each offers slightly different capabilities,
representing varying degrees of compliance with soft real-time deadlines where
memory constraints and virtual machine footprint are irrelevant. A smaller
number of virtual machines can handle lower-level requirements, where hard
real-time deadlines, execution speed, and memory footprint are much more
important. Usually, these virtual machines co-exist with an underlying
operating system or RTOS that manages the underlying hardware services. But,
the fact is: Sometimes this just isnít good enough. Sometimes, Java software
needs to reach beyond the hardware abstraction layer to talk directly to
hardware devices.
In a world where Java is increasingly considered as the
language of choice, having a virtual machine technology with complete
application coverage, top-to-bottom, can be a significant advantage. Many
embedded Java applications are built using a two-language approach. Java is
used for the larger, more complex and more dynamic portion of the application
while C is used for lower-level functionality such as device drivers or
portions of the application where faster throughput is required.
The impact of that choice results in awkward and
unpredictable transitions via a Java Native Interface (JNI) that links the Java
and C applications together. Why people do this is obvious: traditional virtual
machines are too large, too slow, and too unpredictable to handle low-level
execution. Accordingly, newly available hard real-time Java technologies now
make it possible to use the Java language instead of C to address low-level
real-time concerns. Compared with the JNI technology, this same hard real-time
Java technology also offers superior performance and robustness for connecting
traditional high-level Java code to low-level C code. As shown in Figure 1,
hard real-time Java can now replace C code for the implementation of device
drivers that communicate directly with hardware. This allows a Java-only
continuum, ranging from 1 to 10 second response times for full-fledged Java,
all the way down to 10 microsecond response times for hard real-time Java,
where itís needed to address hardware line speeds.
Figure 1
(Click graphic to zoom by 1.4x)
|
|
Replacing C with Java
The weaknesses of the mixed-language approach are several
fold. First, the JNI protocol extracts a high toll every time the application
software crosses the boundary between Java and C execution. This protocol
overhead, which may more than double the cost of the executable code, defeats
many of the performance benefits of using the C language for certain
performance-critical parts of an application. Second, and more importantly, the
Java security model is compromised by introduction of C code into the
application. In a large number of embedded Java applications built during the
past 10 years, representing over a million lines of embedded Java code,
Aonix support engineers have found that the JNI interface
between C and Java code represents the single most common failure point.
Compounding this problem, these errors are among the most difficult to debug.
This is because a C programmer who inadvertently compromises the JNI protocol
leaves the accompanying Java virtual machine in an unstable state. The error
may manifest itself as an error in Java application code or in the
implementation of the Java virtual machine itself. Finger pointing between the
virtual machine vendor, the Java application developers, and the C developers
results.
Java Specification Request (JSR) 302 is developing standard
approaches for hard real-time safety-critical Java programming. Besides
supporting the stringent demands of safety certification for applications like
nuclear power station shutdown and control of commercial aircraft, the
safety-critical Java standard also represents a foundation appropriate for the
development of all kinds of low-level code in the Java language. Prototype
implementations of this evolving standard have demonstrated significant savings
in memory footprint (more than 100 fold), throughput (up to 3 fold), and determinism
(thousands fold). This low-level Java code is able to demonstrate performance
characteristics within 10 percent of optimized C. It is able to directly
control device hardware by providing support for Java implementation of
first-level interrupt handlers and device register input and output operations.
For those who must build tiered software architectures that
span the spectrum from dynamic high-level complexity to static low-level
simplicity, a mechanism has been designed to allow very efficient and robust
integration of low-level hard real-time Java components with high-level
traditional Java components. From a long-term engineering perspective,
elimination of C code within the entire application yields better control, more
predictability, less expensive software maintenance, and improved software
longevity.
Performanceresults
An Aonix demonstration features a computationally intensive
fractal program with the fractal rendering implemented in either C or hard
real-time Java code. In both cases, the graphics display is programmed in Java
with an SWT graphics interface. The all-Java performance boost revealed by the
demonstration is a benefit of the cleaner integration between high- and
low-level Java code. The all-Java solution clearly shows the inefficiency
introduced by the Java Native Interface required to integrate between
high-level Java code and low-level C code.
The demonstration was run in an embedded Linux environment,
and there was no requirement to address bare hardware for this particular
demonstration. In fact, traditional Java and hard real-time Java technologies
will run atop most embedded OSs and commercial RTOS environments. The hard
real-time Java technology is simple enough that it can also be installed to run
on bare hardware, without an underlying operating system.
Besides the improved reliability, maintainability, and
developer productivity of eliminating the C language from the application, this
demonstration shows that the all-Java solution outruns the equivalent Java-C
hybrid program by more than two to one.. The exact speedup depends on the zoom
factor and the window size. With one particular measurement, the all-Java
program ran 2.33 times faster than the hybrid.
All-Java solutions ease development, integration, and maintenance
There is no one-size-fits-all JVM, but now hard real-time
Java is providing a one-source Java remedy that reaches all levels of the
embedded, real-time application from high-level application complexity all the
way down to the lowest levels of hardware.
Dr. Kelvin Nilsen is
chief technology officer at Aonix, a leading supplier of solutions for
mission-critical software applications. He is recognized as a leading authority
on real-time Java and real-time garbage collection. Currently, he contributes to
the Java Community Process as a member of the expert groups for JSR-282 and
JSR-302. Prior roles include research faculty at Iowa State University and
founder of NewMonics. Dr. Nilsen holds a B.S. degree in Physics from Brigham
Young University, and M.S. and Ph.D. degrees in Computer Science from the
University of Arizona. He can be reached at [email protected].
Aonix North America, Inc.
1-800-972-6649
www.aonix.com
