Building Java-based embedded designs with real time constraints

Hard real time systems are those in which an action performed at the wrong time will have zero or possibly negative value. The connotation of “hard real time” is that compliance with all timing constraints is proven using theoretical static analysis techniques prior to deployment. Soft real time systems are those within which an action performed at the wrong time (either too early or too late) has some positive value even though it would have had greater value if performed at the proper time. The expectation is that soft real-time systems use empirical (statistical) measurements and heuristic enforcement of resource budgets to improve the likelihood that software complies with timing constraints.

Practically speaking, the soft real-time Java development guidelines are generally preferred unless there is a specific constraint that precludes them. This is because soft real-time Java offers the highest developer and software maintenance productivity. The soft real-time Java guidelines involve the use of traditional J2SE-style Java APIs with virtual machines that have been specially implemented to support real-time behavior. These virtual machines support pre-emptible and incremental real-time garbage collection, fixed priority scheduling, and priority inheritance in the implementation of all synchronization locks.

In contrast, the hard real-time Java technologies do not make any use of automatic garbage collection. Instead, dynamic memory is allocated and de-allocated under more explicit programmer control. A draft standard for safety-critical Java supports a subset of the full spectrum of capabilities recommended for hard real-time Java development.

Note that the difference between hard real-time and soft real-time does not depend on the time ranges specified for deadlines or periodic tasks. A soft real-time system might have a deadline of 100 microseconds, while a hard real-time system may have a deadline of 3 seconds.

Satisfying real-time constraints in a high assurance Java application is possible if the developer recognizes the strengths and weaknesses of particular Java methodologies such as automatic garbage collection, and carefully selecting the most appropriate mechanisms to address each particular system requirement.

It is also necessary to play close attention to the hard real-time Java guidelines as specified in ”Draft Guidelines for Scalable Java Development of Real-Time Systems”, authored by Kelvin Nilsen, available at http://research.aonix.com/jsc/rtjava.guidelines.5-6-05.pdf.

The real-time cost of automatic garbage collection
Automatic garbage collection is one of the key reasons why Java developers are more productive than C and C++ developers. But the power of garbage collection comes with a cost.

Traditional Java implementations occasionally pause execution of all Java threads to scan memory in search of objects that are no longer being used. These pauses can last tens of seconds with large memory heaps. Memory heaps ranging from 100 Mbytes to a full Gigabyte are being used in certain mission-critical systems. The 30-second garbage collection pause times experienced with traditional Java virtual machines are incompatible with the real-time execution requirements of most mission-critical systems.

Special real-time virtual machines have been implemented to support pre-emptible and incremental operation of the garbage collector. With these virtual machines, the interference by garbage collection on the real-time application workload can be statistically bounded, making this approach suitable for soft real-time systems with timing constraints measured in the hundreds of microseconds.

One of the costs of automatic garbage collection is the overhead of implementing sharing protocols between application threads. Application threads are continually modifying the way objects relate to each other within memory while garbage collection threads are continually trying to identify objects that are no longer reached from any threads in the system. This coordination overhead is one of the main reasons that compiled Java programs run at a third to half the speed of optimized C code.

The complexity of the garbage collection process and of any software that depends on garbage collection for reliable execution is beyond the reach of cost-effective static analysis to guarantee compliance with all hard real-time constraints. Thus, we do not recommend the use of automatic garbage collection for software that has hard real-time constraints or that requires DO-178B Level A safety certification.