Embedded Java - JavaTech: An Introduction to Scientific and Technical Computing with Java - page 655

deadlines. A real-time system is said to be deterministic , meaning that it can
be relied upon to execute a given task in a predictable amount of time, every
time that task is executed. A real-time system is not necessarily “real fast.” What
matters is that the time taken to complete a task is guaranteed to be within a
known maximum allowed time, i.e. a worst-case delay.
Systems are often classified as “hard real-time” or “soft real-time.” Hard real-
time systems do not tolerate any missed deadlines at all. Soft real-time allows
for some degree of delay and missed deadlines, i.e. performance degrades rather
than fails. Often only a part of a program requires hard real-time execution, say
the part that controls a device of some sort, and the rest of the program, such as
a user interface, gets by with soft real-time performance.
With reasonable care, a program using J2SE or J2ME code can provide accept-
able soft real-time performance such as responding quickly enough to inputs on
agraphical 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.
The biggest obstacle to real-time processing with Java comes from the Garbage
Collector (GC) [7,8]. The GC works as a threaded process to manage the alloca-
tion of memory in the “heap,” i.e. the data buffer for a program. The GC provides
memory for new objects and periodically reclaims memory from objects with
no references to them. The GC relieves the programmer of the burden of mem-
ory management and is often cited as one of the primary advantages of Java
programming.
However, for real-time applications, the uncertainty as to when and for how
long the GC will run is unacceptable. A process responding to a critical request
cannot stop what it is doing while the GC runs. The JVM specification does
not require a particular type of GC algorithm, and many such algorithms are
not deterministic. The GC can be turned off completely, as in one of the Java
processors we discuss below, but then the user must carefully monitor the heap
to avoid overflows. 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 ensures 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, New-
Monics provides its PERC JVM, which is compatible with JDK 1.3 and works
with several real-time operating systems [9]. The Jamaica VM from Aicas “pro-
vides hard real-time guarantees for all features of the languages together with
high performance runtime efficiency” [10].
Incremental collection is a common technique used to create a real-time-
compatible GC. Unlike many GC algorithms that must either fully complete their