This is no longer the case when using the Sun Java Real-Time System (Java RTS), Sun Microsystems’ implementation of the RTSJ, and its real-time garbage-collector (RTGC). You can now produce a predictable application by changing a few declarations in an existing program; assigning real-time priorities and scheduling parameters to time-critical threads; and providing minimal configuration information for the RTGC. Here’s a short example to get a feel for what’s involved.

// self is a Thread // self is a RealtimeThread
while (true) do { self.setPriority(myRT_Priority);
compute_data(); self.setSchedulingParameters(myPeriod);
now = System.currentTimeMillis(); while (true) do {
Thread.sleep(next_period – now); compute_data();
send_data(); Thread.waitForNextPeriod();
next_period += period; send_data();
} }

Further programming tips and code examples can be found at http://java.sun.com/javase/technologies/realtime/.

Key Concepts
Before discussing predictability, we must first define it, along with a few related terms.

A program is predictable if its jitter, i.e., the variation in its total response time, is bounded. A program is deterministic to the extent that its jitter approaches zero; a perfectly deterministic program has a jitter of zero. We can’t attain that, but it doesn’t matter in practice as long as jitter can be bounded. For a financial application, jitter might be defined in terms of transaction time. For an industrial control application, it might be defined in terms of the length of time it takes to figure out the next position of a robotic arm.

A deadline is the time by which a program must complete a response. In a soft real-time application, missing one or a few deadlines isn’t critical, but in a hard real-time application, no deadline can be missed.

In a multi-threaded program, usually only a few threads execute code that must be predictable. We call such threads critical. We refer to the rest of the threads as non-critical. In a real-time system, critical threads always execute at a critical real-time priority above that of non-critical threads. Real-time priorities must be enforced by the operating system and are always higher than normal time-sharing thread priorities. The priorities of normal threads are in practice advisory, since non-real-time threads can be preempted by the operating system at any time. Threads with real-time priorities run until blocked, which means that if used carelessly they can potentially hang the system.

When running a Java software program, jitter can be caused by many system activities, especially internal virtual machine activities. The common sources of jitter include class loading and static initialization, dynamic compilation, and the execution of compiled code and garbage collection. Jitter in each of these categories can be bounded, but only at the price of program throughput. Thus we recognize a predictability spectrum, with high throughput and low predictability at one end and lower throughput and high predictability at the other. You can usually configure a conventional virtual machine, like the HotSpot JVM Sun Microsystems ships in the Java Platform Standard Edition (Java SE), to achieve soft real-time predictability down to about 20 milliseconds or so on multi-processor systems. However, to go much lower, and especially to get down below a millisecond, requires a real-time virtual machine such as that included in Java RTS.

In a virtual machine like the HotSpot JVM, the primary performance criterion is the average execution time of an application, which translates to maximum throughput. Certain, infrequently used, virtual machine operations can be allowed to execute in an unpredictable amount of time if doing so allows the most common cases and more frequent operations to execute faster. This is great if throughput is your only objective, but not so great if you need predictability.

Class Loading
A virtual machine normally loads a class when a program first tries to create an instance of that class, or when a program tries to use a static method or variable of that class. When a class is loaded, its static variables are initialized. This activity takes time and can interfere with the execution of any code that is critical for the real-time application. Since it isn’t possible to predict when classes will be loaded or how long it will take, it’s also not possible to predict when this jitter will occur, nor whether the amount of the jitter is acceptable. In both real-time and non-real-time virtual machines, you can avoid this problem by referencing and using all classes utilized by critical threads before they start executing time-critical code. In addition, Java RTS allows you to specify a list of classes to be pre-loaded and initialized at start-up.

Synchronization
High-performance virtual machines, like the HotSpot JVM, heavily optimize the common case of uncontended object locking, typically using branch instructions first, then atomic instructions, and, only as a last resort, an operating system mutex when contention occurs. Java RTS can’t use branch instructions in the uncontended case because that mechanism requires a stop-the-world pause, during which no application thread can run. It does, however, use atomic instructions in preference to mutexes as long as there’s no real contention. In addition, Java RTS provides a mechanism to force allocation of a mutex for a particular object so that the associated OS-induced jitter doesn’t happen while executing time-critical code.

Compilation
One of the most common sources of jitter is run-time compilation. Since compiled code executes faster than interpreted code, a program can run faster if frequently executed pieces of code are compiled during program execution. If, however, compilation interrupts the execution of a section of time-critical code, determinism will be seriously compromised.

Another source of unpredictable compilation-related jitter is lazy, or on-demand, resolution of symbols (fields, classes and methods). When an unresolved symbol is encountered during the execution of generated code, a virtual machine can use some extra, non-deterministic code to resolve the symbol. In this way, a virtual machine can avoid resolving symbols that are never actually used and improve average performance. However, since the timing of the resolution operation itself is unpredictable, lazy symbol resolution is unacceptable in time-critical code.

Another issue is that optimized code typically makes assumptions about runtime conditions that, if violated, must result in abandoning the generated code and reverting back to either an interpreter or to completely unoptimized code. This process is called deoptimization and requires a stop-the-world pause. Time-critical code cannot depend on this sort of optimization and must be compiled to run more slowly than non-time-critical code.

Virtual machines, like the HotSpot JVM, make no attempt to control compilation-induced jitter other than to compile in the background on multi-processor systems. Java RTS, on the other hand, currently supports two compilation modes: Just-In-Time Compilation (JIT) and Initialization Time Compilation (ITC).