System Integration
Gnu C (gcc –O2)
Soft Real-Time Java (PERC Ultra)
Hard Real-Time Java (PERC Pico)
Min (ns)
280
519
314
Max (ns)
571
1,060
633
Average (ns)
360
639
392
Std Dev (ns)
25.52465
48.66415
29.8434
Virtual Memory (MB)
2.32
24
2.5
Table 1
Comparison of code efficiency between optimized C and two commercial implementations of Java.
Java technology offers throughput, footprint and predictable latency comparable to equivalent optimized C programs. We characterize this technology as hard realtime Java. In various experiments conducted on this hard real-time Java technology, we have found that Java code runs within 15% of the speed, memory footprint, and determinism of optimized C code. Table 1 compares the efficiency of optimized C with commercial products supporting both soft real-time (PERC Ultra) and hard realtime (PERC Pico) execution of Java. The measured workload was patterned after a real-world defense industry application. Though the Sun HotSpot virtual machine (VM) is not designed to support real-time operation, we evaluated the benchmark on Sun HotSpot as well. Surprisingly, Sun HotSpot offered average speed that is even better than optimized C, 294 ns. However, the maximum time for the HotSpot implementation was 8,089 ns and the standard deviation was 228.8 ns. Also of note was HotSpot’s virtual memory consumption of over 250 Mbytes. HotSpot improves upon C by profiling the code as it runs, in-lining the implementations of certain methods, and optimizing execution of the most common path through the code. While this approach offers impressive throughput, the high variation in execution time is incompatible with the requirements of many real-time systems, and the self-modifying code is incompatible with traceability and repeatability requirements of most highintegrity systems. With the ability of hard real-time Java to approach C performance, the motivation to use C for the implementation of low-level, performance-critical code decreases. Today’s typical real-time Java
Shared Registry
“device.X”
Traditional Java Virtual Machine Performs Registry.lookup(“device.X”);
Figure 1
Hard Real-Time Java Virtual Machine Performs Registry.publish (“device.X”, o);
Traditional and real-time Java virtual machines consult objects in a shared registry by which the real-time VM can execute objects referred to by the traditional VM.
application incorporates a combination of Java and C code, bound together using the Java Native Interface (JNI). In general, the use of C code has been required to implement portions of the system that demand higher throughput, more determinism, or smaller (more economical) memory footprint than is feasible with traditional Java. In some cases, the use of C for lowlevel software is motivated by a need to directly interface to hardware devices. Often, in such systems, software developers come to view JNI as the Achilles’ heel of their software architectures. All of the security that is such an intrinsic part of the Java virtual machine is compromised at the boundary between Java and C. More than one customer has identified this boundary as the single most common source of programmer errors. A second weakness of the JNI interface is the high cost of marshalling data every time the boundary between Java and C is crossed.
Untitled-6 1
August 2008
33
3/17/08 2:05:19 PM