|JamaicaVM 3.2 — User Documentation: The Virtual Machine for Realtime and Embedded Systems|
|Prev||Chapter 12. Guidelines for Realtime Programming in Java||Next|
Thus far, only standard Java construct have been discussed. However libraries and other APIs are also an issue. Timely Java development needs support for timely execution and device access. There are also issues of certifiability to consider. The JamaicaVM has at least some support for all of the following APIs.
The Real-Time Specification for Java (RTSJ) provides functionality needed for time-critical Java applications. RTSJ introduces an additional API of Java classes, mainly with the goal of providing a standardized mechanism for realtime extensions of Java Virtual Machines. RTSJ extensions also cover other areas of great importance to many embedded realtime applications, such as direct access to physical memory (e.g., memory mapped I/O) or asynchronous mechanisms.
Currently, RTSJ is available for the JamaicaVM developed in HIDOORS and for TimeSys JTime. JavaVMs from other vendors are likely to follow in the future.
Ensuring that Java programs can execute in a timely fashion was a main goal of RTSJ. To enable the development of realtime software in an environment with a garbage collector that stops the execution of application threads in an unpredictable way (see Figure 12-2), the new thread classes RealtimeThread and NoHeapRealtimeThread were defined. These thread types are unaffected, or at least less severely affected, by garbage collection activity. Also, at least 28 new priority levels, logically higher than the priority of the garbage collector, are available for these threads, as illustrated in Figure 12-3.
For realtime threads not to be affected by garbage collector activity, these threads need to use memory areas that are not under the control of the garbage collector. New memory classes, ImmortalMemory and ScopedMemory, provide these memory areas. One important consequence of using special memory areas is, of course, that the advantages of dynamic memory management is not fully available to realtime threads.
In realtime systems with threads of different priority levels, priority inversion situations must be avoided. Priority inversion occurs when a thread of high priority is blocked by waiting for a monitor that is owned by a thread of a lower priority that is preempted by some thread with intermediate priority. The RTSJ provides two alternatives, priority inheritance and the priority ceiling protocol, to avoid priority inversion.
The RTSJ provides a solution for realtime programming, but it also brings new difficulties to the developer. The most important consequence is that applications have to be split strictly into two parts: a realtime and a non realtime part. Communication between these parts is heavily restricted: realtime threads cannot perform memory operations such as the allocation of objects on the normal heap which is under the control of the garbage collector. Synchronization between realtime and non realtime threads is also severely restricted to prevent realtime threads from being blocked by the garbage collector due to priority inversion.
The JamaicaVM removes these restrictions by using its realtime garbage collection technology. Realtime garbage collection obviates the need to make a strict separation of realtime and non realtime code. Combined with static memory deallocation that automatically replaces some dynamic memory allocations, dynamic allocations in realtime code may even be eliminated completely. Using RTSJ with realtime garbage collection provides necessary realtime facilities without the cumbersomeness of having to segregate a realtime application.
Both the need to use legacy code and the desire to access exotic hardware may make it advantageous to call foreign code out of a JVM. The Java Native Interface (JNI) provides this access. JNI can be used to embed code written in other languages than Java, (usually C), into Java programs.
While calling foreign code through JNI is flexible, the resulting code has several disadvantages. It is usually harder to port to other operating systems or hardware architectures than Java code. Another drawback is that JNI is not very high-performing on any Java Virtual Machine. The main reason for the inefficiency is that the JNI specification is independent of the Java Virtual Machine. Significant additional bookkeeping is required to insure that Java references that are handed over to the native code will remain protected from being recycled by the garbage collector while they are in use by the native code. The result is that calling JNI methods is usually expensive.
An additional disadvantage of the use of native code is that the application of any sort of formal program verification of this code becomes virtually intractable.
Nevertheless, because of its availability for many JVMs, JNI is the most popular Java interface for accessing hardware. It can be used whenever Java programs need to embed C routines that are not called too often or not overly time-critical. If portability to other JVM is a major issue, there is no current alternative to JNI. When portability to other operating systems or hardware architectures is more important, RTDA or RTSJ is a better choice for device access.
Usually when one refers to Java, one thinks of the Java 2 Standard Edition (J2ME), but this is not the only Java configuration available. For enterprise applications, Sun Microsystems has defined a more powerful version of Java, Java 2 Enterprise Edition (J2EE), which supports Web servers and large. There is also a stripped down version of Java for embedded applications, Java 2 Micro Edition (J2ME). This is interesting for timely Java development on systems with limited resources.
J2ME is in fact not a single Java implementation, but a family of implementations. At its base, J2ME has two configurations: Connected Device Configuration (CDC) and Connected Limited Device Configuration (CLDC). Profiles for particular application domains are layered on top of these configurations, e.g. Mobile Information Device Profile (MIDP) on CLDC, and Personal Profile on CDC.
The JamaicaVM supports both base configurations. Smaller Java configurations are interesting not only on systems with hardware limitations, but also for certification. The vast number of classes in J2SE would make any JVM certification daunting. Again, the choice between J2SE and J2ME is a trade off between flexibility on the one hand and leanness and robustness on the other. A safety-critical version of JamaicaVM may well support a safety-critical profile for CDC in the future.