|
Embedded applications, such as controlling a device like a cell phone or
a heart pump, can require real-time (RT) programming. (RT
requirements, of course, can also be applied to non-embedded systems.)
Real-time essentially means providing both periodic services and
responses to asynchronous demands within strictly enforced deadlines.
A real time system is said to be deterministic, meaning it
can be relied upon to execute a given task in a predictable amount
of time, every time it is called.
Note that a real-time system is not necessarily
"real fast." What matters most is that the time taken to complete
a task is guaranteed to stay within a known maximum allowed time,
i.e. a worst-case delay.
It is common to classify systems as hard real-time
or soft real-time. The hard RT systems will never miss a
deadline while soft RT tolerates some degree of delay and missed
deadlines. A soft RT system degrades rather than fails.
Its common that one part of software system is
hard RT while most of it is soft. For example, a program controlling
the communications in a cell phone might need to heed hard RT requirements
while the graphics user interface on the phone's LCD screen could
tolerate some delays.
With reasonable care in the coding and tuning,
a program using J2SE or J2ME code can provide acceptable soft real-time
performance such as responding quickly enough to inputs on a graphical
user interface to satisfy usability requirements. However, for hard
real-time tasks Java requires special techniques and/or extensions
to the standard set of packages. For example, one technique has
been to connect Java to C/C++ programs via JNI (see Chapter
22) to carry out the most time critical tasks.
Garbage
Collection vs. Real-Time
The most critical obstacle to real-time processing with Java comes from
the Garbage
Collector (GC). The GC thread works in the background to manage
the allocation of memory. The GC provides memory to new objects
and reclaims memory from objects no longer referenced by any variables.
The GC relieves the programmer from the burden of memory management
and is often cited as one of the primary advantages of Java programming.
However, for real time applications the uncertainty as to when the GC will
run and for how long is unacceptable. A process responding to a
critical request cannot stop what it is doing and begin running
the GC. . The JVM specification does not require a particular type
of GC algorithm, and many such algorithms are not deterministic.
One drastic option is simply to turn the GC off. For example, the Javelin Stamp processor,
which we will discuss later, eliminates the GC entirely. The drawback
obviously is that the user must then take responsibility
for all memory management. In particular, the creation of objects
and arrays must be very carefully monitored and restricted by the
program to avoid running out of memory.
Another technique is to invoke System.gc()
during free periods when critical processing isn't required. Though
not required to do so, most JVMs run the GC immediately when this
method is invoked. If the programmer also insures that there is
sufficient memory available for new objects (otherwise the GC will
run to free up memory), then the GC will not interfere with the
real-time activities.
There are several commercial real-time JVMs available. For example,
NewMonics provides
its PERC JVM, which is compatible with JDK 1.3 and works with several
real-time operating systems. The Jamaica VM from Aicas
"provides hard real-time guarantees for all features of the languages
together with high performance runtime efficiency".
Incremental collection is a common technique used to create a real-time
compatible GC. Unlike many GC algorithms that must either fully
complete their pass through the memory or start over from the beginning
if they are interrupted, an incremental GC works in short steps
and thus allows for interruptions in between the steps. The JVMs
from NewMonics and Aicas, for example, use incremental GC.
The Real
Time Specification for Java (RTSJ)
The JVM specifications do not preclude enhancements needed to provide real-time
performance and work on the Real Time Specification for Java
(RTSJ) began in 1998 by a group in the Java Community Process (jcp.org)
and they finished in 2003. Details of the specification can be found
at www.rtj.org.
The RTSJ extension classes come via the javax.realtime
API. (Note that standard Java programs can run without modification in a real-time
JVM.) The company TimeSys (www.timesys.com) provides the
reference implementation of the RTSJ.
The RTSJ does not specify a particular GC algorithm such as incremental
collection. It does define new types of memory areas that allow avoidance of
the GC altogether. Immortal memory holds objects without destroying them except
when the program ends. Scoped memory is used only while a process works within a particular
section, or scope, of the program such as in a method. Objects there
are automatically destroyed when the process leaves the scope.
Neither immortal nor scoped memories are garbage collected, so using
them avoids the problems of GC interference. Note, however, that
the programmer must watch out for overflow of the immortal memory.
Another important aspect of the RTSJ was the addition of real-time
threads, which provide for more precise scheduling
than with standard threads. They have 28 levels of priority and
their priority is strictly enforced. They are not subject to so-called
priority inversion situations where a lower priority thread has
a block on a resource needed by the higher priority thread and thus
prevents the higher priority thread from running. Furthermore, the
RTSJ includes non-heap real-time threads that cannot be interrupted
by the GC.
The RTSJ also provides for asynchronous event handlers that
deal with external events (or happenings, as they are called,
to distinguish them from the events in the AWT). Asynchronous
transfer of control allows one thread to interrupt another thread
in a safe manner, unlike the deprecated suspend()
and stop()
methods for standard threads.
Timing is obviously important for real-time programming so the javax.realtime
API includes the abstract class HighResolutionTime
and its subclass AbsoluteTime,
which represents a point in time, and RelativeTime,
which represents a duration. The base class uses a long
value for milliseconds and an int
value for nanoseconds. Unlike standard Java, RTSJ requires that
an implementation provide sub-millisecond precision. (Of course,
the accuracy will vary according to the capability of the clock
on a particular system.)
While still maintaining security protections, the RTSJ allows direct
access to physical memory. This means that device drivers can
be created with Java. Previously, Java had to link to native
code to communicate directly with hardware.
Full implementations of the RTSJ specification can be too large for
some embedded systems and not all of its capabilities are required
for every real-time application. So some Java real-time systems
use subsets of the RTSJ or they use independent extensions to obtain
a smaller memory footprint.
Real-time programming in Java, and in general, can be considerably
more challenging than non-RT programming. A number of complex topics
and techniques are involved and careful timing measurements and
testing are required. See the book by Dibble and the other real-time
references for more information.
References & Web Resources
- Real Time Java Working Group - www.rtj.org.
- Sione Palu, Real-time
Specification for Java (RTSJ), Gamellan - developer.com.
- RT OS:
- Edward J. Correia, Real
Time Java Takes Flight: New and pending specifications aim to
simplify embedded development, broaden device compatibility,
SD Times, August 1, 2003.
- Peter C. Dibble, Real-Time Java Platform Programming,
Sun Microsystems, Inc., 2002.
- Brian Goetz, A
brief history of garbage collection, IBM DeveloperWorks,
2003.
- Tuning
Garbage Collection with the 1.4.2 Java[tm] Virtual Machine,
Sun Microsystems, Inc.
- Greg
Bollella on Controlling Physical Systems with Real-time Specification
for Java: Combining Real-time and Non-real-time Operations on
a Single Processor, System News, Vol. 75, Issue 4, May
24, 2004.
- javolution.org
- this open source project provides "a time-predictable standard
library".
- jscience.org
- extensive math and science class library that builds on the
javaolution RT library.
Latest update: Dec. 14, 2004
|
